373. Problemas com placas NE1000 / NE2000 (e clones)

Problema: Placa clone PCI NE2000 não é detectada na inicialização com kernel v2.0.x.

Causa: O programa de controle ne.c até a v2.0.30 conhece somente o número PCI ID das placas clone baseadas no RealTek 8029. Desde então, Windbond e Compex também disponibilizaram placas PCI NE2000 clones, com números PCI ID diferentes, e desta maneira o programa de controle não as detecta.

Solução: A solução mais fácil é atualizar para uma versão v2.0.31 (ou mais recente) do kernel do Linux. Ele conhece os números de identificação (ID) de cerca de cinco chips NE2000-PCI diferentes e os detectará automaticamente na inicialização ou na hora de carregamento do módulo. Se você atualizar para 2.0.34 (ou mais recente) há um programa de controle específico somente para PCI NE2000 que é levemente menor e mais eficiente que o original programa de controle ISA/PCI.

Problema: A placa PCI NE2000 clone é detectada como uma ne1000 (placa 8 bits!) na inicialização ou quando carrego o módulo ne.o para os kernels v2.0.x, e portanto não funcionam.

Causa: Alguns clones PCI não implementam acesso com tamanho de byte (e portanto não são 100 por cento compatíveis com NE2000). Isto causa o processo de detecção achar que a placa é NE1000 se o teste PCI não foi utilizado (o que não ocorre quando um endereço de I/O explícito é dado para o módulo ou em tempo da inicialização).

Solução: Você precisa atualizar para v2.0.31 (ou mais recente) como descrito acima. O programa de controle verifica agora este defeito do hardware.

Problema: A placa PCI NE2000 tem um desempenho terrível, mesmo quando o tamanho da janela é reduzido como descrito na seção de Dicas de Desempenho.

Causa: As folhas específicas do chip 8390 original, projetado e vendido há dez anos atrás, notaram que uma leitura falsa a partir do chip que era necessária antes de cada operação de escrita para máxima confiabilidade. O programa de controle tem a facilidade para fazer isto, mas foi incapacitado pelo padrão desde os dias do kernel v1.2. Um usuário relatou que a recapacitação desta descaracterização ajudou seu desempenho com uma placa clone PCI NE2000 barata.

Solução: Desde que só foi relatada como uma solução por uma pessoa, não espere muito. A recapacitação da leitura antes do conserto da escrita é feita simplesmente pela edição do arquivo linux/driver /net/ne.c, não comentando a linha que contém NE_RW_BUGFIX e então remontar o kernel ou o módulo apropriadamente. Por favor, envie uma mensagem descrevendo a diferença de desempenho e tipo de placa/chip que você tem se isto puder ajudá-lo (o mesmo pode ser feito para o programa de controle ne2k-pci.c também).

Problema: ISA Plug and Play NE2000 (como RealTek 8019) não é detectada.

Causa: A especificação NE2000 original (e portanto o programa de controle NE2000 do Linux) não tem suporte para Plug and Play.

Solução: Use a configuração de disco DOS que veio com a placa para desabilitar o PnP, e para estabelecer a placa para um endereço I/O e IRQ específico. Acrescente uma linha em /etc/conf.modules como options ne io=0xNNN onde 0xNNN é o endereço I/O hex que você estabelece à placa (isto assume que você esteja usando um programa de controle modular; se não o estiver usando, então use um argumento ether=0,0xNNN,eth0 na inicialização). Como alternativa, se você precisar deixar o PnP inativo para que seja compatível com algum outro sistema operacional, então examine o pacote isapnptools. Tente man isapnp para ver se já está instalado em seu sistema. Se não estiver, então examine as seguintes URL:

Ferramnetas ISA PNP.

Problema: A placa NE*000 trava a máquina, algumas vezes com uma mensagem `` DMA Conflict'', algumas vezes completamente em silêncio.

Causa: Existiam alguns defeitos no programa de controle e nas camadas superiores de rede que causam isto. Foram corrigidos nos kernels a partir da versão v1.2.9. Atualize seu kernel.

Problema: A placa NE*000 trava a máquina durante o teste NE, ou não consegue ler o endereço de estação corretamente.

Causa: Os kernels anteriores à versão v1.3.7 não restabeleciam completamente a placa após sua detecção durante a inicialização. Algumas placas baratas não eram deixadas em um estado razoável após a inicialização e precisavam ser completamente restabelecidas antes de qualquer tentativa de uso. Um teste anterior também pode ter erroneamente configurado a placa NE antes do teste NE ser feito. Neste caso, tente utilizar o comando reserve= na inicialização para proteger sua placa de outros testes.

