Intel PRO/100+ Server Adapter w/ Redhat

Michael Barthelow m.barthelow@f5.com
Wed Sep 15 10:29:51 1999


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BEFF86.D6B17620
Content-Type: text/plain;
	charset="iso-8859-1"

The 82559 has an integrated 82555 PHY and that is what is being discovered. 

I think this is normal.

mb

> -----Original Message-----
> From: Erik Barker [mailto:erik@vip.net]
> Sent: Wednesday, September 15, 1999 12:24 AM
> To: linux-eepro100@beowulf.gsfc.nasa.gov
> Subject: Intel PRO/100+ Server Adapter w/ Redhat
> 
> 
> 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
> 
> 

------_=_NextPart_001_01BEFF86.D6B17620
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">



RE: Intel PRO/100+ Server Adapter w/ Redhat



The 82559 has an integrated 82555 PHY and that is = what is being discovered.

I think this is normal.

mb

> -----Original Message-----
> From: Erik Barker [mailto:erik@vip.net]
> Sent: Wednesday, September 15, 1999 12:24 = AM
> To: linux-eepro100@beowulf.gsfc.nasa.gov
> Subject: Intel PRO/100+ Server Adapter w/ = Redhat
>
>
> 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.htm= l
>
> 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:  =3D4 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
>
>

------_=_NextPart_001_01BEFF86.D6B17620--