Os drivers Realtek impedem a detecção da interface eth1?

Question

Aqui está a situação: Eu tinha uma configuração de rede funcional na minha caixa Debian, com duas interfaces Ethernet sendo reportadas por ifconfig - eth0 e eth1. eth0 é uma placa Realtek NIC integrada e eth1 é uma placa PCI NIC da D-Link. O som, no entanto, não estava funcionando no sistema.

Seguindo o conselho em esta página , eu fui para O site da Realtek e fez o download do "LINUX driver para o kernel 3.xe 2.6.xe 2.4.x ". Eu descompactei-o e, depois de instalar os pacotes de cabeçalho de compilação e Linux necessários, executei r8168-8.037.00/autorun.sh como root. Após revisão, cometi um grande erro aqui. Cliquei em "Realtek PCIe GBE Família Controller Series Drivers" em vez de "HD Audio Codec Driver", então eu instalei o driver de rede em vez de seu driver de áudio. Oops De qualquer forma, agora estou procurando uma maneira de desfazer essa bagunça.

Nenhuma mensagem de erro parecia ser exibida, mas o som ainda não estava funcionando, então reiniciei a máquina. Quando surgiu novamente, ifconfig -a agora só mostra a interface eth0 e não eth1 . Além disso, find /sys/devices/ -type d | grep eth só me retorna eth0 devices e não eth1 devices. Nem dmesg | grep eth1 fornece qualquer saída. De alguma forma, os novos drivers Realtek impediram que eth1 fosse detectado! O som ainda não está funcionando, a propósito.

Como isso está acontecendo e como posso corrigi-lo? Eu acho que vou ter que viver sem som, mas eu quero voltar minha configuração de trabalho eth0 e eth1 . Como posso obter o Linux detectando eth1 novamente?

Parece que ele pode ter instalado algumas coisas em /lib/modules/3.2.0-4-amd64/kernel/drivers/net/ethernet/realtek , se isso ajudar. Por exemplo, o arquivo r8168.ko está no diretório src dos drivers que eu descompactei e nesse diretório /lib... .

    

Answer 1

OK eu consegui consertá-lo, mas era um PITA real (o Linux precisa desesperadamente de um sistema de instalação de driver mais maduro com um IMHO de reversão embutido). Veja como:

cd /lib/modules/3.2.0-4-amd64/kernel/drivers/net/ethernet/realtek/

Este diretório tinha r8169.bak e r8168.ko . Se o instalador do Realtek tivesse acabado de excluir o r8169 em vez de fazer o backup, eu teria sido ferrado.

/sbin/rmmod r8168
ifconfig -a

Tanto eth0 como eth1 desapareceram agora.

mv r8168.ko r8168.bak
mv r8169.bak r8169.ko
/sbin/depmod 'uname -r'
/sbin/modprobe r8169
ifconfig -a

eth0 e eth1 estão de volta e funcionando.

Então, em conclusão; instalação de driver e atualização no Linux é uma merda. É melhor esperar que o seu instalador seja bom o suficiente para fazer o backup de seus drivers anteriores, porque o Linux basicamente diz "faça o que diabos você deseja instalar seus novos drivers". Deve haver algum serviço que seja chamado para instalar os drivers, pelo qual o Linux mantém um controle das versões anteriores para que possam ser revertidas.

    

Answer 2

Somehow the new Realtek drivers have prevented eth1 from being detected!

Meio que uma pena, já que obviamente os drivers do kernel da árvore estavam funcionando em primeiro lugar. Por que você instalou novos?

Se a interface aparecer com ifconfig , o kernel tem um driver carregado para o nic. Isso não significa necessariamente que o driver funcionará perfeitamente para o que você estiver planejando fazer com ele , mas em 99% + dos casos, será. Os chipsets ethernet Realtek são comuns e o kernel tem muito suporte para eles.

Pode parecer como o "melhor" driver para usar seria um driver do fabricante, mas eu acho que isso é, na verdade, geralmente não é verdade . O problema é que os fabricantes têm pouco ou nada investido em drivers linux - tanto em termos de quanto é importante para eles (muito pouco, já que o linux tem uma participação insignificante) e, consequentemente, quanto recursos serão dedicados a ele. Além disso:

• Como eles não fazem parte da árvore de kernel oficial, não há envolvimento direto com os desenvolvedores reais do kernel. Significado, quase qualquer palhaço poderia ter feito isso. Eles estão fora da avaliação normal e da revisão por pares, etc.

• Por serem de código fechado, ninguém pode olhar o código e dizer: "Isso está errado", etc. Portanto, quaisquer erros que existam estão ocultos. Se houver algum problema e o fabricante não puder ser incomodado em pagar alguém para manter o motorista apropriadamente, ninguém mais poderá ir à tona porque a placa está fora dos limites.

Em resumo, não há supervisão do produto nem compromisso das pessoas que o fornecem. Os devs do linux são bastante explícitos sobre isso: O melhor driver para usar é o driver in-tree oficial, NÃO um proprietário. Somente se o driver do kernel não funcionar você deve começar a procurar em outro lugar. / p>