FA511/tulip cardbus card fails (no EEPROM) on reboot from WinXP

Since upgrading my Winbook Si laptop's Windows partition from ME to
XP, my Netgear FA511 card fails under Linux after rebooting from
Windows:

eth0: ADMtek Comet rev 17 at 00011800, EEPROM not present, 00:4C:69:6E:75:7C, IRQ 10.

The only way to recover seems to be to power down the computer.
Restarting PCMCIA, ejecting/re-inserting the card, and rebooting
all have no effect.

I'm running Debian (both Sarge and Sid) with homebuilt kernel
2.6.18. The relevant lspci -vv output (same for working and
failing):

0000:06:00.0 Ethernet controller: Linksys 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 11)
Subsystem: Netgear: Unknown device 511a
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-
Latency: 64 (63750ns min, 63750ns max)
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 3000 [size=256]
Region 1: Memory at 16000000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at 14000000 [disabled] [size=128K]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=100mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Suggestions? Powering down the machine after WinXP is an easy
workaround, but I run Windows so infrequently that remembering to
do it isn't..

--
Bill Brelsford
(E-Mail Removed)

On Wed, 17 Jan 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <tPdrh.403808$(E-Mail Removed)>,
Bill Brelsford wrote:

>Since upgrading my Winbook Si laptop's Windows partition from ME to
>XP, my Netgear FA511 card fails under Linux after rebooting from
>Windows:

> eth0: ADMtek Comet rev 17 at 00011800, EEPROM not present,
00:4C:69:6E:75:7C, IRQ 10.

Hmmm...

[compton ~]$ etherwhois 00:4C:69
Non-existent address as of Dec 18 17:25:59 MST 2006 OUI file
http://standards.ieee.org/regauth/oui/oui.txt
004C696E7579 (Linux in hex) Tulip driver can't find EEPROM
[compton ~]$

You may want to google for that MAC address - yes it's a well known
problem, no - I don't remember what the fix is... my notes say:

