mirror of
https://github.com/apache/nuttx.git
synced 2026-08-25 07:27:11 +00:00
8c8ef5fbcc
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> |
||
|---|---|---|
| .. | ||
| arm | ||
| arm64 | ||
| avr | ||
| ceva | ||
| dummy | ||
| hc | ||
| mips | ||
| misoc | ||
| or1k | ||
| renesas | ||
| risc-v | ||
| sim | ||
| sparc | ||
| tricore | ||
| x86 | ||
| x86_64 | ||
| xtensa | ||
| z16 | ||
| z80 | ||
| CMakeLists.txt | ||
| Kconfig | ||