Cosa è cambiato con i driver USB nei kernel Linux 4.0 e successivi?

8

Con kernel fino a 3.19, tutti i miei dispositivi USB funzionano perfettamente.

Durante l'aggiornamento a 4.0 o versioni successive, alcuni dei miei dispositivi USB smettono di funzionare e il kernel produce errori come questo:

[    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

Quel particolare esempio era solo un lettore di schede di memoria USB economico ... Non mi interessa davvero.

Il problema più importante per me è che anche il ricevitore Quad DVB-T sulla mia scatola backend Mythtv è soggetto allo stesso problema, quindi al momento non riesco ad aggiornare quella macchina oltre le 3.19. Questa è una scheda PCI-e, che sembra una specie di bridge da PCI a USB, e sintonizzatori DVB collegati via USB. Non ne sono del tutto sicuro, ma penso che in realtà potrebbe essere una scheda USB PCIe -> PCI ->.

Ecco i dettagli della carta su un kernel 3.19 funzionante:

# 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

Quindi, cosa è cambiato di recente nei driver USB del kernel? È un bug o è un problema di configurazione?

Diverse versioni del kernel fa (3.8), le cose USB sono cambiate e quindi ehci-hcddovevano essere caricate prima ehci-pci. initramfs-toolsda allora è stato aggiornato per gestirlo automaticamente, ma ho ancora i commenti commentati della soluzione alternativa nel mio /etc/modulesfile:

# 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

Si tratta di una situazione simile, che può essere gestita caricando i driver in un ordine particolare o inserendo nella blacklist alcuni driver obsoleti?

Alcuni dettagli hardware e software:

Ciò si è verificato su diverse macchine tra cui:

  • Scheda madre Asus M4A89TD PRO USB3 con processore AMD Phenom II X6 1090T (workstation)
  • Asus M5A97 con processore AMD Phenom II X6 1090T (mito frontend)
  • Asus Sabertooth 990FX con processore AMD Phenom II X6 1090T (workstation e server)
  • Asus Sabertooth 990FX con processore a otto core AMD FX (tm) -8150 (mito backend)

L'ultimo, con l'FX-8150 (che è quello che avevo in giro quando la precedente scheda madre è morta e ho dovuto ricostruirla), è la scatola del mito con il ricevitore DVB-T DigitalNow Quad. Il primo, M4A89TD Pro, è la macchina con il lettore di schede di memoria USB economico.

Tutti hanno almeno 8 GB di RAM e tutti hanno GPU nvidia GTX-750 (scatole mitiche) o GTX-560 o GTX-560Ti, usando il driver proprietario nvidia. Tutti eseguono Debian Sid, con kernel recenti (4.2.x su tutto tranne il mito backend in quanto è l'unico in cui USB è importante per tutto tranne HID - USB kbd e mouse e persino un tablet Wacom funzionano bene, BTW, su 4.0+ kernel).

Tutte le macchine si avviano da SSD da 128-256 GB in RAID-1 usando XFS per / e ext4 per / boot. Il backend mythtv esegue anche zfsonlinux per l'archiviazione di massa. Come è la workstation / server combinati.

Ho provato kernel kernel debian, kernel liquorix e kernel compilati su misura. Tutti con lo stesso risultato: fino a 3,19 va bene. 4.0 e successive interrompe il mio ricevitore DVB-T e il mio lettore di schede di memoria.

Nota: non sto cercando conoscenze generali o informazioni che possono essere trovate in cinque minuti con google. Sto cercando informazioni specifiche su eventuali regressioni USB note (o altre possibili correlazioni) nei kernel 4.0+ e, per fortuna, una patch o una soluzione alternativa.

linux  kernel  usb  dvb 
— cas
fonte
Esegui kernel statici o dinamici? Dinamico significa con i moduli. Se si esegue in modo dinamico, provare ad eseguire l'avvio in qualcosa di simile a un ambiente minimo (kernel + initramfs che offre immediatamente il prompt della shell) con un kernel completamente compilato staticamente e provare i propri dispositivi. Se falliscono ancora, invia un bug al kernel bugzilla.
io uso i moduli. come è ovvio dalla mia menzione /etc/modules. il collegamento statico dei moduli nel kernel non farà alcuna differenza e probabilmente peggiorerà le cose non dandomi l'opportunità di cambiare l'ordine di caricamento dei moduli.
— Cas
aggiornamento: ho appena provato Linux kernel 4.3 sulla confezione con il lettore multi-card. nessun cambiamento, ancora rotto.
— Caso
Se è ancora rotto su 4.3, puoi tranquillamente supporre che nessuno stia vedendo il problema o stia segnalando il bug. La maggior parte dei bug sono stati corretti dalla versione .3 del ciclo del kernel principale. Quindi la regressione è integrata e non andrà via senza che qualcuno si prenda il tempo di fornire al manutentore del driver tutti i dati necessari per risolvere il problema, se possono risolverlo. Se non hanno il dispositivo, potresti essere nei guai, perché è molto difficile eseguire il debug di problemi hardware quando la persona di debug non lo possiede.
— Lizardx,
cas, hai effettivamente richiesto l'aggiornamento? Se dovessi affrontare un problema del genere che è difficile da risolvere in questo momento , mi limiterei a utilizzare il kernel vecchio e funzionante. Quali problemi rimanenti ti spingono ad aggiornare? (subito dopo aver letto i commenti nella risposta di Lizardx)

Risposte:

1

Sembra una regressione del kernel in Linux 4.x, almeno per il tuo hardware specifico.

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

Potrebbe essere in questo commit, ma è difficile da dire poiché non hai fornito ulteriori informazioni sul tuo sistema.

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

Apparentemente alcuni sistemi stanno riscontrando problemi con almeno USB 3: https://lists.debian.org/debian-kernel/2015/08/msg00066.html

Quindi la vera domanda è: qual è il tuo hardware e qual è l'ultimo kernel 4.x che hai provato. Questo potrebbe essere stato risolto in una recente versione 4.x. Il problema con USB 2 e 3, o solo 3, o non è correlato alla versione USB? Ciò contribuirà a restringerlo. I tuoi dati sembrano solo usb2 max sul tuo sistema.

Le regressioni del kernel sono normali.

Come dico alle persone quando fanno questo tipo di domanda, un nuovo kernel Linux ha diversi possibili risultati:

  1. qualcosa che non ha funzionato prima funziona ora
  2. tutto è rimasto uguale sul tuo sistema
  3. qualcosa che ha funzionato prima, ha smesso di funzionare
  4. alcune cose sono migliorate e alcune hanno smesso di funzionare

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1455376 Questo è un bug di Ubuntu con gestione USB.

Di solito i bug che incidono su cose che molte persone usano vengono corretti in modo relativamente rapido, quindi vale la pena controllare l'ultima versione dell'ultimo kernel stabile, che credo sia al momento 4.3.

Se usi Ubuntu, puoi eseguire il kernel liquorix, almeno se è Ubuntu corrente, non LTS, lo stesso per le versioni debian e non stabili.

Vedendo: inxi -bxxx sarebbe utile per mostrare le basi del tuo sistema. inxi è installabile dalla maggior parte dei repository distro.

Ecco l'elenco delle modifiche USB di Greg KH per 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 mostra il set completo di modifiche.

https://lkml.org/lkml/2015/6/26/511 sono le modifiche in USB per 4.2-rc1. Come puoi vedere, chiedere "cosa è cambiato" non è probabilmente la domanda esatta, ma sarebbe più utile determinare se il problema è stato risolto per l'hardware nelle ultime versioni.

— Lizardx
fonte
1
Non mi stai davvero dicendo nulla che non conosco già, questa è solo conoscenza generale / roba googling di base. Ho bisogno di informazioni specifiche su modifiche / bug / regressione in kernel 4.0 e successivi ... e, si spera, un puntatore a una patch o almeno una soluzione alternativa. La segnalazione di bug del launchpad riguarda chiaramente un problema diverso in quanto si riferisce al bug presente in 3.18 mentre il mio è OK su tutto fino a 3.19 ma non su 4.0 o versioni successive. Il kernel più recente che ho provato è il 4.2 di mercoledì 30 settembre. Quando avrò il tempo di riavviare la mia scatola dei miti, proverò 4.3 ma non mi aspetto alcun miglioramento.
— Caso
OTOH, la menzione del bug PCI-e è interessante e vale la pena seguirla ... anche se è di ritorno ad aprile e probabilmente già nella 4.2 (che ho provato). Secondo github.com/ljalves/linux_media/issues/107 è stato corretto in git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/… per 4.16
— cas
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.