search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.23k stars 5.02k forks source link

Raspberry Pi 4: USB disconnect causes failure on other USB devices #5192

Open leezu opened 2 years ago

leezu commented 2 years ago

Describe the bug

With a Mass Storage and a Wireless device (mt7921au CF-953AX) connected to the two USB-3 ports of the Raspberry Pi 4, unplugging the mass storage device triggers internal errors in the kernel mt7921au driver and in the Wireless device's firmware causing the wireless device firmware to reset, indicating that the unplugging of one device interfered with the transmission of messages to the other device.

Steps to reproduce the behaviour

With both devices plugged in, run a speedtest (or otherwise generate traffic) and plug out the Mass Storage device. Observe the failures of the Wireless device.

Device (s)

Raspberry Pi 4 Mod. B

System

Raspberry Pi reference 2021-05-07 Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, dcfd74d7d1fa293065ac6d565711e9ff891fe2b8, stage2

Firmware: Aug 26 2022 14:03:16 Copyright (c) 2012 Broadcom version 102f1e848393c2112206fadffaaf86db04e98326 (clean) (release) (start)

Kernel: Linux raspberrypi 6.0.0-rc7-v8+ #4 SMP PREEMPT Wed Sep 28 02:12:59 UTC 2022 aarch64 GNU/Linux built from rpi-6.0.y https://github.com/raspberrypi/linux/commit/3fb5ca89c844eb9fda924a5e76ffab9e8c068675 which includes the https://github.com/raspberrypi/linux/pull/5173 USB fixes. (This issue also happened with earlier kernels that did not include the #5173 fixes)

Logs

[  347.921685] usb 2-2: USB disconnect, device number 3
[  347.957699] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  348.173668] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=0x07 driverbyte=DRIVER_OK
[  348.653651] usb 2-1: USB disconnect, device number 2
[  348.682609] wlxe0e1a934a6a9: failed to remove key (0, 8c:fd:f0:4f:4f:1c) from hardware (-19)
[  348.688160] wlxe0e1a934a6a9: failed to remove key (0, 2c:71:ff:8e:bd:7f) from hardware (-19)
[  348.695264] wlxe0e1a934a6a9: failed to remove key (0, 94:3a:91:52:e8:11) from hardware (-19)
[  348.700769] wlxe0e1a934a6a9: failed to remove key (0, 2c:71:ff:ae:dc:cc) from hardware (-19)
[  348.706256] wlxe0e1a934a6a9: failed to remove key (1, ff:ff:ff:ff:ff:ff) from hardware (-19)
[  349.661627] mt7921u 2-1:1.3: timed out waiting for pending tx
[  350.009917] usb 2-1: new SuperSpeed USB device number 4 using xhci_hcd
[  350.032007] usb 2-1: New USB device found, idVendor=0e8d, idProduct=7961, bcdDevice= 1.00
[  350.032026] usb 2-1: New USB device strings: Mfr=6, Product=7, SerialNumber=8
[  350.032033] usb 2-1: Product: Wireless_Device
[  350.032038] usb 2-1: Manufacturer: MediaTek Inc.
[  350.032043] usb 2-1: SerialNumber: 000000000
[  352.065633] Bluetooth: hci0: Opcode 0x c03 failed: -110
[  352.195642] usb 2-1: reset SuperSpeed USB device number 4 using xhci_hcd
[  352.360257] mt7921u 2-1:1.3: HW/SW Version: 0x8a108a10, Build Time: 20220908210919a

[  352.374794] mt7921u 2-1:1.3: WM Firmware Version: ____010000, Build Time: 20220908211021
[  354.020290] mt7921u 2-1:1.3 wlxe0e1a934a6a9: renamed from wlan1
[  354.241576] Bluetooth: hci0: Opcode 0x c03 failed: -110
[  374.455254] IPv6: ADDRCONF(NETDEV_CHANGE): wlxe0e1a934a6a9: link becomes ready

Additional context

No response

P33M commented 2 years ago

What happens if you connect one of the devices with a usb3.0 extension lead, or repeat the test with one or both devices plugged into a usb3.0 hub instead?

leezu commented 2 years ago

With this usb3.0 extension lead and this usb3.0 hub, I tested if in the following settings if unplugging this SATA to usb3.0 adapter triggers any kernels errors on the CF-953AX. Each of the tests is done with a fresh boot with all respectively mentioned devices and adapters connected at boot.

mt7921u errors are triggered with:

No errors are triggered with:

P33M commented 2 years ago

The general recommendation is to plug USB-SATA adapters into a downstream powered hub, as they frequently do not adhere to their maximum allowed Vbus current (900mA). Splitting the two devices across separate Vbus supplies clearly fixes the problem with the mass-storage unplug event.

leezu commented 2 years ago

Thank you. Here the usb3 hub and usb3 extension lead both do not have an external power source, whereas the SATA adapter does have a its own power. I verified the current used by the SATA adapter with this USB Power Meter Tester and it shows consistent 0.08A with the SATA adapter connected and the SATA disk powered on. So it looks like this SATA adapter does adhere to the maximum allowed Vbus current?

But disregarding that measurement, could you please explain why "CF-953AX on usb3 hub and SATA on RPi usb3 port" could suffer from such Vbus interference whereas "CF-953AX on usb3 hub and SATA on usb 3 extension lead" isolates against these issues? This seems to imply that the extension lead provides an isolation. I'm not familiar with the USB standard and wiring of these hubs and extension leads, but it does surprise me that an extension lead can provide isolation here. If you have further thoughts on why this setting could isolate that would be helpful.

leezu commented 2 years ago

@P33M would it make sense to obtain VIA Labs input on this issue? They request end users do not directly contact them, so I think you would be the right person to ask. ("End-Users should NOT apply. For product-specific support, please visit your device manufacturer's support site." https://www.via-labs.com/contact.php).

tomikaa87 commented 2 years ago

@leezu

@P33M would it make sense to obtain VIA Labs input on this issue? They request end users do not directly contact them, so I think you would be the right person to ask. ("End-Users should NOT apply. For product-specific support, please visit your device manufacturer's support site." https://www.via-labs.com/contact.php).

Not just on this issue, but on these ones too: https://github.com/raspberrypi/linux/issues/5060 https://github.com/raspberrypi/linux/issues/3404

Since none of these problems seem to be tied to a specific OS or kernel version, I'd say it's a USB host controller firmware issue. Doesn't matter if we use a USB hub or not, or the hub is powered or not.