fxp0: device timeout and sk0: watchdog timeout problems

[JoaoBR]

On Thursday 19 January 2006 04:14, Ganbold wrote:
> I have same problem even after updating the sk code to the latest:
>
> Jan 19 12:58:53 gw kernel: fxp0: device timeout
> Jan 19 12:59:10 gw kernel: sk0: watchdog timeout
> Jan 19 12:59:10 gw kernel: sk0: link state changed to DOWN
> Jan 19 12:59:20 gw kernel: fxp0: device timeout
> Jan 19 12:59:52 gw kernel: fxp0: device timeout
> Jan 19 13:00:23 gw kernel: fxp0: device timeout
> Jan 19 13:00:29 gw kernel: sk0: watchdog timeout
> Jan 19 13:00:52 gw kernel: fxp0: device timeout
> Jan 19 13:01:05 gw kernel: sk0: watchdog timeout
>
> Ganbold
>

hi 
maybe a stupid hint but did you checked the TP cable and pin order? I often 
saw such problems when a gigabit connected to an older /10 HUB or when using 
incorrect pin orders on the cables or even to long cables

Appearently the sk down events are gone on my server with Pyun's patched 
drivers, did you checked if you compiled with them in the right place? My 
servers are now almost 24h up with the new sk driver and none of them is 
having the problem any more until now. Until this I had crontab run "ifconfig 
sk0 up" all 10 minutes what helped me so long.

On my SMP system when sk stopped it caused also watchdog timeout on all other 
NICs, on UP kernel not.

Do you use interface polling? Check with vmstat -i because you may have 
overlapping IRQs and you cards may not support it. Look into the MB manual 
and see which pci slots are shared and don't use them or try another bios 
setting. What MB you are using?

you may try ifconfig fxp link0 to load its microcode which could help but in 
my opinion and experience the fxp cards are bad when using more than one and 
I through them all out but interesting is that they work well on until 
releng_5, btw the sk  also works well on releng_5

João







A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br