Problema: O programa de controle NE*000 reporta `not found (no reset ack)' durante o teste de inicialização.

Causa: Está relacionado com a mudança acima. Após a verificação inicial de que um 8390 está no endereço de i/o testado, o restabelecimento é feito. Quando a placa completa o restabelecimento, espera-se que gere uma resposta indicando que o restabelecimento foi completado. Sua placa não gerou a resposta (ack reset), então o programa de controle supõe que não existe placa NE presente.

Solução: Você pode informar ao programa de controle que você tem uma placa ruim usando de outra maneira o parâmetro não utilizado mem_end com valor igual a0xbad (em hexidecimal) durante a inicialização. Você tem que informar também um endereço base I/O diferente de zero para a placa quando usar o override 0xbad. Por exemplo, para uma placa que está em 0x340 e não gera o reset ack você deve usar algo como:

LILO: Linux ether=0,0x340,0,0xbad,eth0

Isto permitirá que a detecção da placa continue, mesmo que sua placa não gere o ack. Se você estiver usando o programa de controle na forma de módulo, então você pode fornecer a opção bad=0xbad da mesma forma que fornece o endereço I/O. Note que os módulos na v2.0.x não entenderão a opção bad=, pois isto foi implementado durante o kernel de desenvolvimento v2.1.

Problema: A placa NE*000 trava a máquina no primeiro acesso à rede.

Causa: Este problema foi reportado para kernels tão velhos quanto o 1.1.57 até o kernel atual. Parece confinado a umas poucas placas clone configuráveis por software. Parece que elas esperam ser inicializadas de uma forma especial.

Solução: Várias pessoas reportaram que somente rodar o software de configuração DOS que acompanha a placa antes de uma inicialização (exemplo, loadlin ou control+alt+del) para entrar no Linux faz com que a placa funcione. Isto indicaria que estas placas precisam ser inicializadas de uma maneira particular, levemente diferente do que o atual programa de controle do Linux faz.

Problema: A placa Ethernet NE*000 em 0x360 não é mais detectada.

Causa: Kernels recentes (> 1.1.7X) tem mais verificações de sanidade com respeito a sobreposição de regiões de I/O. Sua placa NE2000 tem largura de espaço de I/O igual a 0x20, o que a faz entrar no espaço de I/O da porta paralela em 0x378. Outros dispositivos que podem estar nesta área são a segunda controladora de unidade de disquete (se presente) em 0x370 e a controladora secundária IDE em 0x376--0x377. Se as portas já estiverem registradas por outro programa de controle, o kernel não deixará o teste acontecer.

Solução: Mova sua placa para outro endereço como 0x280, 0x340, 0x320 ou compile seu kernel sem suporte à porta paralela.

Problema: A rede deixa de funcionar toda vez que imprimo alguma coisa (NE2000).

Causa: Mesmo problema que acima, mas você tem um kernel mais velho que não verifica por sobreposição de regiões de I/O. Use a mesma correção que acima, e consiga um novo kernel enquanto estiver resolvendo.

Problema: A placa Ethernet NE*000 testa em 0xNNN: 00 00 C5 ... não encontrado. (assinatura inválida yy zz).

Causa: Primeiro, você tem uma placa NE1000 ou NE2000 no endereço OxNNN? Se tiver, o endereço de hardware reportado parece válido? Se sim, então você tem um clone NE*000 insatisfatório. Presume-se que todos os clones NE*000 tem o valor 0x57nos bytes 14 e 15 da SA PROM da placa. A sua não tem, ela tem `yy zz' no lugar.

