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_01C0A807.DE7DFCD0
Content-Type: text/plain;
charset="iso-8859-1"
Hi,
I've been tracking this problem down for a couple of days and have arrived
at this point. I am continuing
to investigate but I thought that now would be a good time to post something
and see if someone has
already solved this problem...
We have RedHat 6.2 running on a cPCI cage (running on both the system slot
card and the peripheral
cards). The system slot card (the host card) is a boot server for the slave
cards. The host card has two
ethernet interfaces, one for the "public" LAN and one for the slave card
network (192.168.0.x). Occasionally
we would notice that the slave cards would not boot up when the cage was
rebooted.
We gradually started booting with fewer and fewer drivers and other cards in
the system, until we got down
to just a few slave cards and the system card. The problem is reproducible
in every case, and I would say
it is reproducible on 50% - 80% of all reboots. Note that rebooting likely
has nothing to do with it but the
eepro driver is compiled into our kernel, so rebooting is how we're
reproducing the problem.
What happens is that eth0 - the public LAN interface - works fine. But eth1
- the interface for the slave
cards to network boot - does not receive or transmit any packets. In all
other immediately observable
aspects, eth1 appears normal.
Here is the output from eepro100-diag when run on eth1:
eepro100-diag.c:v2.02 7/19/2000 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #2: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at
0x1440.
i82557 chip registers at 0x1440:
00900000 07fee800 00000000 00080002 182545e1 00000000
No interrupt sources are pending.
The transmit unit state is 'Idle'.
The receive unit state is 'Idle'.
This status is unusual for an activated interface.
The Command register has an unprocessed command 0090(?!).
EEPROM contents, size 64x16:
00: 0100 02af a047 0000 0000 0201 4701 0000
0x08: 7132 3402 40a0 000c dec0 0003 0000 0000
...
0x38: 0000 0000 0000 0000 0000 0000 0000 091f
The EEPROM checksum is correct.
Intel EtherExpress Pro 10/100 EEPROM contents:
Station address 00:01:AF:02:47:A0.
Receiver lock-up bug exists. (The driver work-around *is* implemented.)
Board assembly 713234-002, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
MII PHY #1 transceiver registers:
3000 782d 02a8 0154 05e1 45e1 0001 0000
0000 0000 0000 0000 0000 0000 0000 0000
0a03 0000 0001 0000 0000 0000 0000 0000
0000 0000 0b10 0000 0000 0000 0000 0000.
As you can see, the interface is active but has an unusual status, including
an unprocessed
command in the command register.
Once this problem happens, it will generally persist for several reboots but
it will eventually
go away and eth1 will work OK. After a few more reboots, the problem will
come back.
As I say, I am continuing to investigate but I thought I'd throw this out
and see if anyone could
save me some time :-) Oh - by the way, we're using version 1.09j-t of
eepro100.c.
Thanks,
Ed
Ed Elberson, JZ40
Global Tools and Automation
Richardson Texas
ESN 444-0316
(972) 684-0316
ewe@nortelnetworks.com
------_=_NextPart_001_01C0A807.DE7DFCD0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
eepro100 interface unusable; unprocessed command (?!) in command =
register
Hi,
I've been tracking this problem down =
for a couple of days and have arrived at this point. I am =
continuing
to investigate but I thought that now =
would be a good time to post something and see if someone has
already solved this problem...
We have RedHat 6.2 running on a cPCI =
cage (running on both the system slot card and the peripheral
cards). The system slot card (the =
host card) is a boot server for the slave cards. The host card has =
two
ethernet interfaces, one for the =
"public" LAN and one for the slave card network =
(192.168.0.x). Occasionally
we would notice that the slave cards =
would not boot up when the cage was rebooted.
We gradually started booting with =
fewer and fewer drivers and other cards in the system, until we got =
down
to just a few slave cards and the =
system card. The problem is reproducible in every case, and I would =
say
it is reproducible on 50% - 80% of =
all reboots. Note that rebooting likely has nothing to do with it but =
the
eepro driver is compiled into our =
kernel, so rebooting is how we're reproducing the problem.
What happens is that eth0 - the public =
LAN interface - works fine. But eth1 - the interface for the =
slave
cards to network boot - does not =
receive or transmit any packets. In all other immediately =
observable
aspects, eth1 appears normal.
Here is the output from eepro100-diag =
when run on eth1:
eepro100-diag.c:v2.02 7/19/2000 Donald =
Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #2: Found a Intel i82557 (or =
i82558) EtherExpressPro100B adapter at 0x1440.
i82557 chip registers at =
0x1440:
00900000 07fee800 00000000 =
00080002 182545e1 00000000
No interrupt sources are =
pending.
The transmit unit state =
is 'Idle'.
The receive unit state =
is 'Idle'.
This status is unusual for an =
activated interface.
The Command register has an =
unprocessed command 0090(?!).
EEPROM contents, size 64x16:
00: 0100 02af a047 =
0000 0000 0201 4701 0000
0x08: 7132 3402 40a0 000c dec0 =
0003 0000 0000
=
...
0x38: 0000 0000 0000 0000 0000 =
0000 0000 091f
The EEPROM checksum is =
correct.
Intel EtherExpress Pro 10/100 EEPROM =
contents:
Station address =
00:01:AF:02:47:A0.
Receiver lock-up bug exists. =
(The driver work-around *is* implemented.)
Board assembly 713234-002, =
Physical connectors present: RJ45
Primary interface chip i82555 =
PHY #1.
MII PHY #1 transceiver =
registers:
3000 782d 02a8 0154 05e1 45e1 =
0001 0000
0000 0000 0000 0000 0000 0000 =
0000 0000
0a03 0000 0001 0000 0000 0000 =
0000 0000
0000 0000 0b10 0000 0000 0000 =
0000 0000.
As you can see, the interface is =
active but has an unusual status, including an unprocessed
command in the command =
register.
Once this problem happens, it will =
generally persist for several reboots but it will eventually
go away and eth1 will work OK. After =
a few more reboots, the problem will come back.
As I say, I am continuing to =
investigate but I thought I'd throw this out and see if anyone =
could
save me some time :-) Oh =
- by the way, we're using version 1.09j-t of eepro100.c.
Thanks,
Ed
Ed Elberson, JZ40
Global Tools and =
Automation
Richardson Texas
ESN 444-0316
(972) 684-0316
ewe@nortelnetworks.com
------_=_NextPart_001_01C0A807.DE7DFCD0--