linux
linux copied to clipboard
LAN7800 // USB3 host hangs with 100mbit links
Describe the bug
With a Raspberry Pi 4 Model B I can reproducibly generate an ethernet hang using LAN7800 USB devices. (See steps listed)
Steps to reproduce the behaviour
-
Raspberry Pi Setup:
- Connect a Raspberry pi 4 Model B to a USB3 hub with a LAN7800 device on a 5Gbps port
- Boot a raspios 64-bit image (e.g. 2024-07-04-raspios-bookworm-arm64-lite.img)
- Configure the LAN7800 to a known static IP using interfaces.d (in my case eth1 - 10.0.2.1)
- install iperf3
-
Remote Host Setup :
- Can be an arbitrary linux machine (in my case Debian 12 on a Dell Latitude Rugged 5420 laptop)
- Configure the ethernet to a known static IP using interfaces.d (in my case eth1 - 10.0.2.230)
- Do either :
- Configure ethernet to 100mbit (ethtool -s enp0s31f6 speed 100)
- Connect ethernet to rpi via a switch that supports 100mbit max
- install iperf3
- start iperf3 in server mode :
- iperf3 -s
-
RPI Test
- Check both devices are communicating OK with a ping test
- Run iper3 on the RPI eg :
- iperf3 -c 10.0.2.230 --bind-dev eth1 -t 0
On test setup here, this starts to fail within a couple of minutes, often as fast as 7 secs in.
Device (s)
Raspberry Pi 4 Mod. B
System
See above.
Logs
user@raspberrypi:~ $ iperf3 -c 10.0.2.230 --bind-dev eth1 -t 0 Connecting to host 10.0.2.230, port 5201 [ 5] local 10.0.2.1 port 39956 connected to 10.0.2.230 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 12.7 MBytes 106 Mbits/sec 0 331 KBytes
[ 5] 1.00-2.00 sec 11.3 MBytes 95.1 Mbits/sec 0 345 KBytes
[ 5] 2.00-3.00 sec 11.7 MBytes 97.9 Mbits/sec 0 363 KBytes
[ 5] 3.00-4.00 sec 10.6 MBytes 89.2 Mbits/sec 0 363 KBytes
[ 5] 4.00-5.00 sec 11.2 MBytes 94.0 Mbits/sec 0 363 KBytes
[ 5] 5.00-6.00 sec 11.5 MBytes 96.6 Mbits/sec 0 363 KBytes
[ 5] 6.00-7.00 sec 11.6 MBytes 97.1 Mbits/sec 0 363 KBytes
[ 5] 7.00-8.00 sec 10.8 MBytes 90.2 Mbits/sec 0 363 KBytes
[ 5] 8.00-9.00 sec 11.5 MBytes 96.8 Mbits/sec 0 363 KBytes
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec 1 1.41 KBytes
[ 5] 10.00-11.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 11.00-12.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 12.00-13.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 13.00-14.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
[ 5] 14.00-15.00 sec 0.00 Bytes 0.00 bits/sec 0 1.41 KBytes
Additional context
Misc notes :
- Occurs using either USB3 port, does not occur using either USB2 port.
- Have reproduced using Microchip LAN7800 EVM and custom hardware utilising same LAN7800 chipset
- Have reproduced using an off the shelf USB3 hub ("Uni USB-C 8-in-1") and custom hardware (Microchip USB5926C)
- Is not reproducible when LAN7800 is directly connected to RPI
- Have reproduced using various stock 64-bit raspios images :
- 2020-08-20-raspios-buster-arm64-lite (linux 5.4.51)
- 2023-02-21-raspios-bullseye-arm64-lite (linux 5.15.84)
- 2023-05-03-raspios-bullseye-arm64-lite (linux 6.1.21)
- 2024-07-04-raspios-bookworm-arm64-lite (linux 6.6.31)
- Link needs to be set to 100mb (can be a second machine using crossover, or a 100mb swtich)
One of the critical elements is that the link needs to be at 100mb. Looking at the LAN78xx driver :
https://github.com/raspberrypi/linux/blob/789af262fb268b2006099a096faf4a383592ce1b/drivers/net/usb/lan78xx.c#L1466C1-L1467C1
There's different behaviour when setting up power management - for 1000mbit the driver enables only U1 acceptance, whilst for everything else (i.e. 100mbit) it enables both U1 and U2 acceptance. If one disables the latter path and only enable U1 acceptance for all link speeds, this hang doesn't occur.
Whilst superficially this might indicate that there's a bug in the LAN78xx driver, once failed it doesn't seem to be able to be recovered without a re-boot so my gut feeling is that it's something in the USB Host Controller driver that's failed :
- usbreset of the LAN7800 doesn't recover
- unplugging and re-plugging the LAN7800 doesn't recover
- unplugging and re-plugging the USB3 hub doesn't recover
I've tried reproducing on a standard PC with USB3 but it doesn't occur. If I can find another ARM board with USB3 Ill re-test and update.