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

8

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

Ao atualizar para a versã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 foi 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 mythtv também está sujeito ao mesmo problema, por isso não consigo atualizar essa máquina além das 3.19 no momento. Esta é uma placa PCI-e, que parece algum tipo de ponte pci-e para usb e os sintonizadores DVB conectados via usb. Não tenho muita certeza, mas acho que pode ser realmente uma placa PCIe -> PCI -> USB.

Aqui estão os detalhes da placa em um kernel 3.19 em funcionamento:

# 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), o material USB foi alterado para que ehci-hcdtivesse que ser carregado antes ehci-pci. initramfs-toolsdesde então, foi atualizado para lidar com isso automaticamente, mas ainda tenho os remanescentes comentados da solução alternativa no meu /etc/modulesarquivo:

# 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

Essa é uma situação semelhante, que pode ser tratada carregando os drivers em uma ordem específica ou colocando na lista negra certos drivers obsoletos?

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 do 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 era o que eu tinha quando a placa-mãe anterior morreu e tive que reconstruí-lo), é a caixa de mitos do 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 (caixas míticas) ou GPX GTX-560 ou GTX-560Ti, usando o driver proprietário da nvidia. Todos estão executando o Debian sid, com kernels recentes (4.2.x em tudo, menos no backend de mitos, pois esse é o único onde o USB é importante para qualquer coisa, exceto HID - kbd e mouse USB e até mesmo um tablet wacom funcionam bem, BTW, no 4.0+ grãos).

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

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

Observação: não busco conhecimentos gerais ou informações que possam ser encontradas em cinco minutos com o google. Estou atrás de informações específicas sobre quaisquer regressões conhecidas de USB (ou outras possíveis relacionadas) em mais de 4.0 kernels e, com sorte, um patch ou solução alternativa.

linux kernel usb dvb cas
fonte
Você executa o kernel estático ou dinâmico? Dinâmico significa com módulos. Se você executar dinâmico, tente inicializar em algo como um ambiente mínimo (kernel + initramfs que oferece prompt de shell instantaneamente) com o kernel totalmente compilado estaticamente e tente seus dispositivos. Se eles ainda falharem, registre um bug no bugzilla do kernel.
eu uso módulos. como é óbvio da minha menção /etc/modules. vincular estaticamente os módulos ao kernel não fará diferença e provavelmente piorará as coisas, não me dando a oportunidade de alterar a ordem em que os módulos são carregados.
cas
atualização: Eu apenas tentei o linux kernel 4.3 na caixa com o leitor de cartões múltiplos. sem mudança, ainda quebrado.
cas
Se ainda estiver quebrado no 4.3, você pode assumir com segurança que ninguém está vendo o problema ou relatando o bug. A maioria dos bugs é corrigida pela versão .3 do ciclo principal do kernel. Portanto, a regressão é incorporada e não desaparece sem que alguém reserve um tempo para fornecer ao mantenedor do driver todos os dados necessários para resolver o problema, se puderem resolvê-lo. Se eles não tiverem o dispositivo, você pode estar com problemas, porque é muito difícil depurar problemas de hardware quando a pessoa que o depura não o possui.
Lizardx
cas, você realmente precisa atualizar? Se eu enfrentasse um problema difícil de resolver no momento , eu continuaria com o kernel antigo e funcionando. Quais problemas restantes levam você a atualizar? (apenas depois de ler comentários em Lizardx resposta)

Respostas:

1

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

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

Pode estar nesse commit, mas é difícil dizer que você não forneceu mais informações sobre o seu sistema.

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

Aparentemente, alguns sistemas estão tendo problemas com pelo menos o USB 3: https://lists.debian.org/debian-kernel/2015/08/msg00066.html

Portanto, a verdadeira questão é: qual é o seu hardware e qual é o kernel 4.x mais recente que você 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 está relacionado à versão usb? Isso ajudará a reduzi-lo. Seus dados parecem ser apenas usb2 max no seu sistema.

Regressões de kernel são normais.

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

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

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1455376 Esse é um bug do Ubuntu com manipulação de usb.

Normalmente, os bugs que afetam as coisas que muitas pessoas usam são corrigidos com relativa rapidez, portanto vale a pena conferir a versão mais recente do kernel estável mais recente, que eu acho que é de 4,3 no momento.

Se você usa o ubuntu, pode executar o kernel liquorix, pelo menos se for o ubuntu atual, não o LTS, o mesmo para versões não estáveis ​​do debian.

Ver: inxi -bxxx seria útil para mostrar o básico do seu sistema. O inxi é instalável na maioria dos repositórios de distribuição.

Aqui está a lista de alterações 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 mostra o conjunto completo de alterações.

https://lkml.org/lkml/2015/6/26/511, que são as alterações no USB para 4.2-rc1. Como você pode ver, perguntar 'o que mudou' provavelmente não é a pergunta exata exata, mais útil seria determinar se o problema foi resolvido para o seu hardware ainda nas versões mais recentes.

Lizardx
fonte
1
Você realmente não está me dizendo nada que eu ainda não saiba, isso é apenas conhecimento geral / material básico de pesquisa no Google. Preciso de informações específicas sobre alterações / erros / regressão nos kernels 4.0 e posteriores ... e espero que seja um ponteiro para um patch ou pelo menos uma solução alternativa. O relatório de erros da barra de ativação é claramente sobre um problema diferente, pois se refere ao erro presente na 3.18, enquanto o meu está bom em tudo até 3.19, mas não na 4.0 ou posterior. O kernel mais recente que tentei é o 4.2 em Wed, 30 de setembro. Quando tiver tempo para reiniciar minha caixa de mitos, tentarei 4.3, mas não estou esperando nenhuma melhoria.
cas
OTOH, a menção do bug PCI-e é interessante e vale a pena acompanhar ... embora seja em abril e provavelmente já no 4.2 (o que eu tentei). De acordo com github.com/ljalves/linux_media/issues/107 foi fixado em git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/... para 4,16
cas