Transmit timeouts on 440GX Ocotea on 10baseT-HD network

Transmit timeouts on 440GX Ocotea on 10baseT-HD network

[Wade Farnsworth]

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

Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network

[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

Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network

[Eugene Surovegin]

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

Re: Transmit timeouts on 440GX Ocotea on 10baseT-HD network

[Wade Farnsworth]

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