Solução de problema em placa de rede Davicom Semiconductor (qualquer distro)

manfilho

Esse problema me foi detectado inicialmente no Slackware 11, mas conferi em fóruns que em outras distribuições acontecia o mesmo problema, sem clareza nas soluções. Existem dois módulos para esse tipo de placa, o tulip e o dfme, em alguns casos, ambos funcionam, em outros há conflito ou o OS carrega o módulo errado. :) Se você estiver passando por problemas com essa placa, recomendo essa leitura.

[ Hits: 25.956 ]

Por: ManFilho em 19/06/2007

1 0

Denuncie Favoritos Indicar Impressora

Fazendo a placa falar

Desabilitando a interface:

ATENÇÃO, se você esquecer de descarregar o módulo com ela UP, você vai ficar batendo cabeça para carregar o "dmfe", vai mostrar tudo certo no lsmod, o módulo carregado e tudo mais, só que funcionar não vai... aqui não foi =( .. Portanto...

Deixando a interface inativa:

# /sbin/ifconfig eth0 down

Descarregando o módulo

# /sbin/modprobe -r tulip

Carregando o dmfe, o que o Slackware já deveria ter carregado por si só: ;D

# /sbin/modprobe -i dmfe

Levantando a interface para ver a eth0 dar sinal de vida: =D

# /sbin/ifconfig eth0 up

Agora testando a eth0...

# /sbin/ifconfig eth0

eth0   Link encap:Ethernet  HWaddr 0A:09:A1:32:9F:40
          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::208:a1ff:fe86:6f10/64 Scope:Link
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:88 errors:0 dropped:0 overruns:0 frame:0
          TX packets:17 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8319 (8.1 KiB)  TX bytes:2298 (2.2 KiB)
          Interrupt:10 Base address:0xb800

# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=254 time=6.30 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=254 time=0.706 ms

Pronto, a minha placa fala!

Agora vamos deixar ela falante toda vez que reiniciar o sistema. (:

Página anterior Próxima página

Páginas do artigo

   1. Detectando o problema
   2. Verificando o módulo ativo
   3. Fazendo a placa falar
   4. Configurar pra quando reiniciar o sistema

Outros artigos deste autor

Nenhum artigo encontrado.

Leitura recomendada

Obtendo maior funcionalidade de um mouse com 5 botões

Configurando sua placa Nvidia no Debian Sarge

Placa Intel PRO/Wireless 3945ABG no Debian Linux

Instalando o modem Huawey E1556 no GNU/Linux

Adaptador USB RF para redes sem fio (Clone) no Debian e Dapper

Comentários

[1] Comentário enviado por morvan em 19/06/2007 - 10:54h

Bom dia a todos.

Tive um problema similar, porém o resolvi de forma diversa. No Fedora 6, a placa era detectada normalmente e era carregado o módulo correto (dmfe); no Fedora 7, ao invés disto era carregado o módulo tulip, o que ocasionava o mal-funcionamento desta. A solução - bem simples - consistiu em colocar o driver da Tulip na lista negra - um recurso documentado no MAN do ModProbe. Ao banir o módulo da tulip o Sistema - como era esperado - não o carrega. Daí é só dar um alias para o módulo (driver) correto.
Fica assim, sinteticamente:
# modprobe.conf - alterado em 2007...
blacklist tulip
alias eth? dmfe
...
# fim do modprobe.conf

Pronto. Na inicialização do Sistema, o módulo correto é carregado, sem qualquer problema.
Abraços,

Morvan

0 0

[2] Comentário enviado por manfilho em 19/06/2007 - 14:55h

O bom do linux é esse, várias formas de resolver o mesmo problema, dinamismo, praticidade! ;D
Pensei em ir mais a fundo...
Retirar no kernel a opção de modularizar o tulip, recompila-lo, mas seria muito demorado e mais complicado para um usuário leigo entender! :)
De qualquer forma, a sua solução também é muito simples.

Abração.

0 0

[3] Comentário enviado por juninho (RH.com) em 19/06/2007 - 15:43h

Nem acredito, tive este mesmo problema a alguns meses, como não tenho tanto conhecimento como vocês, a única solução que encontrei foi substituir a placa por uma Realteck.

Parabéns por compartilharem mais uma solução!!!!

0 0

[4] Comentário enviado por removido em 20/06/2007 - 09:07h

No Debian não tem diretório rc.d nem arquivo rc.modules...
Como eu faço esse procedimento no Debian Etch ???

0 0

[5] Comentário enviado por manfilho em 20/06/2007 - 15:30h

Se eu não me engano fica no /etc/rc.modules
E a pasta equivalente à /etc/rc.d/ no Debian é a /etc/init.d/
Corrijam-me se eu estiver errado!

Um abraço, boa sorte!

0 0

[6] Comentário enviado por CerberusBH em 20/06/2007 - 19:21h

Olá!
Meu PC é "véio", com Slackware 11, e a placa de rede também é uma Davicom. Mas no meu caso o interessante é que o módulo dmfe simplesmente não funciona nem rezando! :-D
Com o módulo tulip funciona perfeitamente.
Quando eu usava Conectiva 10, o módulo que funcionava era o dmfe e, até então, eu nunca tinha ouvido falar em tulip.
Até mais!

0 0

[7] Comentário enviado por manfilho em 06/07/2007 - 22:15h

Pois é.. alguem sabe explicar buscando bem do útero do kernel o porquê desta situação?
flw =]