Solução: Existem duas maneiras de resolver isto. A mais fácil é usar um valor 0xbad mem_end como descrito acima para o problema `no reset ack'. Isto vai fazer com que a verificação de assinatura não seja feita, desde que um endereço base de i/o diferente de zero também seja fornecido. Desta forma não é necessária a recompilação do kernel.

O segundo método envolve mudar o próprio controlador, e então recompilar o seu kernel. O controlador (/usr/src/Linux/drivers /net/ne.c) tem uma lista ``Hall of Shame'' (Galeria da Vergonha) perto da linha 42. Esta lista é usada para detectar clones insatisfatórios. Por exemplo, as placas DFI usam DFI nos primeiros 3 bytes da PROM, no lugar de usar 0x57 nos bytes 14 e 15, como esperado.

Você pode determinar o que há nos primeiros 3 bytes da PROM de sua placa adicionando uma linha como esta:

    printk("PROM prefix: %2.2x %2.2x %2.2x\n",SA_prom[0],SA_prom[1],SA_prom[2]);

no programa de controle, logo depois da mensagem de erro que você obteve acima, e logo antes de return ENXIO na linha 227.

Reinicialize com esta mudança, e após a falha na detecção, você obterá os três bytes da PROM como no exemplo da DFI acima. Então você pode adicionar sua placa na bad_clone_list[] perto da linha 43. Digamos que a linha acima imprimiu:

PROM prefix: 0x3F 0x2D 0x1C

depois que você reinicializou a máquina, e digamos que a versão 8 bits de sua placa era chamada "FOO-1k" e a versão 16 bits "FOO-2k". Então você adicionaria a linha seguinte na bad_clone_list[]:

{"FOO-1k", "FOO-2k", {0x3F, 0x2D, 0x1C,}},

Note que as duas linhas de nome que você adiciona pode ser qualquer coisa são somente mostradas na inicialização, e não tem nada relacionado na placa. Você também pode retirar o "printk()" que adicionou acima, se quiser. Ele não deverá chegar àquela linha novamente no final das contas. Então, recompile o kernel mais uma vez, e sua placa deverá ser detectada.

Problema: Erros do tipo DMA address mismatch (endereço DMA não correspondente).

O chip é um NatSemi 8390 real? (DP8390, DP83901, DP83902 ou DP83905?) Se não, alguns chips clones não implementam corretamente o registrador de verificação de transferência. Os programas de controle MS-DOS nunca fazem a verificação de erro, então isto não importa para eles. (Nota: a verificação de endereços de DMA não é feita por padrão até o kernel v1.2.4 por razões de desempenho. Habilite-o com o define `NE_SANITY' em ne.c se você quiser que a verificação seja feita).

A maioria das mensagens aparecem aos pares? Se for assim: Você está usando uma NE2000 num slot de 16 bits? Ele está chaveado para usar somente transferências de 8 bits?

O programa de controle Linux espera que uma NE2000 esteja em um slot de 16 bits. Uma NE1000 pode tanto estar num slot de 8 quanto num de 16 bits. Este problema também pode ocorrer em alguns clones, notavelmente em velhas placas D-Link de 16 bits, que não tem os bytes corretos de identificação no endereço de estação da PROM.

Você está executando o barramento mais rápido que 8Mhz? Se você puder mudar a velocidade (para mais rápido ou mais lenta), veja se faz diferença. A maioria dos clones NE2000 rodarão a 16MHz, mas alguns podem não rodar. Mudar a velocidade pode também mascarar um barramento barulhento.

Que outros dispositivos estão no barramento? Se a movimentação dos dispositivos pelos slots altera a confiabilidade, então você tem um problema de barramento exatamente o que a mensagem de erro foi projetada para detectar. Parabéns, você provavelmente encontrou a fonte de outros problemas.

Problema: A máquina trava durante a inicialização logo depois da mensagem "8390... ou WD...". A remoção da NE2000 corrige o problema.

Solução: Mude o endereço base de sua NE2000 para algo como 0x340. Alternativamente, você pode usar o argumento de inicialização `reserve=' juntamente com o argumento ether= para proteger sua placa de outras tentativas de detecção de outros programas de controle de dispositivos.

Causa: Seu clone NE2000 não é um clone suficientemente bom. Uma NE2000 é uma coisa que irá disparar quaisquer tentativas de detecção em seu espaço. Mudar a NE2000 para um endereço menos popular irá tirá-la do caminho de outras tentativas de detecção, permitindo a inicialização de sua máquina.

Problema: A máquina trava durante a tentativa de detecção SCSI durante a inicialização.

Causa: Mesmo problema acima, mude o endereço de sua placa Ethernet, ou use os argumentos de inicialização reserve/ether.

Problema: A máquina trava durante a tentativa de detecção da placa de som durante a inicialização.

Causa: Não, isto realmente acontece durante a silenciosa tentativa de detecção SCSI, e é o mesmo problema acima.

Problema: NE2000 não é detectada na inicialização - nenhuma mensagem na inicialização.

Solução: Não existe nenhuma solução mágica pois pode devem existir razões para ela não ter sido detectada. A lista seguinte pode ajudá-lo a analisar os possíveis problemas.

1) Monte um kernel novo só com o dispositivo de controle de programa que você precisa. Certifique-se que você está realmente inicializando o kernel novo. Esquecer de executar o LILO, etc. pode resultar na inicialização do antigo (olhe atentamente para hora da montagem/data reportada na inicialização). Parece óbvio, mas todos já o fizemos antes. Certifique-se de que o programa de controle está de fato incluído no novo kernel, verificando o arquivo para nomes System.mapcomo ne_probe.

2)Examine atentamente as mensagens de inicialização. Alguma vez ela sugeriu que se fizesse uma detecção ne2k como a detecção `NE*000 em 0xNNN: não encontrado (bla bla)' ou ela simplesmente falha silenciosamente? Há uma grande diferença. Use dmesg|more para rever as mensagens de inicialização depois de acessar, ou pressione Shift-PgUp para rolar a tela depois que a inicialização estiver completada e a linha de comando de acesso aparecer.

