8

With kernels up to 3.19, all of my USB devices work perfectly.

On upgrading to 4.0 or later, some of my USB devices stop working and the kernel produces errors like this:

[    3.369436] usb 9-1: device descriptor read/64, error -62
[    3.593543] usb 9-1: new full-speed USB device number 4 using ohci-pci
[    3.997572] usb 9-1: device not accepting address 4, error -62
[    4.120602] usb 9-1: new full-speed USB device number 5 using ohci-pci
[    4.524792] usb 9-1: device not accepting address 5, error -62
[    4.524911] usb usb9-port1: unable to enumerate USB device
[   15.402105] usb 9-1: new full-speed USB device number 6 using ohci-pci
[   15.530135] usb 9-1: device descriptor read/64, error -62
[   15.759224] usb 9-1: device descriptor read/64, error -62
[   15.983312] usb 9-1: new full-speed USB device number 7 using ohci-pci
[   16.111309] usb 9-1: device descriptor read/64, error -62
[   16.340398] usb 9-1: device descriptor read/64, error -62
[   16.564378] usb 9-1: new full-speed USB device number 8 using ohci-pci
[   16.968454] usb 9-1: device not accepting address 8, error -62
[   17.091555] usb 9-1: new full-speed USB device number 9 using ohci-pci
[   17.495570] usb 9-1: device not accepting address 9, error -62
[   17.495603] usb usb9-port1: unable to enumerate USB device
[   17.673702] usb 9-1: new full-speed USB device number 10 using ohci-pci
[   17.801758] usb 9-1: device descriptor read/64, error -62
[   18.030814] usb 9-1: device descriptor read/64, error -62
[   18.254834] usb 9-1: new full-speed USB device number 11 using ohci-pci
[   18.382858] usb 9-1: device descriptor read/64, error -62
[   18.611902] usb 9-1: device descriptor read/64, error -62
[   18.835977] usb 9-1: new full-speed USB device number 12 using ohci-pci
[   19.240034] usb 9-1: device not accepting address 12, error -62
[   19.363101] usb 9-1: new full-speed USB device number 13 using ohci-pci
[   19.767182] usb 9-1: device not accepting address 13, error -62
[   19.767226] usb usb9-port1: unable to enumerate USB device

That particular example was just a cheap USB memory card-reader....I don't really care about it.

The more important issue to me is that the Quad DVB-T receiver on my mythtv backend box is also subject to the same problem, so I'm unable to upgrade that machine past 3.19 at the moment. This is a PCI-e card, that looks like it's some kind of pci-e to usb bridge, and the DVB tuners attached via usb. I'm not entirely sure but I think it might actually be a PCIe -> PCI -> USB card.

Here are the card's details on a working 3.19 kernel:

# lsusb | grep Leadtek
Bus 010 Device 005: ID 0413:6680 Leadtek Research, Inc. 
Bus 010 Device 004: ID 0413:6680 Leadtek Research, Inc. 
Bus 010 Device 003: ID 0413:6680 Leadtek Research, Inc. 
Bus 010 Device 002: ID 0413:6680 Leadtek Research, Inc. 

# dmesg | grep -i DigitalNow| grep pci
[    9.405568] input: DigitalNow Quad DVB-T Receiver as /devices/pci0000:00/0000:00:0a.0/0000:04:00.0/0000:05:00.2/usb10/10-1/rc/rc1/input17
[    9.405687] rc1: DigitalNow Quad DVB-T Receiver as /devices/pci0000:00/0000:00:0a.0/0000:04:00.0/0000:05:00.2/usb10/10-1/rc/rc1
[    9.475939] input: DigitalNow Quad DVB-T Receiver as /devices/pci0000:00/0000:00:0a.0/0000:04:00.0/0000:05:00.2/usb10/10-2/rc/rc2/input22
[    9.476049] rc2: DigitalNow Quad DVB-T Receiver as /devices/pci0000:00/0000:00:0a.0/0000:04:00.0/0000:05:00.2/usb10/10-2/rc/rc2
[    9.542441] input: DigitalNow Quad DVB-T Receiver as /devices/pci0000:00/0000:00:0a.0/0000:04:00.0/0000:05:00.2/usb10/10-3/rc/rc3/input24
[    9.542617] rc3: DigitalNow Quad DVB-T Receiver as /devices/pci0000:00/0000:00:0a.0/0000:04:00.0/0000:05:00.2/usb10/10-3/rc/rc3
[    9.609134] input: DigitalNow Quad DVB-T Receiver as /devices/pci0000:00/0000:00:0a.0/0000:04:00.0/0000:05:00.2/usb10/10-4/rc/rc4/input26
[    9.609289] rc4: DigitalNow Quad DVB-T Receiver as /devices/pci0000:00/0000:00:0a.0/0000:04:00.0/0000:05:00.2/usb10/10-4/rc/rc4

