Bug 196747
| Summary: | Realtek 8153 disconnects with EPROTO -71 when hub has traffic, resetting entire usb device tree | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Harald Rudell (harald.rudell) |
| Component: | Network | Assignee: | drivers_network (drivers_network) |
| Status: | NEW --- | ||
| Severity: | normal | CC: | dion |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 4.12.8-041208-generic | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Harald Rudell
2017-08-23 20:00:52 UTC
Meanwhile, do not connect Realtek USB to a hub that has sibling ports being used The device needs its own single-usb-port or a hub with no other devices connected /sys/bus/usb/devices lists the device tree reliably This is the chip that is sold in the Apple store as Belkin USB-C LAN if blessed by Apple it must work... There is a macOS driver that appears to work well However, it's 480 Mb/s under macOS, too Correction: macOS has it at 5 Gb/s, but only when connected directly to the computer. I have some adapters that Apple apparently do not like. Therefore, the speed issue under Linux could be an adapter problem, too I can confirm that Realtek 8153 does work at 5 Gb/s. The non-standard passive male-usb-c to male-usb-a that people use gives 480 Mb/s one way, but 5 Gb/s when the usb-c connector is turned upside down It also seems that the xhci_hcd built-in kernel driver resets the usb hubs that has no connected devices periodically every 3 minutes to 3 hours. More logging making paranoid people think something is broken. Anyway, lots of traffic flowing through the hub where r8153 is connected causes the hub to be reset and of course whoever is receiving the usb traffic to fail. This includes resetting sensitive hardware like network interfaces and usb drives. (5 Gb/s obtained with driver version 2.08.0) unclear if 1.08.9 can do it The 1.08.9 r8152 driver can only provide 480 Mb/s and not the 5 Gb/s that the hardware is capable of I think the github readme was explaining the problem as differing device ids for the same chip Jesus, lsusb --tree crashes Realtek, too. Just not the hub. 3 seconds before lsusb completes: usb 2-2: new SuperSpeed USB device number 35 using xhci_hcd usb 2-2: New USB device found, idVendor=0bda, idProduct=8153 usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=6 usb 2-2: Product: USB 10/100/1000 LAN usb 2-2: Manufacturer: Realtek usb 2-2: SerialNumber: 000001000000 usb 2-2: reset SuperSpeed USB device number 35 using xhci_hcd No scratch #8. I was playing with multiple Realtek. It's worse. If a Realtek USB device is plugged in anywhere on any port, that and the other device will reset. You can not avoid the crash through some clever hub arrangement, it will crash. r8152 2.08.0 with the same symptoms resets the entire usb bus with all connected usb devices and hubs periodically every two weeks or so without any provocation. This is unacceptable if you have sensitive usb devices other than silly things like computer mice. The ax88179_178a driver has none of these problems, a driver for different hardware providing the same function on the same computer So, if you bot macOS, you must use the Realtek b/c that's the only hardware Apple truly writes drivers for Boot into Linux Realtek has to be unplugged because of the poor driver software, and instead use the Asix that itself has a shitty driver for macOS. |