Re: sky2 driver - large files upload problem

[Stephen Hemminger <shemminger@osdl.org>]

On Tue, 22 Aug 2006 00:04:07 +0200
Jon Wikne <wikne@cheetah.uio.no> wrote:

> Stephen Hemminger wrote:
> 
> > On Mon, 21 Aug 2006 16:21:07 +0200
> > Jon Wikne <wikne@cheetah.uio.no> wrote:
> > 
> >>Daniel Drake wrote:
> >>
> >>>Jon Wikne wrote:
> >>>
> >>>>What happens is typically this: After transeferring some
> >>>>data, ranging from less than 100kB to 10MB, the upload freezes,
> >>>>i.e. gets no further. Use of ping shows the connection is
> >>>>effectively dead. If I do a sequence /sbin/ifdown eth0
> >>>>/sbin/ifup eth0 the upload might resume, but stops again
> >>>>shortly. The phenomenon seems to occur sooner if the path
> >>>>to the remote system is _fast_ (low ping times).
> >>>
> >>>You can try applying this patch:
> >>>http://developer.osdl.org/shemminger/prototypes/sky2-proc-debug.patch
> >>>
> >>>It will add a /proc/net/sky2/ethX file, which lists the status of the TX 
> >>>and status rings. You should compare the contents of this file during 
> >>>normal operation to when the interface has hung.
> >>
> >>Thanks, Daniel. I applied the patch.
> >>
> >>The output of 'cat /proc/net/sky2/eth0' under normal circumstances
> >>is here:
> >>
> >>http://puma.uio.no/sky2/sky2-status-normal.txt
> >>
> >>After the interface hangs, 'cat /proc/net/sky2/eth0' causes the
> >>whole computer to hang completely. No kernel oops or other
> >>messages in the console window. Power down is the only
> >>solution.... :-[ No log entries after reboot.
> >>
> > It could be the code in the debug patch is walking off into space.
> > The smaller version of the same patch, doesn't walk but just reports
> > the index values.
> [ patch ]
> 
> OK, I applied that. Part of it (5 hunks) had to be done manually, since
> it appeared not to be relative to the version in 2.6.18-rc4 which I was
> using.
> 
> The result is:
> 
> Normal operation:
> Status ring (empty)
> Tx ring (empty)
> Rx pending hw get=60 put=256 last=511

The chip has prefetched some of the 254 frames we gave it.

> Error condition:
> Status ring (empty)
> Tx ring 338..378

40 packets waiting to send

> Rx pending hw get=316 put=0 last=511

So there are some frames waiting to be received as well.
Looks like a missed interrupt.  Is there anything surprising in the
ethtool stats?  (ethtool -S eth0)

In the past, when there were flow control hardware bugs
there would be suspicious statistics like "1 mac pause frame received".


> 
> 
> -- Jon
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Stephen Hemminger <shemminger@osdl.org>

All non-trivial abstractions, to some degree, are leaky.