[eepro100] Problems with eepro100, RH6.2, Asus MES-N NLX

Sat, 30 Sep 2000 08:12:15 +0930

Hi Folks,

I have an Asus MES-N NLX based rack box that we recently needed
to rebuild because it had been compromised.  For the rebuild we
upgraded from RH6.1 to RH6.2 as this seemed the simplest way of
avoiding the particular vulnerabilites that had been exploited.
At the same time we added a second IDE drive.

Since rebuilding the box I have been unable to get the onboard
ethernet to work - the hub just doesn't "light up" for that port.
A cheapie PCI Realtek adapter is working fine.  As far as I have
been able to recall based on rough notes, the only change is the
RH version and the disk.  I have attempted to "fix" things by
messing with BIOS interrupt assignments without success.  In all
other respect the system seems to be operating normally.

Based on some on the discussion on this list I gather that I'm
probably using a different driver as a result of the upgrade to
RH 6.2, and this may be the cause of the change.

I'm something of a newbie in this area, so I would welcome a
little advice.

 - Can I revert to an earlier version of the driver but retain
   RH 6.2?  If so, what driver (where?) should I use and how do
   I go about building it?

 - What diagnostic procedures should I follow to diagnose and
   document the state of the driver to this list (other than
    what I show below)?

Some info that may be relevant... from the dmesg:

  Linux version 2.2.14-12 (root@porky.devel.redhat.com)
    (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release))
    #1 Tue Apr 25 12:31:52 EDT 2000

  ...

  eepro100.c:v1.09j-t 9/29/99
    Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/eepro100.html
  eepro100.c: $Revision: 1.18 $ 1999/12/29
    Modified by Andrey V. Savochkin <saw@msu.ru>
  eth0: Intel PCI EtherExpress Pro100
    at 0xc7868000, 00:E0:18:E0:05:D2, IRQ 11.
    Board assembly 668081-002, 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).
    Receiver lock-up workaround activated.
  rtl8139.c:v1.07 5/6/99
    Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/rtl8139.html
  eth1: RealTek RTL8139 Fast Ethernet
    at 0xa000, IRQ 10, 00:60:67:79:69:4f.

And ifconfig:

  eth0
    Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
    inet addr:XX.XX.XX.XX  Bcast:XX.XX.XX.XX  Mask:XX.XX.XX.XX
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    Interrupt:11 Base address:0x8000

  eth1
    Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX:XX
    inet addr:XX.XX.XX.XX  Bcast:XX.XX.XX.XX  Mask:XX.XX.XX.XX
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:236 errors:0 dropped:0 overruns:0 frame:0
    TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    Interrupt:10 Base address:0xa000

I downloaded and compiled mii-diag and it says:

  Using the default interface 'eth0'.
  Basic registers of MII PHY #1:  3000 7809 02a8 0154 05e1 0000 0000 0000.
   Basic mode control register 0x3000: Auto-negotiation enabled.
   Basic mode status register 0x7809 ... 7809.
     Link status: not established.

which looks bad ;-(    I also tried pci-config:

  pci-config.c:v2.01 7/4/2000
    Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html
  Device #1 at bus 0 device/function 0/0, 06201039.
  Device #2 at bus 0 device/function 0/1, 55131039.
  Device #3 at bus 0 device/function 1/0, 00081039.
  Device #4 at bus 0 device/function 1/1, 00091039.
  Device #5 at bus 0 device/function 2/0, 00011039.
  Device #6 at bus 0 device/function 3/0, 12298086.
  Device #7 at bus 0 device/function 3/1, 00000000.
  Device #8 at bus 0 device/function 6/0, 000d1073.
  Device #9 at bus 0 device/function 20/0, 813910ec.

I got a little confused at this poin on which one to check, but
assuming that the #1 in the mii-diag is meant to correspond to
the pci-config parameter, a pci-config -# 1 gave me:

  pci-config.c:v2.01 7/4/2000
    Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html
  Device #1 at bus 0 device/function 0/0.
    06201039 22100007 06000002 00802000 e0000000 00000000 00000000 00000000
    00000000 00000000 00000000 00000000 00000000 000000c0 00000000 00000000
    00000000 00000000 00000000 00000000 30c5012e 0a000040 00000000 00000000
    7100000a 00000000 00c10000 00000000 00009f03 00000000 00000000 00000000
    1e730080 40030060 00000800 0003092a 00000000 05000040 00000000 00000000
    10003080 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    00200002 1f000203 00000000 00000000 00000000 00000000 00000000 00000000
    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
    Base Address 0: Memory at e0000000.
    Extended capabilities, first structure at offset 0xc0.
    Extended PCI capability type 2 at 0xc0, next 0.

I then ran an eepro100diag -f -a:

  eepro100-diag.c:v2.02 7/19/2000
    Donald Becker (becker@scyld.com) http://www.scyld.com/diag/index.html
  Index #1: Found a Intel i82557 (or i82558) EtherExpressPro100B adapter at
0xa800.
  i82557 chip registers at 0xa800:
    00000050 073570e4 00000000 00080002 18250000 00000600
    No interrupt sources are pending.
     The transmit unit state is 'Suspended'.
     The receive unit state is 'Ready'.
    This status is normal for an activated but idle interface.

Maybe I've just done something basic wrong, but I can't find it!

Cheers, Dieter.

--
Dieter Jansen                                   Tetraplex Pty Ltd
dieter@tplex.com.au                      http://www.tplex.com.au/