Intel PRO/100+ Server Adapter w/ Redhat

[Erik Barker]

I'm currently running a server with 2 identical Intel PRO/100+ (i82559)
cards running on a Redhat 5.2 box with the 2.2.12 kernel.  I replaced the
default (1.06) eepro100.c file in the kernel directory with the newest ver.
1.09l and recompiled fine.  I rebooted and got the following information:

eth0: Intel PCI EtherExpress Pro100 at 0xc4802000, 00:90:27:9F:A0:CE, IRQ
10.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 729757-004, 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).
eth1: Intel PCI EtherExpress Pro100 at 0xc4804000, 00:90:27:9F:D2:A3, IRQ
11.
  Receiver lock-up bug exists -- enabling work-around.
  Board assembly 729757-004, 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.09l 8/7/99 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html

It looks like its finding an incorrect interface chip version because I'm
running the i82559 (so says the box and chips), not the i82555.  Is there
something I have to change in the driver source to force it to use the
i82559 or is this display output simply cosmetic?

Another inconsistency is that I compiled the eepro100-diag program with the
libmii.c file and although I needed to take down the interface to get an
actual diagnostic, it found the card as an i82557???

Here's some of the output from dmesg:

eth0: Transmit timed out: status 0050  0000 at 316120/316132 command
000c0000.
eth0: Tx ring dump,  Tx queue 316132 / 316120:
eth0:   0 000ca000.
eth0:   1 000ca000.
eth0:   2 000ca000.
eth0:   3 400ca000.
eth0:  =4 000ca000.
eth0:   5 000ca000.
eth0:   6 000ca000.
eth0:   7 000ca000.
eth0:   8 000ca000.
eth0:   9 000ca000.
eth0:   10 000ca000.
eth0:   11 000ca000.
eth0:   12 000ca000.
eth0:   13 000ca000.
eth0:   14 000ca000.
eth0:   15 000ca000.
eth0:   16 000ca000.
eth0:   17 000ca000.
eth0:   18 000ca000.
eth0:   19 000ca000.
eth0:   20 000ca000.
eth0:   21 000ca000.
eth0:   22 000ca000.
eth0:   23 000ca000.
eth0: * 24 000c0000.
eth0:   25 000ca000.
eth0:   26 000ca000.
eth0:   27 000ca000.
eth0:   28 000ca000.
eth0:   29 000ca000.
eth0:   30 000ca000.
eth0:   31 000ca000.
eth0:Printing Rx ring (next to receive into 321052).
  Rx ring entry 0  00000001.
  Rx ring entry 1  00000001.
  Rx ring entry 2  00000001.
  Rx ring entry 3  00000001.
  Rx ring entry 4  00000001.
  Rx ring entry 5  00000001.
  Rx ring entry 6  00000001.
  Rx ring entry 7  00000001.
  Rx ring entry 8  00000001.
  Rx ring entry 9  00000001.
  Rx ring entry 10  00000001.
  Rx ring entry 11  00000001.
  Rx ring entry 12  00000001.
  Rx ring entry 13  00000001.
  Rx ring entry 14  00000001.
  Rx ring entry 15  00000001.
  Rx ring entry 16  00000001.
  Rx ring entry 17  00000001.
  Rx ring entry 18  00000001.
  Rx ring entry 19  00000001.
  Rx ring entry 20  00000001.
  Rx ring entry 21  00000001.
  Rx ring entry 22  00000001.
  Rx ring entry 23  00000001.
  Rx ring entry 24  00000001.
  Rx ring entry 25  00000001.
  Rx ring entry 26  00000001.
  Rx ring entry 27  c0000001.
  Rx ring entry 28  00000001.
  Rx ring entry 29  00000001.
  Rx ring entry 30  00000001.
  Rx ring entry 31  00000001.
  PHY index 1 register 0 is 3000.
  PHY index 1 register 1 is 782d.
  PHY index 1 register 2 is 02a8.
  PHY index 1 register 3 is 0154.
  PHY index 1 register 4 is 05e1.
  PHY index 1 register 5 is 4461.
  PHY index 1 register 21 is 0000.
eth0: Trying to restart the transmitter...

I've seen other people with the same results when using the ver. 1.09l
driver so I think I'll downgrade to the 1.06 which came with the 2.2.12
kernel.  Otherwise, anyone have a solution for the i82555 discrepancies??
I'd like to test this driver when it's properly identifying the chip.

TIA,

Erik