Linux無法湞測到我的NE2000相容網路卡 |
答題得分者是:jackkcg
|
ryowu
一般會員 發表:56 回覆:25 積分:16 註冊:2002-04-23 發送簡訊給我 |
|
jackkcg
站務副站長 發表:891 回覆:1050 積分:848 註冊:2002-03-23 發送簡訊給我 |
參考看看
http://br.tldp.org/documentos/comofazer/html/ethernet/ethernet.pt_BR-373.html
********************************************************************** <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
<TITLE>Como Fazer Ethernet Linux: Problemas com placas NE1000 / NE2000 (e clones)</TITLE>
<LINK HREF="ethernet.pt_BR-374.html" REL=next>
<LINK HREF="ethernet.pt_BR-372.html" REL=previous>
<LINK HREF="ethernet.pt_BR.html#toc373" REL=contents>
</HEAD>
<BODY>
P墔ina seguinte
P墔ina anterior
瓝dice
373. Problemas com placas NE1000 / NE2000 (e clones)Problema: Placa clone PCI NE2000 no é detectada na inicializaço com kernel v2.0.x. Causa: O programa de controlene.c até a v2.0.30 conhece somente o número PCI ID das placas clone baseadas no RealTek 8029. Desde ento, Windbond e Compex também disponibilizaram placas PCI NE2000 clones, com números PCI ID diferentes, e desta maneira o programa de controle no as detecta.
Soluço:
A soluço mais fácil é atualizar para uma verso 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 no funcionam.
Causa:
Alguns clones PCI no implementam acesso com tamanho de byte (e portanto no so 100 por cento compatíveis com NE2000). Isto causa o processo de detecço achar que a placa é NE1000 se o teste PCI no foi utilizado (o que no 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 padro 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, no espere muito. A recapacitaço da leitura antes do conserto da escrita é feita simplesmente pela ediço do arquivo linux/driver /net/ne.c , no comentando a linha que contém NE_RW_BUGFIX e ento 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) no é detectada.
Causa:
A especificaço NE2000 original (e portanto o programa de controle NE2000 do Linux) no 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 no o estiver usando, ento 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, ento examine o pacote isapnptools. Tente man isapnp para ver se já está instalado em seu sistema. Se no estiver, ento 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 verso v1.2.9. Atualize seu kernel.
Problema:
A placa NE*000 trava a máquina durante o teste NE, ou no consegue ler o endereço de estaço corretamente.
Causa:
Os kernels anteriores à verso v1.3.7 no restabeleciam completamente a placa após sua detecço durante a inicializaço. Algumas placas baratas no 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 no gerou a resposta (ack reset), ento o programa de controle supõe que no 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 no 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 no gera o reset ack você deve usar algo como: Isto permitirá que a detecço da placa continue, mesmo que sua placa no gere o ack. Se você estiver usando o programa de controle na forma de módulo, ento 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 no entendero 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 to 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 no é 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 so 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 no 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 no 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 ... no 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, ento você tem um clone NE*000 insatisfatório. Presume-se que todos os clones NE*000 tem o valor 0x57 nos bytes 14 e 15 da SA PROM da placa. A sua no 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 no seja feita, desde que um endereço base de i/o diferente de zero também seja fornecido. Desta forma no é necessária a recompilaço do kernel.
O segundo método envolve mudar o próprio controlador, e ento 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. Ento você pode adicionar sua placa na bad_clone_list[] perto da linha 43. Digamos que a linha acima imprimiu:
depois que você reinicializou a máquina, e digamos que a verso 8 bits de sua placa era chamada "FOO-1k" e a verso 16 bits "FOO-2k". Ento você adicionaria a linha seguinte na bad_clone_list[]:
Note que as duas linhas de nome que você adiciona pode ser qualquer coisa so somente mostradas na inicializaço, e no tem nada relacionado na placa. Você também pode retirar o "printk()" que adicionou acima, se quiser. Ele no deverá chegar àquela linha novamente no final das contas. Ento, recompile o kernel mais uma vez, e sua placa deverá ser detectada.
Problema:
Erros do tipo DMA address mismatch (endereço DMA no correspondente).
O chip é um NatSemi 8390 real? (DP8390, DP83901, DP83902 ou DP83905?) Se no, alguns chips clones no implementam corretamente o registrador de verificaço de transferência. Os programas de controle MS-DOS nunca fazem a verificaço de erro, ento isto no importa para eles. (Nota: a verificaço de endereços de DMA no é feita por padro 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 no 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 rodaro a 16MHz, mas alguns podem no rodar. Mudar a velocidade pode também mascarar um barramento barulhento.
Que outros dispositivos esto no barramento?
Se a movimentaço dos dispositivos pelos slots altera a confiabilidade, ento 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 no é 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:
No, isto realmente acontece durante a silenciosa tentativa de detecço SCSI, e é o mesmo problema acima.
Problema:
NE2000 no é detectada na inicializaço - nenhuma mensagem na inicializaço.
Soluço:
No existe nenhuma soluço mágica pois pode devem existir razões para ela no 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.map como 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: no 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 ento 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 no 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 no poder conseguir a linha IRQ desejada.
5) Se você ainda estiver perplexo pela falha silenciosa do programa de controle, ento 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; }Ento 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 no. 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 padro é 0x300 e ele no 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 sero diferentes. Note que todos os valores PROM so 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 no 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 regio que é detectado, você pode ver alguns no 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. no-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 no puder, ento as coisas no esto boas. Exemplo:
Os argumentos so 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 verso pode ser mais nova que 11. P墔ina seguinte
P墔ina anterior
瓝dice
</BODY>
</HTML>
------
********************************************************** 哈哈&兵燹 最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好 Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知 K.表Knowlege 知識,就是本站的標語:Open our mind |
本站聲明 |
1. 本論壇為無營利行為之開放平台,所有文章都是由網友自行張貼,如牽涉到法律糾紛一切與本站無關。 2. 假如網友發表之內容涉及侵權,而損及您的利益,請立即通知版主刪除。 3. 請勿批評中華民國元首及政府或批評各政黨,是藍是綠本站無權干涉,但這裡不是政治性論壇! |