É possível obter um módulo para suportar um dispositivo que (algumas vezes) reporta um ID PCI incorreto?

Question

Estou tentando configurar uma NIC sem fio (TP-Link TL-WN350GD) em um servidor Linux (Debian Squeeze).

Após uma inicialização a frio, o comando lspci -nn mostra que o ID PCI da placa é 168c: ffa1. O kernel (2.6.38 dos backports) não possui nenhum módulo para esse ID de dispositivo e, portanto, nenhum módulo é carregado.

No entanto, após uma inicialização a quente (ou seja, executando o comando reboot), o mesmo dispositivo aparece como 168c: 001d, que parece ser a ID correta e é tratado pelo módulo ath5k conforme documentado aqui . Tanto quanto eu posso dizer, o dispositivo funciona perfeitamente no Debian com este kernel específico (eu posso conectar a um AP e me comunicar sem fio com o resto da rede).

O problema é que, quando o sistema é desligado, na próxima vez em que ele é inicializado, o dispositivo recebe uma ID incorreta (168c: ffa1) e, obviamente, ele não é detectado. Se eu executar uma reinicialização, tudo voltará ao normal (ID do dispositivo = 168c: 001d, com o módulo ath5k carregado automaticamente).

Eu nunca vi um comportamento tão estranho em relação a IDs PCI antes, e é isso que eu gostaria de saber:

Existe alguma solução para uma situação como esta? Existe alguma maneira de "forçar" o ID deste dispositivo em particular para que o driver seja carregado toda vez, e não apenas após uma inicialização a quente? Se isso puder ser feito por meio de uma regra do udev, um exemplo seria realmente útil.

TIA, Alex

    

Answer 1

Provavelmente você poderia encaixar isso com o udev, mas não estou bêbado o suficiente para tentar lidar com as regras do udev no momento. A maneira não totalmente insana seria fazer com que o driver registrasse corretamente que ele pode trabalhar com o ID de PCI alternativo - mas somente se ele realmente puder .

Meu palpite é que quando ele surge com o ID PCI alternativo, ele está expondo um dispositivo diferente, que na verdade não é uma placa sem fio. Eu esperaria que, se esse dispositivo alternativo pudesse realmente ser acionado pelo driver, o driver já lidaria com esse caso. (Dado que é uma diferença de inicialização quente / frio, eu estou supondo que é algum tipo de bollocks de carregamento de firmware). Se o driver não puder conduzir o dispositivo alternativo, qualquer tipo de encaixe não funcionará, udev ou de outra forma.

Eu me livraria do cartão e o substituiria por algo que não é tão insano.

    

Answer 2

Provavelmente isso também pode ser feito via udev também. Muitos anos atrás eu tomei outra abordagem ao tentar obter uma chave de memória USB desconhecida para funcionar; Eu adicionei o ID do dispositivo manualmente e, por sorte, ele funcionou.

Assim, uma maneira muito hardcore seria modificar o arquivo drivers/net/wireless/ath/ath5k/pci.c no código-fonte do Linux e modificar um pouco a seção IDs PCI conhecidos . Já existe essa linha:

    { PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */

Gostaria de saber o que aconteceria se você o modificasse:

    { PCI_VDEVICE(ATHEROS, 0x001d) }, /* 2417 Nala */
    { PCI_VDEVICE(ATHEROS, 0xffa1) }, /* 2417 Nala */

e, em seguida, compilou seu próprio kernel.

Mas eu não vi esse tipo de mudança no comportamento do ID PCI antes. É totalmente possível que a placa sem fio não esteja realmente em estado utilizável enquanto relata esse id diferente.

    

Answer 3

Uma abordagem insana, embora possivelmente funcional, seria executar lspci no momento da inicialização e forçar uma reinicialização, quando um ID incorreto for detectado. Observe a parte insane (e certifique-se de ter algumas precauções contra o loop de inicialização infinito).

Acho que a sugestão do womble de substituir o dispositivo por algo que funcione sempre é o caminho certo.