82559ER: PHY detection fails, MII not accessible

Hello,

I'm seeing some interesting things with some 82559ER controllers. We were 
attempting link beat detection, on one of the controllers, this worked 
flawlessly; the other seems to have an unsupported register layout.

I've attached the output of lspci -v and eepro100-diag:

00:12.0 Ethernet controller: Intel Corp. 82559ER (rev 10)
        Flags: bus master, medium devsel, latency 66, IRQ 11
        Memory at fc020000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at 1080 [size=64]
        Memory at fc000000 (32-bit, non-prefetchable) [size=128K]
        Expansion ROM at <unassigned> [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2

[root] #./eepro100-diag -aavvvvDf
eepro100-diag.c:v2.05 6/13/2001 Donald Becker ([email protected])
 http://www.scyld.com/diag/index.html
Index #1: Found a Intel 82559ER EtherExpressPro/100+ adapter at 0x1080.
i82557 chip registers at 0x1080:
  0c000050 0fc54000 00000000 00080002 19450000 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.
 The Command register has an unprocessed command 0c00(?!).
EEPROM size probe returned 0xff8c000, 6 bit address.
EEPROM contents, size 64x16:
    00: 3000 0159 ad80 4701 0000 000a 000a 4000
  0x08: 0004 8086 0000 0000 0000 0000 0000 0000
      ...
  0x38: 0000 0000 0000 0000 000c 0000 0000 d436
 The EEPROM checksum is correct.
Intel EtherExpress Pro 10/100 EEPROM contents:
  Station address 00:30:59:01:80:AD.
  Receiver lock-up bug exists. (The driver work-around *is* implemented.)
  Board assembly 000480-134, Physical connectors present: BNC MII
  Primary interface chip None PHY #10.
[root] #

I have tried to decode the MDI status word following Intel's "Open source 
8255x guide"; the PHY address shown in the dump is 01010b (on the working 
chipset, it was 00001). 

Finding out the PHY adress in eepro100-diag seems to go via the EEPROM:

phy0 = eeprom_contents[6] & 0x8000 ? -1 : eeprom_contents[6] & 0x1f;
phy1 = eeprom_contents[7] & 0x8000 ? -1 : eeprom_contents[7] & 0x1f;

eeprom_contents[6] is 0x000a, [7] is 0x4000. I could not find any docs on 
these specific registers.

On the working chipset, [6] is 0x4701 and [7] is 0x0000. 

That should mean phy0 on the working chipset is 0x01 & 0x1f, which is 0x01.

On the non-working chipset, phy0 (and phy1) is 0x00, which seems to indicate 
"no PHY!"

However, that seems entirely unlikely (networking does work there :-))

Maybe the EEPROM is structured differently on this specific chipset, so the 
assumption that EEPROM info is stored in eeprom_contents[6] is wrong?
eeprom_contents[3] and eeprom_contents[4] seem like good candidates :-)

However, the other EEPROM information registers (like what Physical connectors 
are present) are likely in the wrong place, too (a quick change to the 
eepro100-diag.c source code let it find the PHY#1, as was expected). 

Any ideas how I can proceed now?

-Malte #8-)

BTW: We're using a 2.4.17 kernel with rtai extensions, but it doesn't work 
with newer 2.4 kernels either