1.09q timeout too short?

[Steve]

Having kernel 2.3.17, eepro100,v1.09q heavily modified with tracelogs,
I'm still experiencing transmitter reset under heavy traffic.
Specifically, the speedo_timer() causing speedo_tx_timeout() reset via
the "small false-trigger window" logic.


Can I make the TX_TIMEOUT define longer and safely to avoid drop outs?



DIAGNOSTICS:

Ran mii-diag and eepro100-diag and noticed the following:

1.  MII BMSR reports the state transition from invalid link detected,
auto-neg completed, link valid.  (atypical)
2.  MII PHY Register 17: Special Control bits: Bit 10 (reserved) was set
or appeared a slow random.
3.  MII PHY Register 19: Receive False Carrier Counter was as high as 2
but mostly one.
4.  diag reports that "Transmit Unit sometime under Active state" and is
"unusual."  Perhaps it could be worded as "unusual for idle or
disconnected link."



SETUP DETAILS:

I'm running Compaq DeskPro EN series (which has no ability to change PCI
latency at BIOS level) 450 Mhz Pentium II (step2).  I'm pumping close to
3.8 Mbps thru the Intel PRO/100+ Management Adapter (P/N 721383-006)

Remote and local NIC is running 10Mbps half-duplex.


eth0: OEM i82557/i82558 10/100 Ethernet at 0xc4800000,
00:90:27:8B:A2:8C, IRQ 10
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 734938-001, Physical connectors present: RJ45
  Primary interface chip i82555 PHY #1.
  General self-test: passed.
  Serial sub-system self-test: passed.
  Internal registers self-test: passed.
  ROM checksum self-test: passed (0x04f4518b).
eepro100.c:v1.09q 9/16/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html

Again, can I jack up the TX_TIMEOUT to avoid false trigger?


Steve


--
Steve Egbert                      Skytel: 888-463-7343
Software Engineering                 FAX: 972-991-3887
Efficient Networks, Inc.          http://www.efficient.com
"These are people who work on Linux and other weird Unix
variations." -- Mike Nichols, V.P. Microsoft Corporation