>I've the following program running as init, and when I ping -f, after
>about 200 packets, my program stops and the kernel doesn't responds to
>pings anymore.
Sounds like all might not be well with the 3com driver still. I tried flood
pinging my NetWinder (2.2.2/rmk4/philb990301) and everything seemed ok.
fountain:/home/pb# ping -f pig
PING pig.nexus.co.uk (192.0.0.23): 56 data bytes
....
--- pig.nexus.co.uk ping statistics ---
25280 packets transmitted, 25276 packets received, 0% packet loss
round-trip min/avg/max = 0.6/3.3/145.1 ms
fountain:/home/pb#
Is there a later version of 3c59x.c on Becker's web site? Might be worth
taking a look. I had a quick glance at the current version and it looks like
the consequences of failing to allocate a receive buffer might be bad. Also
the DMA cache flushing isn't quite right. We need to flush the cache
immediately after allocating the skb, not after it's been filled by the card.
Otherwise there might be dirty lines sitting in the cache that could in theory
get evicted on top of the newly-written packet - unlikely but possible. And I
think there should be a cache flush at around line 1813 too -- ie just after
we memcpy the data out of a buffer that's going to be recycled.
Russell, I don't quite understand why ARM systems do better with copybreak set
to infinity. Can you explain why that is?
p.
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
