Re: Netgear FA511 on RedHat 7.3

On 16 May 2003, Jared Warren wrote:

> First off, thanks for everyone's effort to provide this device driver.  
> 
> I'm having trouble with a Netgear FA511 on RedHat 7.3.  I'm currently
> running kernel 2.4.18-17.7.x.  I have downloaded and compiled the most
> recent netdrivers.tgz, and placed the resulting modules in
> /lib/modules/2.4.18-17.7.x/kernel/drivers/net.  When I insmod tulip, it
> confirms that it is loading the module from that location.
> 
> The primary symptom is that when I attempt (or the system attempts to)
> bring up the interface, the machine locks up hard (it's a Micron
> Transport XT2, if that matters).  The card is CardBus.

The detection message indicates that the card has been found, and
everything (up until the bus-master transfers) is working correctly.
Specifically, valid data has been read from the EEPROM.

> May 16 08:54:14 linuxlt kernel: cs: IO port probe 0x0a00-0x0aff: clean.
> May 16 08:54:14 linuxlt kernel: tulip.c:v0.95f 11/17/2002  Written by
...

OK, the driver was loaded immediately, and thus presumably automatically
by the PCMCIA subsystem.  

> May 16 08:54:14 linuxlt kernel:   The PCI BIOS has not enabled the
> device at 3/0!  Updating PCI command 0003->0007.
> May 16 08:54:14 linuxlt cardmgr[809]: initializing socket 0
> May 16 08:54:14 linuxlt cardmgr[809]: socket 0: Netgear FA511
> May 16 08:54:14 linuxlt kernel: eth1: ADMtek Centaur-C rev 17 at
> 0xd00b2000, 00:10:7A:69:94:71, IRQ 10.

Looks good so far.

> I've added the following lines to my /etc/pcmcia/config to get Card
> Services to recognize the card:
> 
> card "Netgear FA511"
>   version "N"
>   bind "tulip"

If it automatically loads the driver, these lines are OK.

> Note that that is ALL the information the card returns when it's an
> unrecognized device - no manfid or additional version info appears in
> dmesg (there are two PCIIds, but I couldn't get the card to be
> identified by specifying them instead of the version).

The key element is that the driver must have the PCI IDs in its internal
detection table.  Each PCI ID has additional information, so you can't
just tell some other part of the system "tell the driver to work with
this unknown ID anyway".

[[ I did design the "pci-scan" system to make it possible to add this
capability with an enhanced pci-scan.c.  But the implementation is more
than adding just an ID.  The information required is the same as the
current table entries, including the implementation-specific flags. ]]

> I know this can't be all the debugging information you would want, so
> please let me know what additional info you'd like.

First, verify that 'mii-diag eth1' works with the device -- it should
(and will not crash the machine).

These debugging steps are difficult because of the immediate machine
lock-up.  You'll be rebooting a lot.
My guess is that either the IRQ or bus-master configuration on the
CardBus bridge is flawed.

Do not use X windows for debugging.  The kernel will (hopefully) emit a
crash message to the text console, and that message will identify
exactly what went wrong.  You may have to disable syslog and enable
console logging.

Try another CardBus (no 16 bit PCMCIA) card.  Preferably one that uses
IRQs but is not a bus master.

Try an older or newer kernel, to get a different version of the CardBus
configuration code.

-- 
Donald Becker				[email protected]
Scyld Computing Corporation		http://www.scyld.com
914 Bay Ridge Road, Suite 220		Scyld Beowulf cluster system
Annapolis MD 21403			410-990-9993

_______________________________________________
tulip mailing list, [email protected]
To change to digest mode or unsubscribe visit
http://www.scyld.com/mailman/listinfo/tulip