# lspci | grep '^0[45]:'
04:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa)
05:00.0 USB controller: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller (rev 62)
05:00.1 USB controller: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller (rev 62)
05:00.2 USB controller: VIA Technologies, Inc. USB 2.0 (rev 65)

# lspci -vv -s 05:00
05:00.0 USB controller: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller (rev 62) (prog-if 00 [UHCI])
    Subsystem: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
    Latency: 32, Cache Line Size: 64 bytes
    Interrupt: pin A routed to IRQ 26
    Region 4: I/O ports at d020 [size=32]
    Capabilities: [80] Power Management version 2
        Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
        Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
    Kernel driver in use: uhci_hcd

    05:00.1 USB controller: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller (rev 62) (prog-if 00 [UHCI])
        Subsystem: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32, Cache Line Size: 64 bytes
        Interrupt: pin B routed to IRQ 41
        Region 4: I/O ports at d000 [size=32]
        Capabilities: [80] Power Management version 2
            Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
            Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: uhci_hcd

    05:00.2 USB controller: VIA Technologies, Inc. USB 2.0 (rev 65) (prog-if 20 [EHCI])
        Subsystem: VIA Technologies, Inc. USB 2.0 Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 32, Cache Line Size: 64 bytes
        Interrupt: pin C routed to IRQ 50
        Region 0: Memory at fe500000 (32-bit, non-prefetchable) [size=256]
        Capabilities: [80] Power Management version 2
            Flags: PMEClk+ DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
            Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: ehci-pci

So, what's changed in the kernel USB drivers recently? Is this a bug, or is it a configuration issue?

Several kernel versions ago (3.8), USB stuff changed so that ehci-hcd had to be loaded before ehci-pci. initramfs-tools has since been upgraded to handle that automatically, but i still have the commented out remnants of the workaround in my /etc/modules file:

# make sure ehci-pci loads immediately after ehci-hcd for kernel 3.8
# (should be handled automagically by initramfs-tools 0.110 now)
#ehci-hcd
#ehci-pci

Is this a similar situation, that can be handled by loading drivers in a particular order or by blacklisting certain obsolete drivers?


Some more hardware and software details:

This has occurred on several machines including:

  • Asus M4A89TD PRO USB3 motherboard with AMD Phenom II X6 1090T Processor (workstation)
  • Asus M5A97 with AMD Phenom II X6 1090T Processor (myth frontend)
  • Asus Sabertooth 990FX with AMD Phenom II X6 1090T Processor (workstation and server)
  • Asus Sabertooth 990FX with AMD FX(tm)-8150 Eight-Core Processor (myth backend)

The last one, with the FX-8150 (which is what i had lying around when the previous motherboard died and i had to rebuild it), is the myth box with the DigitalNow Quad DVB-T Receiver. The first one, the M4A89TD Pro, is the machine with the cheap USB memory card-reader.

