Re: Intel 82559 NIC corrupted EEPROM

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

On 11/9/06, John <[email protected]> wrote:

> The second thought is that the adapter is in D3, and something about
> your kernel or the driver doesn't successfully wake it up to D0.

On my NICs, the EEPROM ID (Word 0Ah) is set to 0x40a2.
Thus DDPD (bit 6) is set to 0.

DDPD is the "Disable Deep Power Down while PME is disabled" bit.
0 - Deep Power Down is enabled in D3 state while PME-disabled.
1 - Deep Power Down disabled in D3 state while PME-disabled.
This bit should be set to 1b if a TCO controller is being used via the
SMB because it requires receive functionality at all power states.

Are you suggesting I try and set DDPD to 1?
Or is this completely unrelated?


This may be related but I doubt it.  Something is strange about how
memory is being mapped in your system.  whatever is creating the
problem moved when you changed the kernel version.  I'm wondering if
there is a device collision at e5302000.  I'm not convinced at this
point it is e100's fault.

can you send output of cat /proc/iomem


> An indication of this would be looking at lspci -vv before/after
> loading the driver.

$ diff -u lspci_vv_before_e100.txt lspci_vv_after_e100.txt
--- lspci_vv_before_e100.txt    2006-11-09 14:51:30.000000000 +0100
+++ lspci_vv_after_e100.txt     2006-11-09 14:51:30.000000000 +0100
@@ -74,21 +74,20 @@
         Expansion ROM at 20000000 [disabled] [size=1M]
         Capabilities: [dc] Power Management version 2
                 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
-               Status: D0 PME-Enable+ DSel=0 DScale=2 PME-
+               Status: D0 PME-Enable- DSel=0 DScale=2 PME-


okay when the driver loads it is clearing PME enable, but not
re-enabling it when it unloads.  That is pretty much expected.


  00:09.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro
100] (rev 08)
         Subsystem: Intel Corporation EtherExpress PRO/100B (TX)
-       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
+       Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
         Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium
 >TAbort- <TAbort- <MAbort- >SERR- <PERR-


pci_enable_device should be enabling io,mem,busmaster, they are
probably being disabled when the driver errors out of init.  maybe you
should add a call to  pci_set_power_state(dev, PCI_D0); before the
call to e100_reset


> Also, after loading/unloading eepro100 does the e100 driver work?

No.


now that is really odd.


> A third idea is look for a master abort in lspci after e100 fails to
> load.

I don't understand that one.


There isn't one, MAbort+ would be showing in the above lspci output.

The all 0xffffffff returns when you read registers is a sure sign the
hardware either isn't at the address specified or is in a power down
state.  The only other option i can think of is that something else is
intercepting memory reads and writes.

try something like the attached patch, compile tested only:

Attachment: e100_debug.patch
Description: Binary data

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux