O que mudou com os drivers USB nos kernels Linux 4.0 e posteriores?

7

Com kernels até 3,19, todos os meus dispositivos USB funcionam perfeitamente.

Ao atualizar para o 4.0 ou posterior, alguns dos meus dispositivos USB param de funcionar e o kernel produz erros 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

Esse exemplo em particular era apenas um leitor de cartão de memória USB barato ... Eu realmente não me importo com isso.

A questão mais importante para mim é que o receptor Quad DVB-T na minha caixa de backend do mythtv também está sujeito ao mesmo problema, por isso não posso atualizar essa máquina além de 3,19 no momento. Esta é uma placa PCI-e, que parece ser uma espécie de pci-e para ponte usb, e os sintonizadores DVB conectados via usb. Eu não tenho certeza, mas acho que pode realmente ser um PCIe - > PCI - > Cartão USB.

Aqui estão os detalhes da carta em um kernel 3.19 funcional:

# 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

Então, o que mudou nos drivers USB do kernel recentemente? Isso é um bug ou é um problema de configuração?

Várias versões do kernel atrás (3.8), coisas USB foram alteradas, então ehci-hcd teve que ser carregado antes de ehci-pci . initramfs-tools foi atualizado para lidar com isso automaticamente, mas ainda tenho os restos comentados da solução alternativa no meu arquivo /etc/modules :

# 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

Esta é uma situação semelhante, que pode ser tratada com o carregamento de drivers em uma ordem específica ou com a inclusão de determinados drivers obsoletos na lista negra?

Mais alguns detalhes de hardware e software:

Isso ocorreu em várias máquinas, incluindo:

  • Placa-mãe Asus M4A89TD PRO USB3 com processador AMD Phenom II X6 1090T (estação de trabalho)
  • Asus M5A97 com Processador AMD Phenom II X6 1090T (frontend mito)
  • Asus Sabertooth 990FX com processador AMD Phenom II X6 1090T (estação de trabalho e servidor)
  • Asus Sabertooth 990FX com processador AMD FX (tm) -8150 de oito núcleos (backend mito)

O último, com o FX-8150 (que é o que eu tinha por aí quando a placa-mãe anterior morreu e eu tive que reconstruí-lo), é a caixa mítica com o DigitalNow Quad DVB-T Receiver. O primeiro, o M4A89TD Pro, é a máquina com o leitor de cartão de memória USB barato.

Todos têm pelo menos 8 GB de RAM, e todos têm GPUs nvidia GTX-750 (mito boxes) ou GTX-560 ou GTX-560Ti, usando o driver nvidia proprietário. Todos estão rodando o Debian sid, com kernels recentes (4.2.x em tudo, menos o backend do mito, que é o único em que o USB é importante para qualquer coisa, mas HID - USB kbd e mouse e até um tablet wacom funcionam bem, BTW, em 4.0+ kernels).

Todas as máquinas inicializam SSDs de 128-256 GB em RAID-1 usando XFS para / e ext4 para / boot. O backend do mythtv também está executando o zfsonlinux para armazenamento em massa. Como é a estação de trabalho / servidor combinados.

Eu tentei kernels de estoque debian, kernels liquorix e kernels compilados. Tudo com o mesmo resultado: até 3,19 está bem. 4.0 e posteriores quebre meu receptor DVB-T e meu leitor de cartão de memória.

Por favor, note: Eu não estou atrás de conhecimentos gerais, ou informações que podem ser encontradas em cinco minutos com o google. Estou atrás de informações específicas sobre quaisquer regressões USB (ou outras possivelmente relacionadas) conhecidas em núcleos 4.0+ e, com sorte, um patch ou solução alternativa.

    
por cas 30.10.2015 / 00:47

1 resposta

1

Isso soa como uma regressão do kernel no Linux 4.x, pelo menos para o seu hardware específico.

link

Pode ser neste commit, mas é difícil dizer, já que você não forneceu mais nenhuma informação sobre o seu sistema.

link

Alguns sistemas aparentemente estão vendo problemas com pelo menos USB 3: link

A verdadeira questão é, qual é o seu hardware e qual é o kernel 4.x mais recente que você já tentou. Isso pode ter sido resolvido em uma versão 4.x recente. É o problema com usb 2 e 3, ou apenas 3, ou não relacionados à versão usb? Isso ajudará a reduzi-lo. Seus dados parecem apenas usb2 max no seu sistema.

As regressões do kernel são normais.

Como eu digo às pessoas quando elas fazem esse tipo de pergunta, um novo kernel do Linux tem vários resultados possíveis:

  1. algo que não funcionou antes de funcionar agora
  2. tudo permaneceu o mesmo no seu sistema
  3. algo que funcionou antes, parou de funcionar
  4. algumas coisas melhoraram e algumas coisas pararam de funcionar

link Isso é um bug do Ubuntu com manipulação usb.

Geralmente bugs que afetam as coisas que muitas pessoas usam serão corrigidos de forma relativamente rápida, então vale a pena conferir a versão mais recente do kernel estável mais recente, que eu acho que está em 4.3 no momento.

Se você usa o Ubuntu, você pode rodar o kernel do liquorix, pelo menos se ele for atual, não LTS, mesmo para versões não-estáveis do Debian.

Vendo: inxi -bxxx seria útil para mostrar as noções básicas do seu sistema. inxi é instalável a partir da maioria dos repositórios de distribuição.

Veja a lista de mudanças USB de Greg KH para 4.0 / 3.20

link

  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()
O

link mostra o conjunto completo de alterações.

link são as mudanças no USB para o 4.2-rc1. Como você pode ver, perguntar "o que mudou" não é provavelmente a pergunta certa, mais útil seria determinar se o problema foi resolvido para o seu hardware ainda nos últimos lançamentos.

    
por 09.11.2015 / 08:10