[eepro100] Newbie: eth1: card reports no resources

[Donald Becker]

On Mon, 4 Feb 2002, Ryan Hill wrote:

> > > Feb  3 04:02:12 devastator kernel: eth1: card reports no resources. 
> > > Feb  3 04:08:48 devastator last message repeated 75 times
> > 
> > You are likely running out of memory.
> 
> Really?  My memory consumption is:

You might be temporarily running out of skbuffs.  That's not directly
reflected in the free memory report at some later time.

[[ It would be very interesting to have counters on the allocation
function to report how often allocation failed.  Hmmmm, perhaps I'll add
one to the eepro100 driver just to isolate problems such as this.

> Mem:   382048K av,  378912K used,    3136K free,      48K shrd,   19004K
> buff
> Swap:  787264K av,  115736K used,  671528K free                  177964K
> cached

You are using swap space, which means that at one point you ran short of
memory.  But even if swap space usage is zero, you might have run short
of available skbuffs during an interrupt.  This can happen even when
there are still "pure" pages that could freed without needing to be
swapped out.

> And has consistently operated in this range for months without problems.
> Also, these messages begin immediately after start-up, when almost all of my
> memory is still free.

This could be because the skbuff allocator isn't primed.  The kernel
dynamically increases the number of skbuffs based on the need.  (I'll
omit the complaint about the extra layers in the 2.4 kernel.)

>  My eth2 card is the exact same model, and has never
> reported this message, ever, since the box was built.

Possible answers:
   It's not in promiscuous mode and thus doesn't see the same traffic
   bursts when memory is short.

   One chip has the "no resources" firmware bug.  Normally I would be
   blaming this bug, but from your report a memory shortage is more
   likely.

> So, are these messages indicating my buffer size is set too low (if so,
> where do I change this?), or that I'm running out of physical memory to
> process the packets?

Change the Rx ring size.
It is a compile time constant near the top of the source file.
    #define RX_RING_SIZE	32

Increasing this value lets the driver hoard skbuffs for shortages.  Each
buffer consumes 1.5-2KB of memory, so you should only increase the
setting for machines that you personally verify are deployed with lots
of memory.  

The comment says
/* The ring sizes should be a power of two for efficiency. */
but you can ignore this on modern machines.  The extra modulus
operations are hidden by memory latency.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993