[eepro100] eth0: card reports no resources
Wed Sep 18 07:46:01 2002
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
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
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 (email@example.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 firstname.lastname@example.org
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993