Hi Eugene,
I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
the Ocotea when it's connected to a 10baseT hub, and it's put under
heavy load. I'm using the most current 2.6 git tree.
This can be reproduced by ssh'ing into the Ocotea and running the
command "ping <host-machine> -A -s 1200", then also doing the same ping
command from the host to the Ocotea. The pings will be successful for a
short time, then all transmits on the Ocotea will stop for a few seconds
(usually preceded by a few duplicate packets). Transmits begin again
once the timeout occurs. /proc/net/dev doesn't report any errors, just a
few dropped packets.
Do you know what might be causing the EMAC to stop transmitting in this
situation?
Thanks,
Wade Farnsworth
On Wed, 2005-12-07 at 08:15, Wade Farnsworth wrote:
Hi Eugene,
I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
the Ocotea when it's connected to a 10baseT hub, and it's put under
heavy load. I'm using the most current 2.6 git tree.
This can be reproduced by ssh'ing into the Ocotea and running the
command "ping <host-machine> -A -s 1200", then also doing the same ping
command from the host to the Ocotea. The pings will be successful for a
short time, then all transmits on the Ocotea will stop for a few seconds
(usually preceded by a few duplicate packets). Transmits begin again
once the timeout occurs. /proc/net/dev doesn't report any errors, just a
few dropped packets.
Do you know what might be causing the EMAC to stop transmitting in this
situation?
One more data point to consider: I ran this test on an Ebony board, but
don't encounter any timeouts. Do you know of any 440GX-specific issues
that might cause this?
Thanks again,
Wade Farnsworth
On Wed, Dec 07, 2005 at 08:15:28AM -0700, Wade Farnsworth wrote:
Hi Eugene,
I'm seeing some "NETDEV WATCHDOG: eth0: transmit timed out" messages on
the Ocotea when it's connected to a 10baseT hub, and it's put under
heavy load. I'm using the most current 2.6 git tree.
This can be reproduced by ssh'ing into the Ocotea and running the
command "ping <host-machine> -A -s 1200", then also doing the same ping
command from the host to the Ocotea. The pings will be successful for a
short time, then all transmits on the Ocotea will stop for a few seconds
(usually preceded by a few duplicate packets). Transmits begin again
once the timeout occurs. /proc/net/dev doesn't report any errors, just a
few dropped packets.
Do you know what might be causing the EMAC to stop transmitting in this
situation?
Hmm, I think this should have been fixed in the latest 2.6. Check
that you tree has this patch:
[PATCH] ibm_emac: fix graceful stop timeout handling
It went in on 01 Dec. Although this fix assumed FDX operation for
timeouts, without collisions. Maybe I was too optimistic thinking that
nobody uses 10/HDX :).
Try making STOP_TIMEOUT_10 bigger, say twice as big.
If this doesn't help, I'll send you patch with enables some additional
debugging, so I can check that stop you are experiencing is the same
problem I had last month.
--
Eugene
On Wed, 2005-12-07 at 10:35, Eugene Surovegin wrote:
Hmm, I think this should have been fixed in the latest 2.6. Check
that you tree has this patch:
[PATCH] ibm_emac: fix graceful stop timeout handling
It went in on 01 Dec. Although this fix assumed FDX operation for
timeouts, without collisions. Maybe I was too optimistic thinking that
nobody uses 10/HDX :).
That was my first thought as well, but I've tried it with the patch, and
still get the timeouts.
Try making STOP_TIMEOUT_10 bigger, say twice as big.
That doesn't seem to help any.
If this doesn't help, I'll send you patch with enables some additional
debugging, so I can check that stop you are experiencing is the same
problem I had last month.
Much appreciated. Thanks!
Regards,
Wade Farnsworth