0 0

[8] Comentário enviado por morvan em 07/07/2007 - 14:45h

Boa tarde.
A explicação passa pelo modo como o Kernel identifica o PCI-Id da placa. A partir de um certo número de versão / subversão do Kernel, este passou a identificar o PCI-Id (Grosso modo, todo "hardware" tem o ID do fabricante, bem como o seu subcódigo, que é uma espécie de Banco de Dados de dispositivos por fabricante) da Tulip como "dmfe" e vice-versa. Observe-se que na maioria das vezes funciona um ou outro, transparente ao usuário. Para aprofundar, sugiro uma leitura nos fontes do Kernel e dar uma "Googlada" nas palavra-chave "PCI Id"
[ ],
Morvan

0 0

[9] Comentário enviado por manfilho em 08/07/2007 - 02:12h

Hm... muito boa explicação Morvan, eu fantasiei outra coisa em minha cabeça, sabe aquela desculpa bem esfarrapada que você sabe que está errado mas pela falta de tempo você acaba enfiando guela abaixo e "aceitando"? então, aconteceu! ;D

E com essa resposta surge mais uma dúvida...

Então, essa "falha" é de quem? kernel, distribuição ou da fabricante?

Alguem sabe?

0 0

[10] Comentário enviado por morvan em 08/07/2007 - 14:47h

Boa tarde.
Respondendo e - espero - ajudando mais no processo de discussão, diria a todos que não é, em si, uma falha. É muito mais uma evolução. Quem já teve problema com drivers no Windows, por exemplo, deve se lembrar dos famosos "puxa, mas é o mesmo ChipSet e não aceita o driver"! Quando você tem que baixar um driver de um fabricante em particular, mesmo conhecendo o ChipSet do hardware destino. No Linux, a despeito da tão proclamada dificuldade, a grande maioria dos drivers de dispositivo é carregada de forma transparente, fortemente baseado no PCI-Id do fabricante. E quando dá errado, como neste caso, basta identificar o hardware mais aplicável. Outra coisa, se não tivéssemos o PCI-Id, o qual você pode achar sempre a lista mais atual na Internet, teríamos o caos. É aí onde nos deparamos com uma boa explicação sobre a importância da padronização.
Então, não seria uma falha e sim uma sucessão de fatores.
Abraços a todos.

0 0