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

Discussion in 'Linux Networking' started by Bill Brelsford, Jan 17, 2007.

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

    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

    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
    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, Jan 17, 2007
    1. Advertisements

  2. Bill Brelsford

    Moe Trin Guest

    00:4C:69:6E:75:7C, IRQ 10.


    [compton ~]$ etherwhois 00:4C:69
    Non-existent address as of Dec 18 17:25:59 MST 2006 OUI file
    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: <>
    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 ""
    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.
    Which driver are you trying to use? There are several that work with
    a "tulip" type of card - some better than others.

    Old guy
    Moe Trin, Jan 17, 2007
    1. Advertisements

  3. 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.
    That's about what I thought. Thanks for providing a detailed
    I'm using the driver that comes with the kernel:

    # CONFIG_DE2104X is not set
    # 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
    Bill Brelsford, Jan 17, 2007
  4. Bill Brelsford

    Moe Trin Guest

    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)
    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:

    This can be solved by using the 'pci-scan' module and updated driver

    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.
    (Donald Becker)
    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
    Moe Trin, Jan 18, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.