RTL8139D (Chipset RTL Falso)

Ao configurar um servidor, pedi ao cliente, que comprasse 2 placas de rede, preferencialmente com chipset Realtek por ser facilmente reconhecido, o que foi feito prontamente. Infelizmente o linux não detectou a placa, fui então até o site da Realtek para pegar o driver mais atualizado.
Como não obtive sucesso, apelei para o lspci e obtive a seguinte resposta:

01:00.0 Ethernet controller: Hangzhou Silan Microelectronics Co., Ltd. RTL8139D [Realtek] PCI 10/100BaseTX ethernet adaptor (rev 01)

Visto que o Linux não reconheceu a placa como Realtek, procurei por Hangzhou Silan, no google, e encontrei a verdade sobre a placa. O chipset em questão é falso, e para ser instalado deve ser compilado o driver correto (SC92031) já disponível nos ultimos kernels.

Solucionado: NETDEV WATCHDOG

Resumo:
Resolvi o problema do servidor relacionado ao NETDEV WATCHDOG, desmarcando
a opção ENABLE IRQ BALANCING do Kernel SMP.

A algum tempo atrás um problema novo apareceu no servidor. De tempos em tempos a placa de rede começava a apresentar os seguintes erros:

Feb 1 20:34:11 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:34:26 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:34:41 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:34:56 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:35:11 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:35:26 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out
Feb 1 20:35:41 debian kernel: NETDEV WATCHDOG: eth0: transmit timed out

Esses erros não duravam muito tempo, porque muito rapidamente a placa de rede simplesmente parava de responder.

Para ativar a placa novamente, era necessário descarregar e carregar novamente o seu módulo.

Primeiro recompilei o driver da placa de rede alterando o MMIO para PIO.

* Usa as Portas de I/O programadas ao invés da Memória PCI Compartilhada, pode resolver alguns problemas em placas mãe com inconsistência de memória. (Segundo info do kernel)

Por felicidade ou não, o servidor permaneceu dois dias sem apresentar erro, mas no terceiro dia, a mesma história.

Pensei então na opção de RX-Reset (imagem acima), que, segundo info do kernel, contém uma mais rápida sequencia de reset, e se apresentar problema pode ser optado o método antigo.

Recompilado o módulo, modulo descarregado e carregado. Horas depois o mesmo erro, entretanto numa placa de rede diferente, e que utilizava outro driver. Então, pensei, já que o erro mudou de interface, vamos ver as configurações do módulo da maldita placa.

Encontrei então a opção NAPI API, que é um novo driver desenvolvido para reduzir a carga e interrupção do CPU quando recebendo muitos pacotes da placa de rede. Opção recomendada para Carga de RX acima de 10kpps (pacotes por segundo)

Solução também insuficiente, pois a placa apresentava os mesmos erros, agora em interfaces alternadas (o servidor possui 4 placas de rede)

Pesquisando na internet, encontrei o parâmetro pci=noacpi afim de resolver o erro, insiro no append do lilo (append="pci=noacpi") e reinicio o servidor.

Novamente o servidor começa a apresentar erros, começo então a esmiuçar o kernel com a linha de raciocínio que era problemas no barramento PCI ou IRQ, algo do tipo, até que então, encontro na parte "Processor type and features" a opção "Enable kernel irq balancing"

obs. Essa opção só aparece se o servidor estiver sendo compilado para multiprocessadores (SMP)

Desmarco a opção, recompilo o kernel, e reinicio o servidor.

Bom, hoje é dia 9 de fevereiro, desde o último dia 1, o erro não acontece mais.

Pode não estar relacionado, mas após essa alteração até o processamento da máquina diminuiu consideravelmente, agora o servidor fica idle acima de 96%, e antes estava por volta de 84%.

Pesquisando no google, encontrei um tópico em inglês de um usuário que após recompilar o kernel desativando essa opção sentiu uma considerável diferença no seu desktop linux, segundo o mesmo os vídeos que antes travava de tempos em tempos, agora é executado perfeitamente, mesmo ele usando outros aplicativos em background.

Devido ao leitor que solicitou mais detalhes do procedimento adotado, farei aqui resumidademen te.

obs.. Ao estilo Debian(Ubuntu) mas com poucas modificações, funciona em qualquer distribuição.

Preparando os compiladores necessários.

#apt-get install build-essential kernel-package libncurses5-dev

Instalando o kernel (Faça de acordo com seu próprio kernel)

#apt-get install linux-tree-2.6.26-1

Crie o link simbólico para o souce do kernel

# ln -s /usr/src/linux-2.6.26.1 /usr/src/linux

Entre no diretorio do linux

#cd /usr/src/linux

Configure o kernel conforme imagens inseridas nesse artigo, para isso acessamos a configuração via terminal

#make menuconfig

Salve o arquivo de configuração e faça a compilação do kernel conforme:

#make-kpkg --initrd kernel_image

Uma vez compilado, basta instalar o novo kernel

#dpkg -i linux-image-2.6.26.1*

Agora reinicie a máquina para que o novo kernel seja ativado.