Was hat sich mit USB-Treibern in 4.0- und späteren Linux-Kerneln geändert?

Mit Kerneln bis 3.19 funktionieren alle meine USB-Geräte einwandfrei.

Beim Upgrade auf 4.0 oder höher funktionieren einige meiner USB-Geräte nicht mehr und der Kernel erzeugt folgende Fehler:

[    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

Dieses besondere Beispiel war nur ein billiger USB-Speicherkartenleser ... das interessiert mich nicht wirklich.

Das wichtigere Problem für mich ist, dass der Quad-DVB-T-Receiver auf meiner mythtv-Backend-Box ebenfalls dem gleichen Problem ausgesetzt ist, sodass ich diesen Computer derzeit nicht nach 3.19 aktualisieren kann. Dies ist eine PCI-e-Karte, die aussieht, als wäre sie eine Art PCI-E-zu-USB-Brücke, und die über USB angeschlossenen DVB-Tuner. Ich bin mir nicht ganz sicher, aber ich denke, es könnte tatsächlich eine PCIe -> PCI -> USB-Karte sein.

Hier sind die Details der Karte zu einem funktionierenden 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

Was hat sich in letzter Zeit in den Kernel-USB-Treibern geändert? Ist das ein Fehler oder ein Konfigurationsproblem?

Vor einigen Kernel-Versionen (3.8) wurde das USB-Material geändert, sodass es ehci-hcdzuvor geladen werden musste ehci-pci. initramfs-toolswurde seitdem aktualisiert, um dies automatisch zu handhaben, aber ich habe immer noch die auskommentierten Reste der Problemumgehung in meiner /etc/modulesDatei:

# 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

Ist dies eine ähnliche Situation, die durch Laden von Treibern in einer bestimmten Reihenfolge oder durch Auflisten bestimmter veralteter Treiber behoben werden kann?

Weitere Details zu Hardware und Software:

Dies ist auf mehreren Maschinen aufgetreten, darunter:

Asus M4A89TD PRO USB3-Motherboard mit AMD Phenom II X6 1090T-Prozessor (Workstation)
Asus M5A97 mit AMD Phenom II X6 1090T Prozessor (Mythos Frontend)
Asus Sabertooth 990FX mit AMD Phenom II X6 1090T Prozessor (Workstation und Server)
Asus Sabertooth 990FX mit AMD FX (tm) -8150 Acht-Kern-Prozessor (Mythos-Backend)

Der letzte mit dem FX-8150 (den ich herumliegen hatte, als das vorherige Motherboard starb und ich ihn neu bauen musste) ist die Mythos-Box mit dem DigitalNow Quad DVB-T-Empfänger. Der erste, der M4A89TD Pro, ist das Gerät mit dem billigen USB-Speicherkartenleser.

Alle haben mindestens 8 GB RAM und alle haben entweder nvidia GTX-750 (Mythos-Boxen) oder GTX-560- oder GTX-560Ti-GPUs, die den proprietären nvidia-Treiber verwenden. Auf allen läuft Debian Sid mit den neuesten Kerneln (4.2.x für alles außer dem Mythos-Backend, da dies das einzige ist, bei dem USB für alles andere als HID wichtig ist - USB kbd und Maus und sogar ein Wacom-Tablet funktionieren unter 4.0+ einwandfrei Kernel).

Alle Computer booten von 128-256 GB SSDs in RAID-1 mit XFS für / und ext4 für / boot. Das mythtv-Backend führt auch zfsonlinux für die Massenspeicherung aus. Wie ist die kombinierte Workstation / Server.

Ich habe Debian-Stock-Kernel, Liquorix-Kernel und benutzerdefinierte kompilierte Kernel ausprobiert. Alle mit dem gleichen Ergebnis: bis zu 3,19 ist in Ordnung. 4.0 und höher kaputt meinen DVB-T-Empfänger und meinen Speicherkartenleser.

Bitte beachten Sie: Ich bin nicht nach allgemeinen Kenntnissen oder Informationen, die in fünf Minuten mit Google gefunden werden können. Ich bin nach spezifischen Informationen über bekannte USB-Regressionen (oder andere möglicherweise verwandte Regressionen) in 4.0+ Kerneln und mit etwas Glück nach einem Patch oder einer Problemumgehung.

— cas
quelle

Führen Sie einen statischen oder dynamischen Kernel aus? Dynamisch heißt mit Modulen. Wenn Sie dynamisch arbeiten, versuchen Sie, mit einem vollständig statisch kompilierten Kernel in eine minimale Umgebung (Kernel + Initramfs, die sofort eine Shell-Eingabeaufforderung bietet) zu booten, und testen Sie Ihre Geräte. Wenn sie immer noch fehlschlagen, melden Sie einen Fehler bei Kernel Bugzilla.

Ich benutze Module. wie aus meiner Erwähnung von hervorgeht /etc/modules. Das statische Verknüpfen der Module mit dem Kernel macht keinen Unterschied und verschlimmert wahrscheinlich die Situation, da ich keine Möglichkeit habe, die Reihenfolge zu ändern, in der die Module geladen werden.

— Cas

Update: Ich habe gerade Linux Kernel 4.3 auf der Box mit dem Multi-Kartenleser ausprobiert. keine Veränderung, immer noch kaputt.

— Cas

Wenn es in 4.3 immer noch kaputt ist, können Sie ziemlich sicher davon ausgehen, dass niemand das Problem sieht oder den Fehler meldet. Die meisten Fehler werden durch die .3-Version des Hauptkernzyklus behoben. Die Regression ist also integriert und wird nicht verschwinden, ohne dass sich jemand die Zeit nimmt, dem Treiberbetreuer alle Daten zur Verfügung zu stellen, die er zur Behebung des Problems benötigt, wenn er es beheben kann. Wenn sie das Gerät nicht haben, können Sie in Schwierigkeiten geraten, da es sehr, sehr schwierig ist, Hardwareprobleme zu debuggen, wenn die Debugging-Person es nicht hat.

— Lizardx

cas, müssen Sie tatsächlich ein Upgrade durchführen? Wenn ich so ein Problem konfrontiert , die zu lösen ist schwer jetzt , würde ich nur mit alt und funktionierenden Kernel stecken. Welche verbleibenden Probleme veranlassen Sie zum Upgrade? (kurz nach dem Lesen der Kommentare unter Lizardx Antwort)

Dies klingt nach einer Kernel-Regression unter 4.x Linux, zumindest für Ihre spezifische Hardware.

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

Es kann in diesem Commit sein, aber es ist schwer zu sagen, da Sie keine weiteren Informationen über Ihr System angegeben haben.

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

Einige Systeme haben anscheinend Probleme mit mindestens USB 3: https://lists.debian.org/debian-kernel/2015/08/msg00066.html

Die eigentliche Frage ist also, was ist Ihre Hardware und was ist der neueste 4.x-Kernel, den Sie ausprobiert haben. Dies wurde möglicherweise in einer kürzlich veröffentlichten Version 4.x behoben. Ist das Problem mit USB 2 und 3 oder nur 3 oder nicht mit der USB-Version verbunden? Das wird helfen, es einzugrenzen. Ihre Daten scheinen auf Ihrem System nur USB2 Max zu sein.

Kernel-Regressionen sind normal.

Wie ich den Leuten sage, wenn sie diese Art von Frage stellen, hat ein neuer Linux-Kernel mehrere mögliche Ergebnisse:

etwas, das vorher nicht funktioniert hat, funktioniert jetzt
Auf Ihrem System ist alles gleich geblieben
etwas, das vorher funktionierte, hörte auf zu arbeiten
Einige Dinge wurden besser und andere funktionierten nicht mehr

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1455376 Das ist ein Ubuntu-Fehler bei der USB-Behandlung.

Normalerweise werden Fehler, die sich auf Dinge auswirken, die viele Leute verwenden, relativ schnell behoben. Es lohnt sich daher, die neueste Version des neuesten stabilen Kernels zu überprüfen, die meiner Meinung nach derzeit bei 4,3 liegt.

Wenn Sie Ubuntu verwenden, können Sie den Liquorix-Kernel ausführen, zumindest wenn es sich um aktuelles Ubuntu handelt, nicht um LTS, wie dies auch für nicht stabile Debian-Releases gilt.

Zu sehen: inxi -bxxx wäre hilfreich, um die Grundlagen Ihres Systems zu zeigen. inxi kann von den meisten Distribution-Repositories installiert werden.

Hier ist Greg KHs Liste der USB-Änderungen für 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 zeigt den vollständigen Änderungssatz.

https://lkml.org/lkml/2015/6/26/511 das sind die Änderungen in USB für 4.2-rc1. Wie Sie sehen, ist die Frage, was sich geändert hat, wahrscheinlich nicht genau die richtige Frage. Nützlicher wäre es, festzustellen, ob das Problem für Ihre Hardware in den neuesten Versionen bereits behoben wurde.

— Lizardx
quelle

Du erzählst mir wirklich nichts, was ich noch nicht weiß, das ist alles nur Allgemeinwissen / grundlegendes Googeln. Ich benötige spezifische Informationen zu Änderungen / Fehlern / Regressionen in 4.0- und späteren Kerneln ... und hoffentlich einen Zeiger auf einen Patch oder zumindest eine Problemumgehung. Der Launchpad-Fehlerbericht handelt eindeutig von einem anderen Problem, da er sich auf den Fehler bezieht, der in 3.18 vorhanden ist, während meiner in allen Fällen bis 3.19 in Ordnung ist, jedoch nicht in 4.0 oder höher. Der letzte Kernel, den ich ausprobiert habe, ist 4.2 am Mittwoch, 30. September. Wenn ich Zeit habe, meine Mythos-Box neu zu starten, werde ich 4.3 versuchen, aber ich erwarte keine Verbesserung.

— Cas

OTOH, die Erwähnung des PCI-e-Fehlers ist interessant und es lohnt sich, sie weiterzuverfolgen ... obwohl es schon im April und wahrscheinlich bereits in 4.2 (was ich versucht habe) ist. Nach github.com/ljalves/linux_media/issues/107 wurde in feste git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/... für 4,16

— cas