Stm32h7 ethernet - #19930
Open
JorgeGzm wants to merge 2 commits into
Open
Conversation
…duplex On the linum-stm32h753bi, Ethernet throughput collapses in proportion to what the display panel is showing. With the LTDC scanning a black screen a 1.2 MiB TCP transfer to a wired peer takes 0.7 s; solid white takes 20 to 55 s and noise over 130 s, all at the same negotiated 100BASE-TX full duplex, with the same bytes read from the same SDRAM. The display's switching couples into the PHY hard enough to corrupt 100BASE-TX signalling, and TCP grinds through the losses at whatever rate survives. 10BASE-T signals at 2.5 V with Manchester coding at a tenth of the frequency, and does not care: black, white and noise all move at the link rate. The same transfer that took five minutes with the display rendering takes 5.6 seconds. Restricting the ANAR advertisement is deliberately not the same as disabling autonegotiation. A forced MCR leaves the partner to parallel detection, which cannot sense duplex and picks half, a genuine mismatch, verified here to stall bulk traffic completely. Advertising only 10BASE-T full duplex keeps the negotiation and lands both ends on the same mode. Also fix the never-compiled !CONFIG_STM32_AUTONEG path, which still called stm32_phywrite(); this driver has only ever had mdio_write(). And say what was negotiated at link-up: a duplex mismatch looks exactly like a bad cable, and nothing else reports which of the two it is. The vnc configuration of the linum board enables the new option, and its packet pool sizing from a few commits ago stays: at any link speed, 24 buffers of 196 bytes was never going to stream a display. Assisted-by: Claude:opus-5 Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The receive path hands incoming packets to the stack and transmits whatever reply comes back, without checking that a TX descriptor is free, though the poll path checks exactly that. Under sustained bidirectional load the reply lands on a descriptor the DMA still owns: with assertions built in, a panic from the RX work queue (DEBUGASSERT(des3 & RD_OWN), reproduced under a VNC pointer flood); without them, corruption of a frame in flight. A reply to received data is almost always an acknowledgement, and a peer that misses one retransmits; overwriting a frame the DMA owns recovers from nothing. Drop the reply when the ring is full, using the same descriptor test the poll path already trusts. Assisted-by: Claude:opus-5 Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
JorgeGzm
requested review from
davids5,
raiden00pl and
xiaoxiang781216
as code owners
August 22, 2026 04:41
github-actions
Bot
added
Arch: arm
|
xiaoxiang781216
approved these changes
Aug 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Two independent fixes to the STM32H7 Ethernet driver, split out of #19911
at review request.
Never transmit a reply into a full TX ring
stm32_receive()replies to ARP, IPv4 and IPv6 straight from the RX pathwithout checking whether a TX descriptor is free. Under sustained load the
reply overwrites a descriptor the DMA still owns and the link stalls until
the interface is reset.
All three reply paths now check
stm32_txringfull()first. That check hasto consider
des0as well as the OWN bit: a descriptor already consumed bythe DMA but not yet reclaimed still has its buffer pointer set, and
treating it as free is what corrupts the ring.
Allow restricting autonegotiation to 10BASE-T full duplex
New
CONFIG_STM32_AUTONEG_10FD_ONLY, default n. On a board whose displaygenerates enough noise to corrupt 100BASE-TX, throughput collapses with
whatever is on the screen. Advertising only 10BASE-T full duplex makes both
ends negotiate a link that survives the interference.
It advertises rather than forcing the MCR, so the two ends still agree. A
forced setting on one side produces a duplex mismatch, which looks exactly
like a bad cable and is much harder to diagnose.
Impact
No functional change for existing users. Both are confined to
arch/arm/src/stm32h7/stm32_ethernet.cand the sharedarch/arm/src/common/stm32/Kconfig.eth; the new option defaults to n, sonothing changes unless a board opts in.
The TX ring guard costs one descriptor read per received packet that gets
a reply.
Testing
Host: Linux, arm-none-eabi-gcc 13.2.
Board: linum-stm32h753bi (STM32H753BI, 1024x600 RGB panel),
netnsh.TX ring: sustained ping flood and TCP transfer while the panel was being
redrawn. Before the change the link stalled and only a reset recovered it.
After, the interface stayed up for the whole run.
Autonegotiation: measured throughput with the panel showing static content
against animated content.
With 100BASE-TX the transfer rate varied by up to 200x depending on screen
content. With the option enabled the link is slower on paper and steady in
practice.