Re: [Astlinux-users] NETDEV WATCHDOG: ethx: transmit timed out (net4801)

[Kristian K. <kri...@gm...>]

On 5/22/07, anuar musa <an...@ro...> wrote:
> Hi,
> I have download Astlinux-0.4.5.img.gz but it's still
> have the same problem as I mentioned before.
>
> I did make some change to configuration by enabling
> packet forwarding to enable routing in net4801 besides
> assigning IP address to eth1 and eth2. e.g.
> pbx ~ # ifconfig eth1 192.168.3.1 netmask
> 255.255.255.0
> pbx ~ # ifconfig eth2 192.168.2.1 netmask
> 255.255.255.0
> pbx ~ # echo 1 >
> /proc/sys/net/ipv4/conf/all/forwarding
>
> Some more detail info:
>
> Routing table:
> pbx ~ # netstat -nr
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags
>  MSS Window  irtt Iface
> 192.168.3.0     0.0.0.0         255.255.255.0   U
>    0 0          0 eth1
> 192.168.2.0     0.0.0.0         255.255.255.0   U
>    0 0          0 eth2
>
> pbx ~ # cat /proc/interrupts
>            CPU0
>   0:     793413          XT-PIC  timer
>   2:          0          XT-PIC  cascade
>   4:       1022          XT-PIC  serial
>   5:          0          XT-PIC  ohci_hcd:usb1
>   8:     796142          XT-PIC  rtc
>  10:       2371          XT-PIC  eth0, eth1, eth2
>  14:      23244          XT-PIC  ide0
> NMI:          0
> ERR:          1
>
> Attached is the dmesg file.
>
> Regards,
> Anuar
>

Anuar,

  The last time I saw something like this on a Soekris it was because
of the NS DP83815 short cable issues.  Evidently the DP83815 had some
problems figuring out the proper attenuation on various cable lengths.
 It caused all sorts of problems.

  I could swear that I also saw it with some DP83816s a couple of
years ago.  Driver updates have been able to work around the issue
(for the most part) and I have not heard of this in years.

  Unfortunately, the natsemi driver does not distinguish between the
83815 and the 83816 (which fixed the issue - supposedly).  Can you
open your case and read the DP8381x part number off of your ethernet
chips?

  Also, try this:

1)  Use longer or shorter ethernet cables (trial and error) on both
ethernet interfaces (although eth1 seems to be the culprit).

2)  Is your switch managed?  See if there are an excessive number of
link state changes and/or input errors on the connected ethernet port.
 Also check and make sure that it is negotiating the same speed
(100/full).

3)  Have you tried a different switch?  Try inserting another switch
in between the systems or use a different switch completely.

  Of course it could always be something simple (like a bad cable),
but step #1 should cross that off the list too.

-- 
Kristian Kielhofner