Aqui estão algumas das questões mais frequentemente feitas sobre o uso do Linux com uma conecção Ethernet. Algumas das questões mais específicas são agrupadas em uma `base por fabricante'. Entretanto, uma vez que este documento é basicamente `velho' no momento que você o obtem, quaisquer `novos' problemas não aparecerão aqui instantaneamente. Para estes, sugiro que você faça uso eficiente de seu newsreader. Por exemplo, usuários do nn deveriam digitar
nn -xX -s'3c'
Para buscar todos os artigos de news na sua lista de grupos assinados que tem `3c' na linha de assunto. (ex. 3com, 3c509, 3c503, etc.) Moral: leia o manual de seu newsreader.
Ouvi falar que existe uma versão atualizada ou alfa disponível para a minha placa. Onde posso buscá-la?
Os drivers mais novos entre os `novos' podem ser encontrados
no novo site ftp do Donald: cesdis.gsfc.nasa.gov na área
/pub/linux/. As coisas por aqui mudam frequêntemente,
então de uma olhada sempre.
Agora, se realmente se trata de um driver alfa ou pre-alfa, então por favor trate-o como. Em outras palavras, não reclame porque você não sabe o que fazer com ele. Se você nao consegue saber como instalá-lo, então provavelmente você não deveria estar testando-o. Outra coisa, se ele derrubar sua máquina, não reclame. Em vez disso, nos envie um relatório de bug bem documentado, ou melhor, uma correção!
Note que alguns dos drivers experimentais/alfa `usáveis' foram
incluidos na árvore de diretórios padrão do kernel. Quando estiver
rodando make config, uma das primeiras coisas que você será
perguntado é se você quer ser perguntado sobre a inclusão de
drivers incompletos/em desenvolvimento (``Prompt for development
and/or incomplete code/drivers''. Você terá que responder `Y' aqui
para ser perguntado sobre a inclusão de quaisquer drivers
alfa/experimentais.
Os que estão lendo este HOWTO enquanto estão conectados à Internet podem querer dar uma olhada em:
para as últimas notícias sobre drivers novos e sendo desenvolvidos.
O que precisa ser feito para que o Linux possa usar duas placas ethernet?
Os ganchos para várias placas ethernet estão todos disponíveis. Entretanto, note que no momento somente uma placa ethernet é auto-probed por default. Isto ajuda a evitar possíveis travamentos durante o boot causados por tentativas de detecçao em placas sensíveis.
Existem duas maneiras para habilitar auto-probing para a
segunda (terceira, quarta...) placa. O método mais fácil é
passar argumentos em tempo de boot para o kernel, o que é
feito usualmente pelo LILO. Tentar detectar a segunda placa
pode ser conseguido usando um argumento em tempo de boot tão
simples como ether=0,0,eth1. Neste caso eth0 e eth1
serão associados na ordem em que as placas forem encontradas no
boot. Por exemplo, se você quer que a placa em 0x300 seja a
eth0 e que a placa em 0x280 seja a eth1 então você
poderia usar
LILO: linux ether=5,0x300,eth0 ether=15,0x280,eth1
O comando ether= aceita mais do que a forma IRQ + i/o
+ name mostrado acima. Por favor dê uma olhada e,
Passando Argumentos Ethernet...
para a sintaxe completa, parâmetros específicos de placas, e
dicas sobre o LILO.
Estes parâmetros de tempo de boot podem ficar permanentes para
que você não tenha que redigitá-los toda vez. Veja a opcão de
configuração `append' no manual do LILO.
A segunda maneira (não recomendada) é editar o arquivo
Sparc.c e substituir a entrada 0xffe0 para o endereco
de i/o por zero. A entrada 0xffe0 diz para não ser feito
tentativa de detecção neste dispositivo -- substituindo-a por
zero habilitará a tentativa de detecção naquele dispositivo.
Note que se você pretende usar o Linux como um gateway entre duas redes, você terá que recompilar o kernel com a opção IP forwarding habilitada. Geralmente um velho AT/286 com alguma coisa como o software `kbridge' é uma solução melhor.
Se você está lendo isto enquanto está conectdado à Internet, você pode dar uma olhada no mini-howto que Donald tem em seu site WWW. Chequem Várias Placas Ethernet.
Para usuários de módulos com placas baseadas em 8390, você pode ter um único módulo controlando várias placas da mesma marca. Por favor veja Placas Baseadas em 8390 com Módulos para informações específicas para módulos quando usando várias placas.
Aqui está uma lista de alguns dos clones NE-2000 que se sabe que tem
vários problemas. A maioria deles não é fatal. No caso dos listados
como `clones ruins` -- Isto geralmente indica que as placas não tem
os dois bytes de identificação NE2000. Clones NEx000 tem uma PROM de
Endereço de Estação (SAPROM) na memória do buffer de pacotes.
Clones NE2000 tem 0x57,0x57 nos bytes 0x0e,0x0f da SAPROM,
enquanto outros supostos clones NE2000 devem ser detectados por seu
prefixo SA.
Esta não é uma lista completa de todos os clones NE2000 que não tem
0x57,0x57 nos bytes 0x0e,0x0f da SAPROM.
Existem provavelmente centenas delas. Se você está tentando usar
uma placa que causa o driver a reportá-la como tendo uma `invalid
signature' (assinatura inválida), então você terá que adicionar as
assinaturas de suas placas ao driver. O processo para fazer isto
é descrito abaixo.
Accton NE2000 -- pode não ser detectada no boot, veja abaixo.
Aritsoft LANtastic AE-2 -- OK, mas tem registradores de erro falhos.
AT-LAN-TEC NE2000 -- clone que usa chip Winbond que dispara drivers SCSI
ShineNet LCS-8634 -- clone que usa chip Winbond que dispara drivers SCSI
Cabletron E10**, E20**, E10**-x, E20**-x -- clones ruins, mas o driver checa por eles. Veja E10**.
D-Link Ethernet II -- clones ruins, mas o driver checa por eles. Veja DE-100 / DE-200.
DFI DFINET-300, DFINET-400 -- clones ruins, mas o driver checa por eles. Veja DFI-300 / DFI-400
EtherNext UTP8, EtherNext UTP16 -- clones ruins, mas o driver checa por eles.
Problema: Placa clone PCI NE2000 não é detectada no boot com kernel v2.0.x.
Causa:
O driver ne.c em v2.0.x conhece somente o numero PCI
ID das placas clone baseadas no RealTek 8029. Deste então,
Winbond e Compex também disponibilizaram placas PCI NE2000
clones, com números PCI ID diferentes, e desta maneira o
driver não as detecta.
Solução:
Após o boot, você pode obter o endereço de I/O (e a interrupção)
que a placa usará executando ``cat /proc/pci''.
Por exemplo, se reporta IRQ 9 e I/O 0xffe0, então no prompt
do LILO você pode adicionar ether=9,0xffe0,eth0 o que
apontará o driver corretamente para sua placa e evitará o
probing PCI completamente. (Futuros kernels 2.1+ conhecerão os
PCI IDs dos clones NE2000 Winbond e Compex, então este procedimento
não será mais necessário.)
Problema: Placa NE2000 PCI clone é detectada como uma ne1000 (placa 8 bits!) no boot ou quando carrego o modulo 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 probe PCI não foi utilizado (o que não ocorre quando um endereço de I/O explicito é dado para o módulo ou em tempo de boot).
Solução:
Faça a seguinte mudança em drivers/net/ne.c:"
- if (pci_irq_line)
+ if (pci_irq_line || ioaddr >= 0x400)
wordlength = 2; /* Catch broken PCI cards mentioned above. */
e recompile o módulo (ou o kernel). Revisões futuras (no kernel v2.1+) não precisarão de um endereço I/O para detectar a maioria das placas PCI (Clones NE2000 RealTek, Winbond e Compex PCI) durante o boot ou com o módulo ne.o.
Problema: Placa NE&000 trava a máquina, algumas vezes com uma mensagem `DMA Conflict', algumas vezes completamente em silêncio.
Causa: Existem alguns bugs no driver 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: Placa NE*000 trava a máquine durante o probe NE, ou não consegue ler o endereço de estação corretamente.
Causa: Os kernels anteriores a versão 1.3.7 não resetavam completamente a placa após sua detecção durante o boot. Algumas placas baratas não eram deixadas em um estado razoavel após o boot e precisavam ser completamente resetadas antes de qualquer tentativa de uso. Um probe anterior também pode ter erroneamente configurado a placa NE antes do probe NE ser feito. Neste caso, tente utilizar o comando ``reserve=' no boot para proteger sua placa de outros probes.
Problema: O driver NE*000 reporta `not found (no reset ack)' durante o probe no boot.
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 probed, o reset é feito. Quando a placa completa o reset, espera-se que gere uma resposta indicando que o reset foi completado. Sua placa não gerou a resposta (ack reset), então o driver assume que não existe placa NE presente.
Solução:
Você pode informar ao driver que você tem uma placa ruim usando
o de outra maneira não utilizado parâmetro mem_end com valor igual
a 0xbad (em hexadecimal) durante o boot. Você tem que também
informar 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 reset ack. Se você está usando o driver na forma
de módulo, então você pode fornecer a opcão bad=0xbad da mesma
forma que fornece o endereço de I/O. Note que o módulos na v2.0.x
não entederão a opção bad=, pois isto foi implementado durante
o kernel de desenvolvimento v2.1.
Problema: 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 presente. Parece confinado a umas poucas placas clone configuráveis por software. Parece que elas esperão 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 um boot quente (i.e. 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 que o atual driver linux faz.
Problema:
Placa ethernet NE*000 em 0x360 não é mais detectada.
Causa:
Kernels recentes (> 1.1.7X) tem mais checagens 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 floppy (se presente)
em 0x370 e a controladora secundária IDE em 0x376--0x377.
Se as portas já estão registradas por outro driver, o kernel não deixará
o probe 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 checa por sobreposição de regiões de I/O. Use a mesma correção que acima, e consiga um novo kernel enquanto está resolvendo.
Problema: NE*000 ethercard probe at 0xNNN: 00 00 C5 ... not found. (invalid signature yy zz)
Causa:
Primeiro, você tem uma placa NE1000 ou NE2000 no endereco 0xNNN?
E se tem uma placa lá, o endereço de hardware reportado parece
válido? Se sim, então você tem um clone NE*000 pobre. Assume-se que
todos os clones NE*000 tem o valor 0x57 nos bytes 14 e 15 da
SAPROM 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 mem_end igual a 0xbad como descrito acima para o problema
`no reset ack'. Isto vai fazer com que a checagem 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 driver, e então recompilar o seu kernel. O driver (/usr/src/linux/drivers/net/ne.c) tem um lista "Hall of Shame" ("Galeria da Vergonha") perto da linha 42. Esta lista é usada para detectar clones pobres. 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 driver, logo depois da mensagem de erro que você obteve acima, e logo antes do "return ENXIO" na linha 227.
Reboote 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 diga que a versão 8 bits de sua placa era chamada "FOO-ik" 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 strings de nome que você adiciona pode ser qualquer coisa -- elas são somente mostradas no boot, e e não tem nada relacionado na placa. Você também retirar o "printk()" que adicionou acima, se quiser. Ele não deverá chegar aquela linha novamente no final das contas. Então recompile o kernel uma vez mais, e sua placa deverá ser detectada.
Problema:
Erros do tipo DMA address mismatch
O chip é um NatSemi 8390 real? (DP8390, DP83901, DP83902 or DP83905)?
Se não, alguns chips clones não implementam corretamente o registrador
de verificação de transferência. Drivers MS-DOS nunca fazem checagem de
erro, então isto não importa para eles. (Note: A checagem de endereços
de DMA não é feita por default até o kernel v1.2.4 por razões de
performance. Habilite ele com o define `NE_SANITY' em ne.c se você
quer que a checagem seja feita.)
A maioria das mensagens aparecem aos pares? Se for assim: Você está usando uma NE2000 num slot de 16 bits? Ele está jumpeado para usar somente transferências de 8 bits?
O driver Linux espera que uma NE2000 esteja em um slot de 16 bits. Uma NE1000 pode estar tanto num slot de 8 quanto 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á rodando o bus em uma velocidade maior que 8MHz? Se você puder mudar a velocidade (para mais rápida ou mais lenta), veja se faz diferença. A maioria dos clones NE2000 rodarão a 16 MHz, mas alguns podem não rodar. Mudar a velocidade pode também mascarar um bus com problemas.
Que outros dispositivos estão no bus? Se a movimentação dos dispositivos pelos slots altera a confiabilidade, então você tem um problema de bus -- exatamente o que a mensagem de erro foi projetada para detectar. Congratulações, você provavelmente encontrou a fonte de outros problemas.
Problema: A máquina trava durante o boot 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 boot ``reserve=''
juntamente com o argumento ``ether='' para proteger sua placa de
outras tentativas de detecção de outros drivers de dispositivo.
Causa: Seu clone NE2000 não é um clone suficientemente bom. Uma NE2000 é uma coisa que disparará quaisquer tentativa 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 o boot de sua máquina.
Problema: A máquina trava durante a tentativa de detecção SCSI durante o boot.
Causa: Mesmo problema acima, mude o endereço de sua placa ethernet, ou use os argumentos de boot reserve/ether.
Problema: A máquina trava durante a tentativa de detecção da placa de som durante o boot.
Causa: Não, isto realmente acontece durante a silenciosa tentativa de detecção SCSI, e é o mesmo problema acima.
Problema: NE2000 não é detectada no boot - nenhuma mensagem no boot
Solução: Não existe nenhuma `solução mágica' pois pode haver um número de razões para ela não ter sido detectada. A lista seguinte pode ajudar você a analisar os possíveis problemas.
1) Build a new kernel with only the device drivers that you need.
Verify that you are indeed booting the fresh kernel. Forgetting to
run lilo, etc. can result in booting the old one. (Look closely at
the build time/date reported at boot.) Sounds obvious, but we have
all done it before. Make sure the driver is in fact included in
the new kernel, by checking the System.map file for names
like ne_probe.
2) Look at the boot messages carefully. Does it ever even mention
doing a ne2k probe such
as `NE*000 probe at 0xNNN: not found (blah blah)'
or does it just fail silently. There is a big difference.
Use dmesg|more
to review the boot messages after logging in, or hit Shift-PgUp
to scroll the screen up after the boot has completed and the login
prompt appears.
3) After booting, do a cat /proc/ioports and verify
that the full iospace that the card will require is vacant. If
you are at 0x300 then the ne2k driver will ask
for 0x300-0x31f. If any other device driver has registered
even one port anywhere in that range, the probe will not
take place at that address and will silently continue to the next
of the probed addresses. A common case is having the lp driver
reserve 0x378 or the second IDE channel reserve 0x376
which stops the ne driver from probing 0x360-0x380.
4) Same as above for cat /proc/interrupts. Make sure no
other device has registered the interrupt that you set
the ethercard for. In this case, the probe will happen, and the
ether driver will complain loudly at boot about not being able to
get the desired IRQ line.
5) If you are still stumped by the silent failure of the driver, then edit it and add some printk() to the probe. For example, with the ne2k you could add/remove lines (marked with a `+' or `-') in net/ne.c like:
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;
+ }
Then it will output messages for each port address that it checks, and you will see if your card's address is being probed or not.
6) You can also get the ne2k diagnostic from Don's ftp site (mentioned
in the howto as well) and see if it is able to detect your card after
you have booted into linux. Use the `-p 0xNNN' option to tell it
where to look for the card. (The default is 0x300 and it doesn't
go looking elsewhere, unlike the boot-time probe.)
The output from when it finds a card will look something like:
Checking the ethercard at 0x300.
Register 0x0d (0x30d) is 00
Passed initial NE2000 probe, value 00.
8390 registers: 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 found at 0x300, using start page 0x40 and end page 0x80.
Your register values and PROM values will probably be different.
Note that all the PROM values are doubled for a 16 bit card, and
that the ethernet address (00:00:c0:b0:05:65) appears in the
first row, and the double 0x57 signature appears at the
end of the PROM.
The output from when there is no card installed at 0x300
will look something like this:
Checking the ethercard at 0x300. Register 0x0d (0x30d) is ff Failed initial NE2000 probe, value ff. 8390 registers: 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 Invalid signature found, wordlength 2.
The 0xff values arise because that is the value that
is returned when one reads a vacant i/o port. If you happen
to have some other hardware in the region that is probed, you
may see some non 0xff values as well.
7) Try warm booting into linux from a DOS boot floppy (via loadlin) after running the supplied DOS driver or config program. It may be doing some extra (i.e. non-standard) "magic" to initialize the card.
8) Try Russ Nelson's ne2000.com packet driver to see if even it can see your card -- if not, then things do not look good. Example:
A:> ne2000 0x60 10 0x300
The arguments are software interrupt vector, hardware IRQ, and i/o base. You can get it from any msdos archive in pktdrv11.zip -- The current version may be newer than 11.
Problema: You get messages such as the following:
eth0: bogus packet size: 65531, status=0xff, nxpg=0xff
Causa: There is a shared memory problem.
Solução:
The most common reason for this is PCI machines that are
not configured to map in ISA memory devices. Hence you
end up reading the PC's RAM (all 0xff values) instead of
the RAM on the card that contains the data from the
received packet.
Other typical problems that are easy to fix are board conflicts, having cache or `shadow ROM' enabled for that region, or running your ISA bus faster than 8Mhz. There are also a surprising number of memory failures on ethernet cards, so run a diagnostic program if you have one for your ethercard.
Problema: SMC EtherEZ doesn't work in non-shared memory (PIO) mode.
Causa: Older versions of the Ultra driver only supported the card in the shared memory mode of operation.
Solução: The driver in kernel version 2.0 and above also supports the programmed i/o mode of operation. Upgrade to v2.0, or get the drop-in replacement for kernel v1.2.13 from Donald's ftp/www site.
Problema: Old wd8003 and/or jumper-settable wd8013 always get the IRQ wrong.
Causa: The old wd8003 cards and jumper-settable wd8013 clones don't have the EEPROM that the driver can read the IRQ setting from. If the driver can't read the IRQ, then it tries to auto-IRQ to find out what it is. And if auto-IRQ returns zero, then the driver just assigns IRQ 5 for an 8 bit card or IRQ 10 for a 16 bit card.
Solução: Avoid the auto-IRQ code, and tell the kernel what the IRQ that you have jumpered the card to is via a boot time argument. For example, if you are using IRQ 9, using the following should work.
LILO: linux ether=9,0,eth0
Problema: SMC Ultra card is detected as wd8013, but the IRQ and shared memory base is wrong.
Causa: The Ultra card looks a lot like a wd8013, and if the Ultra driver is not present in the kernel, the wd driver may mistake the ultra as a wd8013. The ultra probe comes before the wd probe, so this usually shouldn't happen. The ultra stores the IRQ and mem base in the EEPROM differently than a wd8013, hence the bogus values reported.
Solução: Recompile with only the drivers you need in the kernel. If you have a mix of wd and ultra cards in one machine, and are using modules, then load the ultra module first.
Problema: A 3c503 pega a IRQ N, mas esta é necessária para algum outro dispositivo que precisa da IRQ N. (ex. driver CD ROM, modem, etc.) Isto pode ser solucionado sem a compilação de um novo kernel?
Solução: A driver 3c503 tenta detectar uma linha de IRQ livre na ordem {5, 9/2, 3, 5}, e ele deve pegar uma linha que não esteja sendo usada. Drivers muito antigos costumavam pegar a linha de IRQ em tempo de boot, e o driver atual (0.99pl12 e mais recentes) escolhe a linha de IRQ quando a placa é aberta (open()) ou configurada através do ifconfig.
Alternativamente, você pode corrigir a IRQ durante o boot passando parâmetros via LILO. A linha seguinte seleciona IRQ9, endereço base 0x3000, <valor ignorado>, e if_port #1 (transceiver externo).
LILO: linux ether=9,0x300,0,1,eth0
A linha seguinte seleciona IRQ3, auto-detecta o endereço base, <valor ignorado>, e if_port default #0 (transceiver interno)
LILO: linux ether=3,0,0,0,eth0
Problema: 3c503: configured interrupt X invalid, will use autoIRQ.
Causa: A placa 3c503 só pode utilizar uma destas IRQs {5, 2/9, 3, 4} (Estas são as únicas linhas que estão conectadas à placa.} Se você passa um valor de IRQ que não está no conjunto acima, você vai receber a mensagem acima. Usualmente, especificando um valor de interrupção para a 3c503 não é necessário. A 3c503 irá fazer autoIRQ quando ela for configurada através do ifconfig, e escolher uma destas IRQs {5, 2/9, 3, 4}.
Solução: Use uma das IRQs válidas listadas acima, ou habilite autoIRQ não especificando uma linha de IRQ.
Problema: Os drivers 3c503 disponibilizados não usam a porta AUI (thicknet). Como posso escolher ela e não a porta default thinnet?
Solução: A porta AUI da 3c503 pode ser selecionada em tempo deboot com a versão 0.99pl12 e posteriores. A selecão é indicada no bit mais baixo da variável atualmente não utilizada dev->rmem_start, então um parâmetro de boot igual a:
LILO: linux ether=0,0,0,1,eth0
deve funcionar. Uma linha de boot para forçar IRQ 5, porta 0x300 e uso de transceiver externo fica assim:
LILO: linux ether=5,0x300,0,1,eth0
Com os kernels 1.3.42 e mais recentes, você pode especificar
a porta AUI também quando está carregando ela como módulo.
Apenas inclua xcvr=1 na linha de comando insmod junto
com seus valores de i/o e irq.
Geralmente a razão disto é que as pessoas não estão usando um kernel que tenha suporte para sua placa. Se você está usando um kernel precompilado que é parte de sua distribuição, então verifique na documentação para ver que kernel está instalado, e se ele foi compilado com suporte para sua placa. Se ele não foi, então suas opções são procurar um que tenha suporte para sua placa, ou compilar você mesmo.
É usualmente sábio compilar seu próprio kernel somente com os drivers que você precisa, pois isto diminui o tamanho do kernel (poupando sua preciosa RAM para as aplicações!) e reduz o número de probes a dispositivos que podem prejudicar hardware sensível. Compilar um kernel não é complicado como parece. Você apenas terá que responder sim ou não para um monte de questões sobre que drivers você quer, e ele faz o resto.
A próxima causa principal é ter outro dispositivo usando parte
do espaço de I/O que sua placa precisa. A maioria das placas
tem tamanho de espaço de I/O igual a 16 ou 32 bytes. Se sua
placa está configurada para 0x300 e 32 bytes de espaço de I/O,
então o driver usará 0x300-0x31f. Se qualquer outro driver de
dispositivo tiver registrado pelo menos uma porta dentro desta
faixa, o probe não será feito neste endereço e o driver irá
continuar silenciosamente para o próximo endereco a ser probed.
Então, depois do boot, execute cat /proc/ioports e
verifique se todo o espaço de I/O que sua placa precisa está
vago.
A próxima causa principal é sua placa estar jumpeada para
um endereço de I/O que não é probed por default. Existe
uma lista de
endereços probed para
cada placa neste documento. Mesmo que a configuração de
I/O de sua placa não esteja na lista de endereços probed,
você pode fornecer isto no boot com o comando ether=
como descrito em
Passando Parâmetros Ethernet...
ifconfig reporta endereço de i/o incorreto para a placa.
No it doesn't. You are just interpreting it incorrectly.
This is not a bug, and the numbers reported are correct. It just
happens that some 8390 based cards (wd80x3, smc-ultra, etc) have the
actual 8390 chip living at an offset from the first assigned i/o port.
Try cd /usr/src/linux/drivers/net;grep NIC_OFFSET *.c|more
to see what is going on. This is the value stored in
dev->base_addr, and is what ifconfig reports. If you
want to see the full range of ports that your card uses, then try
cat /proc/ioports which will give the numbers you expect.
This will usually show up as reads of lots of 0xffff values.
No shared memory cards of any type will work in a PCI machine
unless you have the PCI ROM BIOS/CMOS SETUP configuration set
properly. You have to set it to allow shared memory access
from the ISA bus for the memory region that your card is trying
to use. If you can't figure out which settings are applicable
then ask your supplier or local computer guru. For AMI BIOS,
there is usually a "Plug and Play" section where there will
be an ``ISA Shared Memory Size'' and ``ISA Shared Memory Base''
settings. For cards like the wd8013 and SMC Ultra, change the
size from the default of `Disabled' to 16kB, and change the base
to the shared memory address of your card.
A quirk of the NexGen CPU caused all users with 8390 based cards (wd80x3, 3c503, SMC Ultra/EtherEZ, ne2000, etc.) to get these error messages. Kernel versions 2.0 and above do not have these problems. Upgrade your kernel.
Werner Almesberger has been playing around with ATM support for linux. He has been working with the Efficient Networks ENI155p board ( Efficient Networks) and the Zeitnet ZN1221 board ( Zeitnet).
Werner says that the driver for the ENI155p is rather stable, while the driver for the ZN1221 is presently unfinished.
Check the latest/updated status at the following URL:
Existe suporte a FDDI no Linux?
Sim, LArry Stefani (stefani@lkg.dec.com) escreveu um driver para os kernels v2.0 para as placas DEFEA e DEFPA da DEC. Foram incluidos no kernel v2.0.24. Correntemente nenhuma outra placa é suportada.
Will Full Duplex give me 20MBps? Does Linux support it?
Cameron Spitzer writes the following about full duplex 10Base-T cards: ``If you connect it to a full duplex switched hub, and your system is fast enough and not doing much else, it can keep the link busy in both directions. There is no such thing as full duplex 10BASE-2 or 10BASE-5 (thin and thick coax). Full Duplex works by disabling collision detection in the adapter. That's why you can't do it with coax; the LAN won't run that way. 10BASE-T (RJ45 interface) uses separate wires for send and receive, so it's possible to run both ways at the same time. The switching hub takes care of the collision problem. The signalling rate is 10 Mbps.''
So as you can see, you still will only be able to receive or transmit at 10Mbps, and hence don't expect a 2x performance increase. As to whether it is supported or not, that depends on the card and possibly the driver. Some cards may do auto-negotiation, some may need driver support, and some may need the user to select an option in a card's EEPROM configuration.
As of v2.0, only the 3c509, depca, de4x5 lance32, and all the 8390 drivers (wd, smc-ultra, ne, 3c503, etc.) have been made `architecture independent' so as to work on the DEC Alpha CPU based systems.
Note that the changes that are required aren't that complicated. You only need to do the following:
-multiply all jiffies related values by HZ/100 to account
for the different HZ value that the Alpha uses.
(i.e timeout=2; becomes timeout=2*HZ/100;)
-replace any i/o memory (640k to 1MB) pointer dereferences with the appropriate readb() writeb() readl() writel() calls, as shown in this example.
- int *mem_base = (int *)dev->mem_start; - mem_base[0] = 0xba5eba5e; + unsigned long mem_base = dev->mem_start; + writel(0xba5eba5e, mem_base);
-replace all memcpy() calls that have i/o memory as source or
target destinations with the appropriate one of
memcpy_fromio() or memcpy_toio().
Details on handling memory accesses in an architecture
independent fashion are documented in the file
linux/Documentation/IO-mapping.txt that comes
with recent kernels.
Can I link 10BaseT (RJ45) based systems together without a hub?
You can link 2 machines easily, but no more than that, without extra devices/gizmos. See Twisted Pair -- it explains how to do it. And no, you can't hack together a hub just by crossing a few wires and stuff. It's pretty much impossible to do the collision signal right without duplicating a hub.
I get a bunch of `SIOCSIFxxx: No such device' messages at boot, followed by a `SIOCADDRT: Network is unreachable' What is wrong?
Your ethernet device was not detected at boot, and when
ifconfig and route are run, they have no device
to work with. Use dmesg | more to review the
boot messages and see if there are any messages about
detecting an ethernet card.
I get `SIOCSFFLAGS: Try again' when I run `ifconfig' -- Huh?
Some other device has taken the IRQ that your ethercard
is trying to use, and so the ethercard can't use the IRQ.
You don't necessairly need to reboot to resolve this, as
some devices only grab the IRQs when they need them and
then release them when they are done. Examples are some
sound cards, serial ports, floppy disk driver, etc. You
can type cat /proc/interrupts to see which interrupts
are presently in use. Most of the
Linux ethercard drivers only grab the IRQ when they are
opened for use via `ifconfig'. If you can get the other
device to `let go' of the required IRQ line, then you
should be able to `Try again' with ifconfig.
When I run ifconfig with no arguments, it reports that LINK is UNSPEC (instead of 10Mbs Ethernet) and it also says that my hardware address is all zeros.
This is because people are running a newer version of the `ifconfig' program than their kernel version. This new version of ifconfig is not able to report these properties when used in conjunction with an older kernel. You can either upgrade your kernel, `downgrade' ifconfig, or simply ignore it. The kernel knows your hardware address, so it really doesn't matter if ifconfig can't read it.
When I run ifconfig with no arguments, it reports that I have a huge error count in both rec'd and transmitted packets. It all seems to work ok -- What is wrong?
Look again. It says RX packets big number PAUSE
errors 0 PAUSE dropped 0 PAUSE overrun 0.
And the same for the TX column.
Hence the big numbers you are seeing are the total number of
packets that your machine has rec'd and transmitted.
If you still find it confusing, try typing
cat /proc/net/dev instead.
/dev/ for Ethercards
I have /dev/eth0 as a link to /dev/xxx. Is this right?
Contrary to what you have heard, the files in /dev/* are not used.
You can delete any /dev/wd0, /dev/ne0 and similar entries.
Should I disable trailers when I `ifconfig' my ethercard?
You can't disable trailers, and you shouldn't want to. `Trailers' are a hack to avoid data copying in the networking layers. The idea was to use a trivial fixed-size header of size `H', put the variable-size header info at the end of the packet, and allocate all packets `H' bytes before the start of a page. While it was a good idea, it turned out to not work well in practice. If someone suggests the use of `-trailers', note that it is the equivalent of sacrificial goats blood. It won't do anything to solve the problem, but if problema fixes itself then someone can claim deep magical knowledge.
How do I get access to the raw ethernet device in linux, without going through TCP/IP and friends?
int s=socket(AF_INET,SOCK_PACKET,htons(ETH_P_ALL));
This gives you a socket receiving every protocol type.
Do recvfrom() calls to it and it will fill the sockaddr
with device type in sa_family and the device name in the
sa_data array. I don't know who originally invented
SOCK_PACKET for Linux (its been in for ages) but its superb stuff.
You can use it to send stuff raw too via sendto() calls.
You have to have root access to do either of course.