[eepro100] eth0: card reports no resources

[Donald Becker]

On Tue, 17 Sep 2002, John Jones wrote:

> > That's a modified version of a modified driver...
> I didn't do it!!!  I just inherited the box! ;)
> 
> > > > What is the incoming packet rate?
> Do you have any suggestions on something that we can keep running on the
> console for when this happens?  A command-line tool to see the packet rate?

The /proc/ file system makes a simple history log simple to configure:

while sleep 5; do
   date
   cat /proc/net/dev
done >> /tmp/netstat.log

> > One thing I -am- seeing is a ton of frame errors on the nic:
> >           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
> >           RX packets:2616981 errors:0 dropped:0 overruns:0 frame:46855
> 
> What is reported in /proc/net/dev?  The 'ifconfig' program reads the raw
..
> [root@sieve /root]# cat /proc/net/dev
> Inter-|   Receive                                                |  Transmit
>  face |bytes    packets errs drop fifo frame compressed multicast|bytes
>   eth0:660772930 4104383    0    0    0 59664          0         0
...> 
> Holy crap!  I just did it 10 secs after doing that and got:
> 
>   eth0:663099751 4132672    0    0    0 96432          0         0

The eepro100 NIC has a curious way to report statistics.  It keeps the
values internally inside the chip, and the driver triggers the chip to
write the statistics to a memory region.  The problem with this is that
the chip can take a long time to write that memory region.

To avoid a long delay each time reading statistics, the driver does the
following steps
   adds the previous statistics dump to the driver's statistics table,
   triggers a dump of the chip's statistics values, and
   reports the driver's statistics table.

This usually works well because of a quirk in the way /proc/net/dev is
built: the driver statistics are polled twice, once to compute the
output size and a second time for the actual numbers.
But when the NIC is busy, it puts off writing the statistics table.  The
second statistics calls can occur before the latest values are written
by the NIC.

> [root@sieve /root]# ./mii-diag -v
> mii-diag.c:v2.00 4/19/2000  Donald Becker (becker@scyld.com)
...
>  Basic mode control register 0x2100: Auto-negotiation disabled, with
>  Speed fixed at 100 mbps, full-duplex.

This, combined with seeing many Rx frame error, causes me to ask the
usual question: do you have a duplex mismatch?  Forcing full duplex is
very often a mistake.  Using the default setting of autonegotiation is
always preferable.  If your link partner can't do autonegotiation, you
want half duplex anyway.

-- 
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