All have at least 8GB RAM, and all have either nvidia GTX-750 (myth boxes) or GTX-560 or GTX-560Ti GPUs, using the proprietary nvidia driver. All are running Debian sid, with recent kernels (4.2.x on everything but the myth backend as that's the only one where USB is important for anything but HID - USB kbd and mouse and even a wacom tablet work fine, BTW, on 4.0+ kernels).

All machines boot off 128-256GB SSDs in RAID-1 using XFS for / and ext4 for /boot. The mythtv backend is also running zfsonlinux for bulk storage. As is the combined workstation/server.

I have tried debian stock kernels, liquorix kernels, and custom-compiled kernels. All with the same result: up to 3.19 is fine. 4.0 and later breaks my DVB-T receiver and my memory-card reader.


Please note: I am not after general knowledge, or information that can be found in five minutes with google. I am after specific information about any known USB (or other possibly related) regressions in 4.0+ kernels and, with luck, a patch or workaround.

  • Do you run static or dynamic kernel? Dynamic means with modules. If you run dynamic, try to boot into something like minimal environment (kernel+initramfs that offers shell prompt instantly) with fully statically compiled kernel and try your devices. If they still fail, file a bug at kernel bugzilla. – user140866 Nov 9 '15 at 6:19
  • i use modules. as is obvious from my mention of /etc/modules. linking the modules into the kernel statically will make no difference and will likely make things worse by giving me no opportunity to change the order that the modules are loaded. – cas Nov 9 '15 at 6:31
  • update: I just tried linux kernel 4.3 on the box with the multi-card reader. no change, still broken. – cas Nov 9 '15 at 11:38
  • If it's still broken on 4.3 you can fairly safely assume that nobody is seeing the issue or reporting the bug. Most bugs are fixed by the .3 release of the major kernel cycle. So the regression is built in, and won't go away without someone taking the time to provide the driver maintainer with all the data they require to resolve the issue, if they can resolve it. If they do not have the device, you may be in trouble, because it's very very hard to debug hardware issues when the debugging person doesn't have it. – Lizardx Nov 9 '15 at 23:59
  • cas, do you actually required to upgrade? If I faced such an issue which is hard to resolve right now, I would just stuck with old and working kernel. What remaining issues push you to upgrade? (just after reading comments under Lizardx answer) – user140866 Nov 10 '15 at 4:45
1

This sounds like a kernel regression in 4.x Linux, at least for your specific hardware.

http://archlinuxarm.org/forum/viewtopic.php?f=53&t=8798

It may be in this commit, but it's hard to say since you didn't provide any further information about your system.

https://github.com/torvalds/linux/commit/a0b5cd4ac2d6542d524d8063961bf914b5df1efa

Some systems apparently are seeing issues with at least USB 3: https://lists.debian.org/debian-kernel/2015/08/msg00066.html

So the real question is, what is your hardware, and what is the latest 4.x kernel you have tried. This may have been resolved in a recent 4.x release. Is the issue with usb 2 and 3, or just 3, or not related to usb version? That will help narrow it down. Your data looks like it's just usb2 max on your system.

Kernel regressions are normal.

As I tell people when they ask this type of question, a new linux kernel has several possible outcomes:

  1. something that didn't work before works now
  2. everything stayed the same on your system
  3. something that worked before, stopped working
  4. some things got better, and some things stopped working

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1455376 That's an Ubuntu bug with usb handling.

Usually bugs that impact things a lot of people use will get fixed relatively rapidly, so it's worth checking the latest release of the latest stable kernel, which I think is at 4.3 at the moment.

If you use ubuntu, you can run the liquorix kernel, at least if it's current ubuntu, not LTS, same for debian, non stable releases.

Seeing: inxi -bxxx would be helpful to show the basics of your system. inxi is installable from most distro repositories.

Here's Greg KH's list of USB changes for 4.0 / 3.20

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e29876723f7cb7728f0d6a674d23f92673e9f112

  usb: musb: fix device hotplug behind hub
  usb: dwc2: Fix a bug in reading the endpoint directions from reg.
  staging: emxx_udc: fix the build error
  usb: Retry port status check on resume to work around RH bugs
  Revert "usb: Reset USB-3 devices on USB-3 link bounce"
  uhci-hub: use HUB_CHAR_*
  usb: kconfig: replace PPC_OF with PPC
  ehci-pci: disable for Intel MID platforms (update)
  usb: gadget: Kconfig: use bool instead of boolean
  usb: musb: blackfin: remove incorrect __exit_p()
  USB: fix use-after-free bug in usb_hcd_unlink_urb()
  ehci-pci: disable for Intel MID platforms
  usb: host: pci_quirks: joing string literals
  USB: add flag for HCDs that can't receive wakeup requests (isp1760-hcd)
  USB: usbfs: allow URBs to be reaped after disconnection
  cdc-acm: kill unnecessary messages
  cdc-acm: add sanity checks
  usb: phy: phy-generic: Fix USB PHY gpio reset
  usb: dwc2: fix USB core dependencies
  usb: renesas_usbhs: fix NULL pointer dereference in dma_release_channel()

http://kernelnewbies.org/Linux_4.0 shows the full change set.

https://lkml.org/lkml/2015/6/26/511 that's the changes in USB for 4.2-rc1. As you can see, asking 'what has changed' is not probably the exact right question, more useful would be to determine if the issue has been resolved for your hardware yet in the latest releases.

  • 1
    You're really not telling me anything I don't already know, this is all just general knowledge / basic googling stuff. I need specific information about changes/bugs/regression in 4.0 and later kernels...and hopefully a pointer to a patch or at least a workaround. The launchpad bug report is clearly about a different problem as it refers to the bug being present in 3.18 whereas mine is OK on everything up to 3.19 but not on 4.0 or later. The most recent kernel I have tried is 4.2 on Wed Sep 30. When i have time to reboot my myth box I'll try 4.3 but i'm not expecting any improvement. – cas Nov 9 '15 at 8:07
  • OTOH, the mention of the PCI-e bug is interesting and worth following up...although it's way back in April and probably already in 4.2 (which i have tried). According to github.com/ljalves/linux_media/issues/107 it was fixed in git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/… for 4.16 – cas Nov 9 '15 at 8:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.