Qu'est-ce qui a changé avec les pilotes USB dans les noyaux Linux 4.0 et ultérieurs?

8

Avec des noyaux jusqu'à 3,19, tous mes périphériques USB fonctionnent parfaitement.

Lors de la mise à niveau vers 4.0 ou version ultérieure, certains de mes périphériques USB cessent de fonctionner et le noyau produit des erreurs comme ceci:

[    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

Cet exemple particulier n'était qu'un lecteur de carte mémoire USB bon marché ... Je m'en fous vraiment.

Le problème le plus important pour moi est que le récepteur Quad DVB-T sur mon boîtier backend mythtv est également soumis au même problème, donc je ne suis pas en mesure de mettre à niveau cette machine après 3.19 pour le moment. Il s'agit d'une carte PCI-e, qui ressemble à une sorte de pont pci-e vers usb, et les tuners DVB connectés via usb. Je ne suis pas tout à fait sûr, mais je pense qu'il pourrait en fait s'agir d'une carte PCIe -> PCI -> USB.

Voici les détails de la carte sur un noyau 3.19 fonctionnel:

# 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

Alors, qu'est-ce qui a changé dans les pilotes USB du noyau récemment? Est-ce un bug ou un problème de configuration?

Il y a plusieurs versions du noyau (3.8), les éléments USB ont changé, ce qui ehci-hcda dû être chargé auparavant ehci-pci. initramfs-toolsa depuis été mis à niveau pour gérer cela automatiquement, mais j'ai toujours les restes commentés de la solution de contournement dans mon /etc/modulesfichier:

# 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

Est-ce une situation similaire, qui peut être gérée en chargeant les pilotes dans un ordre particulier ou en mettant sur liste noire certains pilotes obsolètes?

Quelques détails matériels et logiciels supplémentaires:

Cela s'est produit sur plusieurs machines, notamment:

  • Carte mère Asus M4A89TD PRO USB3 avec processeur AMD Phenom II X6 1090T (station de travail)
  • Asus M5A97 avec processeur AMD Phenom II X6 1090T (myth frontend)
  • Asus Sabertooth 990FX avec processeur AMD Phenom II X6 1090T (station de travail et serveur)
  • Asus Sabertooth 990FX avec processeur AMD FX (tm) -8150 à huit cœurs (mythe backend)

Le dernier, avec le FX-8150 (qui était ce que je traînais lorsque la carte mère précédente est morte et que j'ai dû la reconstruire), est la boîte mythique avec le récepteur DigitalNow Quad DVB-T. Le premier, le M4A89TD Pro, est la machine avec le lecteur de carte mémoire USB bon marché.

Tous ont au moins 8 Go de RAM et tous ont soit des GPU nvidia GTX-750 (boîtes mythiques), soit GTX-560 ou GTX-560Ti, en utilisant le pilote nvidia propriétaire. Tous utilisent Debian Sid, avec des noyaux récents (4.2.x sur tout sauf le backend mythique car c'est le seul où l'USB est important pour tout sauf HID - USB kbd et souris et même une tablette wacom fonctionnent bien, BTW, sur 4.0+ graines).

Toutes les machines démarrent des disques SSD de 128 à 256 Go en RAID-1 en utilisant XFS pour / et ext4 pour / boot. Le backend mythtv exécute également zfsonlinux pour le stockage en vrac. Tout comme le poste de travail / serveur combiné.

J'ai essayé les noyaux Debian, les noyaux Liquorix et les noyaux compilés sur mesure. Tous avec le même résultat: jusqu'à 3,19, c'est bien. 4.0 et versions ultérieures cassent mon récepteur DVB-T et mon lecteur de carte mémoire.

Remarque: je ne recherche pas de connaissances générales ou d'informations que vous pouvez trouver en cinq minutes avec google. Je recherche des informations spécifiques sur les régressions USB (ou autres éventuellement liées) connues dans les noyaux 4.0+ et, avec un peu de chance, un correctif ou une solution de contournement.

linux kernel usb dvb cas
la source
Exécutez-vous un noyau statique ou dynamique? Des moyens dynamiques avec des modules. Si vous exécutez dynamique, essayez de démarrer dans quelque chose comme un environnement minimal (noyau + initramfs qui offre une invite de shell instantanément) avec un noyau entièrement compilé statiquement et essayez vos appareils. S'ils échouent toujours, déposez un bogue sur bugzilla du noyau.
j'utilise des modules. comme il ressort de ma mention /etc/modules. la liaison statique des modules au noyau ne fera aucune différence et ne fera probablement qu'empirer les choses en ne me donnant aucune possibilité de changer l'ordre de chargement des modules.
cas
mise à jour: je viens d'essayer le noyau Linux 4.3 sur la boîte avec le lecteur multi-cartes. aucun changement, toujours cassé.
cas
S'il est toujours cassé en 4.3, vous pouvez supposer en toute sécurité que personne ne voit le problème ou ne signale le bogue. La plupart des bogues sont corrigés par la version .3 du cycle principal du noyau. Ainsi, la régression est intégrée et ne disparaîtra pas sans que quelqu'un prenne le temps de fournir au responsable du pilote toutes les données dont il a besoin pour résoudre le problème, s'il peut le résoudre. S'ils n'ont pas l'appareil, vous pouvez avoir des problèmes, car il est très difficile de déboguer des problèmes matériels lorsque la personne qui débogue ne l'a pas.
Lizardx
cas, avez-vous réellement besoin de mettre à niveau? Si je faisais face à un tel problème qui est difficile à résoudre en ce moment , je resterais coincé avec un noyau ancien et fonctionnel. Quels problèmes restants vous poussent à mettre à niveau? (juste après avoir lu les commentaires sous la réponse de Lizardx)

Réponses:

1

Cela ressemble à une régression du noyau sous Linux 4.x, au moins pour votre matériel spécifique.

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

Il peut être dans ce commit, mais c'est difficile à dire car vous n'avez fourni aucune information supplémentaire sur votre système.

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

Certains systèmes rencontrent apparemment des problèmes avec au moins USB 3: https://lists.debian.org/debian-kernel/2015/08/msg00066.html

La vraie question est donc de savoir quel est votre matériel et quel est le dernier noyau 4.x que vous avez essayé. Ce problème peut avoir été résolu dans une récente version 4.x. Le problème avec USB 2 et 3, ou seulement 3, ou n'est-il pas lié à la version USB? Cela aidera à le réduire. Vos données semblent être simplement usb2 max sur votre système.

Les régressions du noyau sont normales.

Comme je le dis aux gens quand ils posent ce type de question, un nouveau noyau Linux a plusieurs résultats possibles:

  1. quelque chose qui ne fonctionnait pas avant fonctionne maintenant
  2. tout est resté le même sur votre système
  3. quelque chose qui fonctionnait auparavant, a cessé de fonctionner
  4. certaines choses se sont améliorées et certaines choses ont cessé de fonctionner

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1455376 C'est un bogue Ubuntu avec la gestion USB.

Habituellement, les bogues qui affectent les choses que beaucoup de gens utilisent seront corrigés assez rapidement, il vaut donc la peine de vérifier la dernière version du dernier noyau stable, qui, je pense, est à 4.3 pour le moment.

Si vous utilisez ubuntu, vous pouvez exécuter le noyau liquorix, au moins si c'est ubuntu actuel, pas LTS, idem pour les versions debian non stables.

Voir: inxi -bxxx serait utile pour montrer les bases de votre système. inxi peut être installé à partir de la plupart des référentiels de distribution.

Voici la liste des changements USB de Greg KH pour 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 montre l'ensemble de modifications complet.

https://lkml.org/lkml/2015/6/26/511 c'est les changements dans l'USB pour 4.2-rc1. Comme vous pouvez le voir, demander `` ce qui a changé '' n'est probablement pas la bonne question, il serait plus utile de déterminer si le problème a été résolu pour votre matériel dans les dernières versions.

Lizardx
la source
1
Vous ne me dites vraiment rien que je ne sache pas déjà, ce ne sont que des connaissances générales / des choses de base sur Google. J'ai besoin d'informations spécifiques sur les changements / bogues / régression dans les noyaux 4.0 et ultérieurs ... et, espérons-le, un pointeur vers un correctif ou au moins une solution de contournement. Le rapport de bogue du tableau de bord concerne clairement un problème différent car il fait référence au bogue présent en 3.18 alors que le mien est OK sur tout jusqu'à 3.19 mais pas sur 4.0 ou version ultérieure. Le noyau le plus récent que j'ai essayé est 4.2 le mercredi 30 septembre. Quand j'aurai le temps de redémarrer ma boîte mythique, j'essaierai 4.3 mais je ne m'attends à aucune amélioration.
cas
OTOH, la mention du bug PCI-e est intéressante et mérite d'être suivie ... bien que ce soit en avril et probablement déjà en 4.2 (que j'ai essayé). Selon github.com/ljalves/linux_media/issues/107, il a été corrigé dans git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/… pour 4.16
cas