| gabriel rosenkoetter on Mon, 10 Dec 2001 06:40:16 +0100 |
|
On Sun, Dec 09, 2001 at 08:40:41PM -0500, William Shank wrote:
> having lots of trouble at home , 10T network but works ok at work , T100.
>
> here is what dmesg shows: - be sure to look at bottom of message -
Fair warning: I don't know much about the hardware or the driver
involved here, so this is merely an educated guess. You would do
well to contact the maintainer of driver for your ethernet card
with the information you sent to the list. (His name ought to be
listed in the source for the driver. It's at
src/linux/drivers/net/eepro100.c. Looks like the current maintainer
is Andrey V. Savochkin <saw@saw.sw.com.sg>, though that may have
changed since the source I have handy.)
In general, If you're seeing ring overruns it's a sign either that
the cable modem/network is severely broken (probably in design) or
that your ethernet driver's or card's 10BaseT mode or NACK
transmission is broken.
The most fixable problem there is the driver. You might want to have
a look (or ask that someone--say, the maintainer--to have a look) at
how it's handling lost packets. It might be enough just to make the
ring buffer longer for 10BaseT.
The problem here, to my eye, is that your card is sending a NACK
for some (ethernet) packet and then not receiving that packet before
it gets back to the slot ring buffer where the packet needs to be
stored (that's what "next to receive into 668, dirty index 668"
implies). This is bad because it can't actually reconstruct the
message of which that packet was a part, so whatever stream that
message was a part of is completely borked (which is how the driver
justifies bailing on the connection entirely).
If you're unlucky, this is caused because your ISP is blocking the
outgoing NACK, which means the other end never sees it and never
responds. (Actually, that's pretty unlikely, as NACKs are typically
piggy-backed on real-data packets, but there are other, more
complicated but similar, kinds of braindeadness in your ISP's
network that could cause this.) In this case, increasing the size
of the ring buffer won't do a damn thing.
Also, if the way in which your ethernet driver sends NACKs is broken,
increasing its ring buffer won't help. You may not see this on your
100BaseT network at work because packet collisions and lossage don't
happen there. (You could force a packet loss by unplugging some
network cable between your machine and whatever it's connected to
and plugging it back in again quickly. Your machine will send a
bunch of NACKs and, if the NACKing in your driver is broken, you'll
see the same ring overflow in a few moments that you do at home.)
Just remembered that I actually do have access to Linux kernel
source these days (and added the paranthetical back in the first
paragraph), so let's have a look...
If you just want to bump up the ring buffer size (probably best to
bump both TX and RX buffer sizes), change the #defines for
{T,R}_RING_SIZE (line 68 and 69 in my copy). Make sure you keep them
a power of 2. You'll have to either recompile your kernel or the
module (depending on which you're using) after doing so. Hrm. Looks
like those RING_SIZE values are used to allocate DMA on the card
itself... so setting them too large may cause the driver to
completely break (there's only so much DMA to be had). That'd be
bad. But isn't a *huge* deal (just means that device attachment of
the card will fail; oh well, just recompile the kernel with smaller
settings).
More than that is beyond what I really have time to dig through
tonight. But that's maybe enough to get you started.
> help is appreciated
Hope this does. I'll be interested to hear how this turns out.
--
gabriel rosenkoetter
gr@eclipsed.net
Attachment:
pgpeis8ihAXPq.pgp
|
|