There are two threads now with similar complaints. I'll add some detail
from my own setups.
[EMAIL PROTECTED] said:
> On Sat, 31 Jul 1999, Dave Wreski wrote:
>
> > Hi all. I just purchased an eepro100, and it's not performing as well as
> > I expected. If I use 'ping -f remotehost' to a host on the same subnet,
> > the hub collision light turns on solid, and percentage of packets lost is
> > about 2% for 60k packets. Collisions are 25k from that it appears.
>
> > eth0: Intel PCI EtherExpress Pro100 at 0xef00, 00:90:27:8B:x:y, IRQ 10.
> > Receiver lock-up bug exists -- enabling work-around.
>
> This is an almost impossibly rare problem, it only occurs at 10Mbps.
> However, since the result is so severe (a complete reciever hang) the driver
> monitors the receive traffic to avoid it. Reportedly only the oldest chips
> have this bug, but the EEPROM hasn't been updated to indicate the fix.
Disabling the sp->rx_bug workaround seems to have no bad effect on my
late-model 82558, and even with it turned on it only triggers set_rx_mode
once every 2 seconds. Do I need to write the eeprom to influence the
behavior of the card? I'm assuming that since both my different eepro100s
say that and they're fairly new, the bug workaround is not necessary.
For my setup, cabling is not a problem. Everything is full-duplex and I
can get over 40 Mb/s at times. /proc/net/dev has an error rate of only
1.0e-8 on the router machine that's been up two months: 6 fifo tx errs.
During large transfers to machines which are physically nearby, on the
same 100 Mb/s FD switch, I frequently get pauses in the transfer and
complaints:
Transmit timed out: status 0050 0000 at 3229/3243 command 000c0000.
Tx ring dump:
0 000ca000.
1 000ca000.
2 000ca000.
3 000ca000.
4 000ca000.
5 000ca000.
6 000ca000.
7 000ca000.
8 000ca000.
9 000ca000.
10 400ca000.
11 000ca000.
12 000ca000.
*13 000c0000.
14 000ca000.
15 000ca000.
Trying to restart the transmitter...
The status is always the same, dirty/cur vary but are usually 14 steps
apart (sometimes 13 or 15). The ring dump elements are always the same
(pattern, not location), although the 0x400ca000 entry will sometimes be
only 0x4003a000. I don't see mappings for those bits in RxFD_bits.
This is 2.3.9 UP, eepro100 driver 1.09c. Any advice?
-- Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
