¿Qué ha cambiado con los controladores USB en los núcleos Linux 4.0 y posteriores?

8

Con núcleos de hasta 3.19, todos mis dispositivos USB funcionan perfectamente.

Al actualizar a 4.0 o posterior, algunos de mis dispositivos USB dejan de funcionar y el núcleo produce errores como este:

[    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

Ese ejemplo en particular fue solo un lector de tarjetas de memoria USB barato ... Realmente no me importa.

El problema más importante para mí es que el receptor Quad DVB-T en mi caja de back-end de mythtv también está sujeto al mismo problema, por lo que no puedo actualizar esa máquina más allá de 3.19 en este momento. Esta es una tarjeta PCI-e, parece que es una especie de puente pci-e a usb, y los sintonizadores DVB conectados a través de usb. No estoy completamente seguro, pero creo que en realidad podría ser una tarjeta PCIe -> PCI -> USB.

Aquí están los detalles de la tarjeta en un kernel 3.19 en funcionamiento:

# 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

Entonces, ¿qué ha cambiado recientemente en los controladores USB del núcleo? ¿Es esto un error o es un problema de configuración?

Hace varias versiones del kernel (3.8), las cosas de USB cambiaron, por lo que ehci-hcdtuvieron que cargarse antes ehci-pci. initramfs-toolsdesde entonces se ha actualizado para manejar eso automáticamente, pero todavía tengo los restos comentados de la solución en mi /etc/modulesarchivo:

# 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

¿Es esta una situación similar, que puede manejarse cargando controladores en un orden particular o colocando en la lista negra a ciertos controladores obsoletos?

Algunos detalles más de hardware y software:

Esto ha ocurrido en varias máquinas, incluyendo:

  • Placa madre Asus M4A89TD PRO USB3 con procesador AMD Phenom II X6 1090T (estación de trabajo)
  • Asus M5A97 con procesador AMD Phenom II X6 1090T (interfaz de mito)
  • Asus Sabertooth 990FX con procesador AMD Phenom II X6 1090T (estación de trabajo y servidor)
  • Asus Sabertooth 990FX con procesador AMD FX (tm) -8150 de ocho núcleos (backend de mito)

El último, con el FX-8150 (que es lo que tenía por ahí cuando murió la placa base anterior y tuve que reconstruirlo), es la caja de mito con el receptor DigitalNow Quad DVB-T. El primero, el M4A89TD Pro, es la máquina con el lector de tarjetas de memoria USB barato.

Todos tienen al menos 8 GB de RAM y todos tienen GPU nvidia GTX-750 (cajas de mito) o GPX GTX-560 o GTX-560Ti, utilizando el controlador patentado nvidia. Todos están ejecutando Debian sid, con núcleos recientes (4.2.x en todo menos en el backend del mito, ya que es el único en el que el USB es importante para todo menos HID - USB kbd y mouse e incluso una tableta wacom funcionan bien, por cierto, en 4.0+ granos).

Todas las máquinas arrancan SSD de 128-256GB en RAID-1 usando XFS para / y ext4 para / boot. El backend de mythtv también ejecuta zfsonlinux para almacenamiento masivo. Como es la estación de trabajo / servidor combinados.

He probado los núcleos de stock de Debian, los núcleos de Liquorix y los núcleos compilados a medida. Todo con el mismo resultado: hasta 3.19 está bien. 4.0 y posterior rompe mi receptor DVB-T y mi lector de tarjetas de memoria.

Tenga en cuenta: no busco conocimientos generales o información que se pueda encontrar en cinco minutos con google. Busco información específica sobre cualquier regresión conocida de USB (u otra posiblemente relacionada) en núcleos 4.0+ y, con suerte, un parche o solución.

linux kernel usb dvb cas
fuente
¿Ejecutas kernel estático o dinámico? Medios dinámicos con módulos. Si ejecuta Dynamic, intente arrancar en un entorno mínimo (kernel + initramfs que ofrece un indicador de shell al instante) con un kernel totalmente compilado estáticamente y pruebe sus dispositivos. Si aún fallan, presente un error en kernel bugzilla.
Yo uso módulos. como es obvio por mi mención de /etc/modules. vincular los módulos al kernel estáticamente no hará ninguna diferencia y probablemente empeorará las cosas al no darme la oportunidad de cambiar el orden en que se cargan los módulos.
cas
actualización: acabo de probar linux kernel 4.3 en la caja con el lector de tarjetas múltiples. Sin cambios, todavía roto.
cas
Si todavía está roto en 4.3, puede asumir con bastante seguridad que nadie está viendo el problema o informando el error. La mayoría de los errores se corrigen con la versión .3 del ciclo principal del núcleo. Por lo tanto, la regresión está integrada y no desaparecerá sin que alguien se tome el tiempo para proporcionarle al encargado del controlador todos los datos que necesitan para resolver el problema, si pueden resolverlo. Si no tienen el dispositivo, puede estar en problemas, porque es muy difícil depurar problemas de hardware cuando la persona que lo depura no lo tiene.
Lizardx
cas, ¿realmente necesitas actualizar? Si me enfrentara a un problema que es difícil de resolver en este momento , simplemente me quedaría con el núcleo antiguo y en funcionamiento. ¿Qué problemas restantes te empujan a actualizar? (justo después de leer los comentarios bajo la respuesta de Lizardx)

Respuestas:

1

Esto suena como una regresión del kernel en 4.x Linux, al menos para su hardware específico.

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

Puede estar en esta confirmación, pero es difícil de decir ya que no proporcionó más información sobre su sistema.

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

Aparentemente, algunos sistemas tienen problemas con al menos USB 3: https://lists.debian.org/debian-kernel/2015/08/msg00066.html

Entonces, la verdadera pregunta es cuál es su hardware y cuál es el último kernel 4.x que ha probado. Esto puede haberse resuelto en una versión 4.x reciente. ¿El problema con usb 2 y 3, o solo 3, o no está relacionado con la versión usb? Eso ayudará a reducirlo. Parece que sus datos son solo usb2 max en su sistema.

Las regresiones del núcleo son normales.

Como le digo a la gente cuando hacen este tipo de preguntas, un nuevo kernel de Linux tiene varios resultados posibles:

  1. algo que no funcionaba antes funciona ahora
  2. todo permaneció igual en su sistema
  3. algo que funcionó antes, dejó de funcionar
  4. algunas cosas mejoraron y otras dejaron de funcionar

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1455376 Eso es un error de Ubuntu con manejo de usb.

Por lo general, los errores que afectan las cosas que mucha gente usa se solucionarán con relativa rapidez, por lo que vale la pena verificar la última versión del kernel estable más reciente, que creo que está en 4.3 en este momento.

Si usa ubuntu, puede ejecutar el kernel liquorix, al menos si es ubuntu actual, no LTS, lo mismo para Debian, versiones no estables.

Viendo: inxi -bxxx sería útil para mostrar los conceptos básicos de su sistema. inxi es instalable desde la mayoría de los repositorios de distribución.

Aquí está la lista de cambios de USB de Greg KH para 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 muestra el conjunto completo de cambios.

https://lkml.org/lkml/2015/6/26/511 esos son los cambios en USB para 4.2-rc1. Como puede ver, preguntar "qué ha cambiado" no es probablemente la pregunta correcta exacta, más útil sería determinar si el problema se ha resuelto para su hardware todavía en las últimas versiones.

Lagarto
fuente
1
Realmente no me estás diciendo nada que aún no sepa, todo esto es solo conocimiento general / cosas básicas de google. Necesito información específica sobre cambios / errores / regresión en los núcleos 4.0 y posteriores ... y con suerte un puntero a un parche o al menos una solución alternativa. El informe de error de launchpad es claramente sobre un problema diferente, ya que se refiere a que el error está presente en 3.18, mientras que el mío está bien en todo hasta 3.19 pero no en 4.0 o posterior. El kernel más reciente que probé es 4.2 el miércoles 30 de septiembre. Cuando tenga tiempo de reiniciar mi caja de mitos, intentaré 4.3 pero no espero ninguna mejora.
cas
OTOH, la mención del error PCI-e es interesante y vale la pena seguir ... aunque es en abril y probablemente ya en 4.2 (que he probado). De acuerdo con github.com/ljalves/linux_media/issues/107 , se arregló en git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/… para 4.16
cas el