Hello Donald, Got v1.04 & am compiling up 2.0.35 + alan pre-14
now , Will report back soon on the mii-diag necessity problem.
Hth, JimL
On Sun, 11 Oct 1998, Donald Becker wrote:
> On Sun, 11 Oct 1998, Matti Aarnio wrote:
> > The version of the Tulip driver at 2.1.124 contains various other
> > bugfixes, most important of which (I think) is SKB allocation out-of-memory
> > handling code, which Donald has not yet believed to be necessary for those
> > drivers which have rx_skbuff[] rings. :-(
>
> Look again: the older versions of the tulip driver (and most other
> descriptor-based bus-master driver) used an drop-immediately scheme. If
> they could not allocate a refill skbuff, they dropped the packet and kept
> the old skbuff on the receive ring. This was to avoid having the chip ever
> shut down from lack of receive buffers.
>
> This worked pretty well until there was a kernel version that tended to keep
> too little free memory around for interrupt handlers. Even though there was
> plenty of physical memory, it was all being used for buffer cache. This
> caused drivers to drop a lot of packets even though a few milliseconds later
> the kernel could come up with a whole bunch of free memory.
>
> So I slowly changed all of my descriptor-based drivers to instead use a
> "buffer deficit" scheme, where the driver passes all of the received
> packets to the queue layer in the first phase, and then refills the receive
> ring later. If the machine runs temporarily short of memory the recieve
> ring will be refilled at the next Rx interrupt. Only if it's persistently
> short of memory will the receive ring empty of buffers and drop packets.
>
> This "buffer deficit" scheme has another beneficial effect: most new chips
> which implement hardware flow control can only trigger FC packets when
> running out of buffers, not in response to a driver-level request. BTW,
> hardware flow control is unrelated to the misnamed code in the new kernel.
> That new code should be called "randomly drop packets when actually doing
> work".
>
> > Speaking of which, a quick browse shows me that:
> >
> > tulip.c at 2.0.35 has this rx_skbuff[] ring problem.
>
> See above -- it just has a different structure.
>
>
> > 3c59x.c (up to and including version 0.99G!) driver does blow up if that
> > ring can not be refilled successfully...
>
> The 3c59x.c driver has a related bug: it has a limit check at the end of a
> loop instead of the beginning. (A mistaken optimization on my part.) If
> the receive ring cannot be filled and empties completely, there are
> obviously no packets to receive. But with the limit check at the end of the
> loop, the driver will think that and old, already-processed packet is a new
> one. Disaster occurs.. This same bug exists in the eepro100.c driver.
> (However the current tulip driver *does* have the check in the correct
> place.)
>
> > eepro100.c's code (at 2.1.124, v0.36) is rather unclear at what it does,
> > but it looks likely to be able to survive the situation.
>
> That old driver version has another low-memory receive bug, and a multicast
> list race condition. The new driver, v1.04, supports newer board versions, is
> much more robust when rapidly changing large multicast filters (Appletalk
> environments!), cache aligns transmit descriptors, and enables hardware flow
> control on the i82558.
>
> > de4x5.c (v0.542) driver will always alloc a new skb at an Alpha, and
> > then copy the data there. If the alloc fails, it is skipped. (No kernel
> > crash from that...) (But this isn't Donald's rx_skbuff[] beasts either..)
>
> That's similar to what my drivers used to do. It's a natural progression
> from the original driver model, which was "copy into a fresh skbuff", to the
> zero-copy "receive directly into an skbuff and refill the slot immediately".
>
> An advantage to copying with the Alpha is that the Tulip must have
> word-aligned receive buffers. With 14 byte Ethernet headers, the IP headers
> are always misaligned. The Linux protocol code doesn't (didn't) have
> get_unaligned() calls for disassembling packets, so uncopied packets cause
> alignment traps. When copying packets (or with a better chip) you can do
> skb_reserve(skb,2) to align the IP header.
>
> Donald Becker [EMAIL PROTECTED]
> USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
> Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
> 301-286-0882 http://cesdis.gsfc.nasa.gov/people/becker/whoiam.html
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-net" in
> the body of a message to [EMAIL PROTECTED]
>
, JimL
+-----------------------------------------------------------------------+
| James W. Laferriere - Network Engineer - [EMAIL PROTECTED] |
| System Techniques - 25416 - 22nd S. - Des-Moines, WA 98198 |
| Give me VMS -or- Give me Linux -but- only on AXP |
+-----------------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
