Instalando um Bridge Reversível PCIe-para-PCI sob resultados Debian em “dispositivo não-classificado”

Question

Instalei um Bridge Reversível PCIe-para-PCI que usa um chip Pericom Semiconductor PI7C9X111SL em um computador Debian. Esta placa PCIe hospeda 2 novos slots para placas PCI. O ID do PCI para essa ponte parece ser 12d8: e111. Estes são ("Pericom", "PI7C9X111SL", "12d8" & "e111") estão todos listados no arquivo de texto do Linux PCI:

/usr/share/misc/pci.ids 

Como:

12d8  Pericom Semiconductor
e111  PI7C9X111SL PCIe-to-PCI Reversible Bridge

Independentemente disso, vejo a seguinte linha quando digito "lspci -knn":

04:00.0 Non-VGA unclassified device [0000]: Pericom Semiconductor PI7C9X111SL PCIe-to-PCI Reversible Bridge [12d8:e111] (rev 02)

Portanto, parece que o Debian não sabe o que fazer com esta placa PCIe. Eu não consigo pensar no meu próximo passo. Todo o pacote Debian neste computador está atualizado. Estou executando o Debian 9.0 e "uname -a" dá:

Linux ##### 4.9.0-1-amd64 #1 SMP Debian 4.9.6-3 (2017-01-28) x86_64 GNU/Linux

Adicionado depois ...

Encontrei este log relacionado no dmesg após inicializar o computador Debian:

[    0.220250] pci 0000:03:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    0.220256] pci 0000:00:0c.0: PCI bridge to [bus 03]
[    0.220258] pci 0000:00:0c.0:   bridge window [io  0xa000-0xafff]
[    0.220260] pci 0000:00:0c.0:   bridge window [mem 0xfde00000-0xfdefffff]
[    0.220262] pci 0000:00:0c.0:   bridge window [mem 0xfdd00000-0xfddfffff 64bit pref]
[    0.224007] pci 0000:04:00.0: [12d8:e111] type 01 class 0xffffff
[    0.224011] pci 0000:04:00.0: ignoring class 0xffffff (doesn't match header type 01)

Adicionado mais tarde, usando este comando:

lspci -s 04:00.0 -xxx

Eu recebo esta resposta:

04:00.0 Non-VGA unclassified device: Pericom Semiconductor PI7C9X111SL PCIe-to-PCI Reversible Bridge (rev ff)
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Minha suposição é que a fabricação da placa não programou o chip adequadamente (como em "não programando nada"). Não tenho certeza se a "classe" é encontrada nos dados acima. E se é onde está nos dados acima. Mas, dado que a classe e os dados acima são todos 0xff, parece ser incriminador.

Comportamento inesperado estranho (uma vez descoberto, tentarei editar essa questão).

Se eu repetir o comando:

lspci -s 04:00.0 -xxx

Estou recebendo resultados diferentes. Talvez o comando (ou a ponte PCI) esteja passando por diferentes páginas de memória EEPROM com 256 bytes de comprimento? Isso parece improvável. Ou, talvez, a leitura da EEPROM não seja confiável. E o modo de falha é ler novamente 0xff. Isso faz mais sentido. E se eu ler a EEPROM o suficiente, eu finalmente encontrarei uma resposta considerável:

04:00.0 Non-VGA unclassified device: Pericom Semiconductor PI7C9X111SL PCIe-to-PCI Reversible Bridge (rev 02)
00: d8 12 11 e1 00 00 10 00 02 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 a0 02
20: 00 00 00 00 01 00 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 80 00 00 00 00 00 00 00 00 01 00 00
40: 20 00 20 09 00 00 00 00 1f 80 40 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 08 00 b8 00 00 00 00
70: 80 00 00 00 00 00 00 00 00 00 00 d0 00 00 00 00
80: 07 90 00 00 f8 ff 00 00 10 00 10 00 10 00 10 00
90: 01 a8 43 c8 00 00 00 00 00 00 00 00 00 00 00 00
a0: 04 b0 00 00 ff ff ff ff ff ff ff ff ff ff ff ff
b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Se for verdade, a leitura da EEPROM não é confiável, outras comunicações com o chip Pericom podem estar em questão. Para testar isso, agora estou me perguntando o que poderia ser feito para mitigar o problema? Talvez diminuindo / mudando os relógios de barramento PCIe, se isso for possível?

    

Answer 1

Resposta parcial: posso dizer o que está errado, mas não sei como consertar isso.

Grepping a mensagem de erro na origem do kernel do Linux leva a drivers/pci/probe.c , que requer um PCI da placa PCI_HEADER_TYPE_BRIDGE (1) para ter a classe PCI_CLASS_BRIDGE_PCI (0x0604). Mas sua placa PCI possui a classe 0xffff (ou seja, a classe não foi configurada corretamente pelo fabricante / revendedor), então o driver decide que algo está errado e prefere não usar essa ponte. E se a ponte não for inicializada por um driver adequado, é claro que você não verá nenhuma carta atrás dela.

As formas em torno disso são (1) corrigir o kernel para fazer uma exceção para sua placa, ou (2) dar à placa sua classe apropriada.

Pesquisando encontra uma folha de dados do chip aqui , então, em princípio, temos todas as informações que precisamos para corrigi-lo. A seção sobre o mapa de registro de configuração (6.1) diz que esses dados são armazenados em uma EEPROM, com as seguintes notas para I2C resp. Acesso SMBUS:

Note 1: When masquerade is enabled, it is pre-loadable.
Note 2: The VPD data is read/write through I2C during VPD operation.

Portanto, deve ser possível sobrescrever esses valores de alguma forma. A seção 10 tem mais detalhes sobre isso, mas a questão é se o I2C / SMBus está conectado em algum lugar, em primeiro lugar - como é em uma placa PCIe, provavelmente não. No entanto, olhando para a seção 6.3.91 / 92, parece que se pode escrever a EEPROM através do registro VPD. Descobrir como fazer isso precisa de mais algum trabalho, e possivelmente um programa em C escrito por mim.

Editar : Parece que há um arquivo vpd em /sys/ que pode ser usado para acesso de gravação deste tipo. Por favor, dê uma olhada se /sys/bus/pci/devices/0000:04:00.0/ existir e tiver um arquivo chamado vpd em algum lugar, ou se isso também estiver faltando por causa da classe errada. Se tal arquivo existir, por favor, faça um hexdump -C e edite sua pergunta com os resultados.

De qualquer forma, antes de fazer isso, deve-se olhar o resto dos valores do espaço de configuração. Você pode fazer isso com lspci -s 04:00.0 -x e lspci -s 04:00.0 -xxx para o despejo completo. (Há um cavet sobre o uso de -xxx na lspci man-page que pode falhar em cartões não conformes, mas experimente). Então edite sua pergunta com os resultados. Desta forma, deve-se ver se a classe é o único valor que precisa ser corrigido ou se há mais.