3) Depois da inicialização, faça um cat/proc/ioports e certifique-se que o iospace total que a placa precisa está vago. Se você estiver em 0x300 então o programa de controle ne2k pedirá 0x300-0x31f. Se qualquer outro dispositivo de programa de controle for registrado mesmo em uma porta em algum lugar naquela área, a detecção não acontecerá naquele endereço e continuará silenciosamente no próximo dos endereços detectados. Um caso comum é ter o programa de controle ip reserve 0x378 ou o segundo canal reserve IDE 0x376 que impede o programa de controle de detectar 0x360-0x380.

4) Mesmo problema acima para cat /proc/interrupts. Certifique-se que nenhum outro dispositivo registrou a interrupção que você configurou para a Ethernet. Neste caso, a detecção acontecerá, e o programa de controle Ethernet se queixará alto na inicialização por não poder conseguir a linha IRQ desejada.

5) Se você ainda estiver perplexo pela falha silenciosa do programa de controle, então edite-o e acrescente printk() a detecção. Por exemplo, com o ne2k você poderia acrescentar/remover as linhas (marcadas com `+' ou `-' ) em net/ne.c:

    int. reg0 = inb_p(ioaddr);

+    printk("NE2k probe - now checking %x\n",ioaddr);
-    if (reg0 == 0xFF)
+    if (reg0 == 0xFF) {
+       printk("NE2k probe - got 0xFF (vacant i/o port)\n");
        return ENODEV;
+    }

Então ele produzirá mensagens para cada endereço de porta que ele verificar, e você verá se seu endereço de placa está sendo detectado ou não.

6) Você também pode conseguir um diagnóstico do site ftp do Don (mencionado no como fazer também) e veja se ele é capaz de detectar sua placa depois que você tiver inicializado dentro do Linux. Use a opção `-p 0xNNN' para dizer onde procurar a placa (o padrão é 0x300 e ele não vai olhar outra parte, diferente da detecção do tempo de inicialização). O resultado de quando ele encontrar a placa será alguma coisa como isto:

Verificar a placa Ethernet em 0x300 
Registro 0x0d (0x30d) é 00 
Detecção NE2000 inicial passado, valor 00 
Registros 8390: 0a 00 00 00 63 00 00 00 01 00 30 01 00 00 00 00
SA PROM  0: 00 00 00 00 c0 c0 b0 b0 05 05 65 65 05 05 20 20
SA PROM 0x10: 00 00 07 07 0d 0d 01 01 14 14 02 02 57 57 57 57

NE2000 encontrou em 0x300, usando a página de início 0x40 e página de fim 0x80.

Seus valores de registro e valores PROM provavelmente serão diferentes. Note que todos os valores PROM são dobrados para um placa de 16 bits, e que o endereço Ethernet (00:00:c0:b0:05:65) aparece na primeira fila, e a assinatura dupla 0x57 aparece no final do PROM.

O resultado de onde não placa instalada em 0x300 parecerá assim:

Verificando a placa Ethernet em 0x300 
Registro 0x0d (0x30d) é ff
Inicial falhou no teste NE2000, valor ff.
Registros 8390: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
SA PROM        0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
SA PROM 0x10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Assinatura inválida encontrada, comprimento da palavra 2.

Os valores 0xff crescem porque aquele é o valor que está de volta quando se lê uma porta i/o livre. Se acontecer de você ter algum outro hardware na região que é detectado, você pode ver alguns não valores 0xff também.

7) Tente a inicialização quente para dentro do Linux a partir de uma unidade de disquete de inicialização DOS (via loadlin) depois de rodar o programa de controle DOS fornecido ou o programa configurado. Pode ser que esteja fazendo alguma mágica extra (ex. não-padronizado) para inicializar a placa.

8) Tente o pacote do programa de controle ne2000.com de Russ Nelson para ver se até ele pode ver sua placa; se não puder, então as coisas não estão boas. Exemplo:

A:> ne2000 0x60 10 0x300

Os argumentos são os vetores de interrupção do software, IRQ de hardware, e a base i/o. Você pode consegui-lo a partir de qualquer arquivo msdos em pktdrv11.zip. A atual versão pode ser mais nova que 11.