Thread (9 messages) 9 messages, 3 authors, 2006-08-23

Re: sky2 driver - large files upload problem

From: Stephen Hemminger <hidden>
Date: 2006-08-21 23:36:56

On Tue, 22 Aug 2006 00:04:07 +0200
Jon Wikne [off-list ref] wrote:
Stephen Hemminger wrote:
quoted
On Mon, 21 Aug 2006 16:21:07 +0200
Jon Wikne [off-list ref] wrote:
quoted
Daniel Drake wrote:
quoted
Jon Wikne wrote:
quoted
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 [off-list ref]

All non-trivial abstractions, to some degree, are leaky.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help