--------
In c.o.l.n (Message-ID: <(E-Mail Removed) .com>
on 3/27/06, a report that the tulip _driver_ chooses 00:4C:69:6E:75:79 (Linux
in hex) as the MAC if it can't see the EEPROM. Article title was "MAC
00:4C:69:6E:75:79" posted from Oz by "(E-Mail Removed)"
--------

>The only way to recover seems to be to power down the computer.
>Restarting PCMCIA, ejecting/re-inserting the card, and rebooting
>all have no effect.

What's happening is that windoze is leaving the NIC in a strange state,
and the Linux driver you have doesn't know how to recover from that
state. When you power down, the card and associated interface gets reset
to a known state - and the Linux driver can handle that. The reason a
'reboot' doesn't fix the problem is that it is a software reset, and this
doesn't effect the hardware There is a "wire" in the computer named /RESET
which, when pulled low - yanks the chains on all hardware. This wire is
connected to the "PWR_GOOD" signal out of the power supply (the supply
voltages are above a threshold such that there is enough poop to run the
system). On a _desktop_ type of system, this wire was also connected to
the front panel RESET push button. This wire is NOT effected by a reboot
or even the "three-finger-salute" so beloved by microsoft.

>I'm running Debian (both Sarge and Sid) with homebuilt kernel
>2.6.18.

Which driver are you trying to use? There are several that work with
a "tulip" type of card - some better than others.

Old guy

In article <(E-Mail Removed)>,
Moe Trin <(E-Mail Removed)> wrote:
> On Wed, 17 Jan 2007, in the Usenet newsgroup comp.os.linux.networking, in
> article <tPdrh.403808$(E-Mail Removed)>,
> Bill Brelsford wrote:
>
>>Since upgrading my Winbook Si laptop's Windows partition from ME to
>>XP, my Netgear FA511 card fails under Linux after rebooting from
>>Windows:
>
>> eth0: ADMtek Comet rev 17 at 00011800, EEPROM not present,
>> 00:4C:69:6E:75:7C, IRQ 10.
>
> Hmmm...
>
> [compton ~]$ etherwhois 00:4C:69
> Non-existent address as of Dec 18 17:25:59 MST 2006 OUI file
> http://standards.ieee.org/regauth/oui/oui.txt
> 004C696E7579 (Linux in hex) Tulip driver can't find EEPROM
> [compton ~]$
>
> You may want to google for that MAC address - yes it's a well known
> problem, no - I don't remember what the fix is... my notes say:
>
> --------
> In c.o.l.n (Message-ID: <(E-Mail Removed) .com>
> on 3/27/06, a report that the tulip _driver_ chooses 00:4C:69:6E:75:79 (Linux
> in hex) as the MAC if it can't see the EEPROM. Article title was "MAC
> 00:4C:69:6E:75:79" posted from Oz by "(E-Mail Removed)"
> --------

I found that posting .. interesting that the MAC address in my case
is ...:7C, not ...:79. And, in my case, the card doesn't work.

>>The only way to recover seems to be to power down the computer.
>>Restarting PCMCIA, ejecting/re-inserting the card, and rebooting
>>all have no effect.
>
> What's happening is that windoze is leaving the NIC in a strange state,
> and the Linux driver you have doesn't know how to recover from that
> state. When you power down, the card and associated interface gets reset
> to a known state - and the Linux driver can handle that. The reason a
> 'reboot' doesn't fix the problem is that it is a software reset, and this
> doesn't effect the hardware There is a "wire" in the computer named /RESET
> which, when pulled low - yanks the chains on all hardware. This wire is
> connected to the "PWR_GOOD" signal out of the power supply (the supply
> voltages are above a threshold such that there is enough poop to run the
> system). On a _desktop_ type of system, this wire was also connected to
> the front panel RESET push button. This wire is NOT effected by a reboot
> or even the "three-finger-salute" so beloved by microsoft.

That's about what I thought. Thanks for providing a detailed
explanation.

>>I'm running Debian (both Sarge and Sid) with homebuilt kernel
>>2.6.18.
>
> Which driver are you trying to use? There are several that work with
> a "tulip" type of card - some better than others.

I'm using the driver that comes with the kernel:

CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
CONFIG_TULIP=m
# CONFIG_TULIP_MWI is not set
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_PCMCIA_XIRCOM is not set
# CONFIG_PCMCIA_XIRTULIP is not set

> Old guy

--
Bill Brelsford
(E-Mail Removed)

On Wed, 17 Jan 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <0mxrh.747175$(E-Mail Removed)>,
Bill Brelsford wrote:

>Moe Trin <(E-Mail Removed)> wrote:

>> Bill Brelsford wrote:

>>> eth0: ADMtek Comet rev 17 at 00011800, EEPROM not present,
>>> 00:4C:69:6E:75:7C, IRQ 10.
>>
>> Hmmm...

>> on 3/27/06, a report that the tulip _driver_ chooses 00:4C:69:6E:75:79
>> (Linux in hex) as the MAC if it can't see the EEPROM.

>I found that posting .. interesting that the MAC address in my case
>is ...:7C, not ...:79. And, in my case, the card doesn't work.

Another minor item I should have noticed - "Linux" in ASCII is actually
'4C 69 6E 75 78" not :79 ("Linuy"????), and in your case, it's even
more interesting 'Linu!" (man ascii)

>> What's happening is that windoze is leaving the NIC in a strange state,

>That's about what I thought. Thanks for providing a detailed
>explanation.

Donald Becker, author of many of the Linux NIC drivers pointed that one
out in a post long ago, and it's mentioned in the Ethernet-HOWTO relative
to some other (older) cards. One further point to ponder was his posting
(my notes don't give the date or article number) in regard to a similar
problem with an 8139 based card:

--------
>So once again I booted up the machine in Windows (98 SE) and then
>rebooted into Linux again and ... the hardware adress was once again 0.
>Shutting down the power and the booting up in Linux again gives the card
>the right address again.

This can be solved by using the 'pci-scan' module and updated driver
from
http://www.scyld.com/network/updates.html

You have a RTL8139B or RTL8139C with PCI power management.
Windows leaves PCI power management capable devices in D3-warm power
state. Neither the BIOS nor Linux knows about PCI power management.
The 'pci-scan' module, combined with the updated driver set, knows how
to restore the device to full power "D0" state before using it.
(E-Mail Removed) (Donald Becker)
--------

>> Which driver are you trying to use? There are several that work with
>> a "tulip" type of card - some better than others.
>
>I'm using the driver that comes with the kernel:

Not what I meant. There is a "Tulip" driver, but some "so-called" tulip
chipsets use the 'de4x5' or 'dmfe' driver. I'm not saying this is the
case here, but was curious.

Old guy