[tulip] Compaq Presario laptop and tulip PCMCIA card

[Donald Becker]

On 7 Mar 2002, Jesse F. Hughes wrote:
> Donald Becker <becker@scyld.com> writes:
> > On 6 Mar 2002, Jesse F. Hughes wrote:
> >
> > Where are you getting the name "level one"?  Level One makes
> > transceivers, but the chip on the Linksys card is from ADMtek.
> 
> It's what's printed on the box.  "Level one 10/100Mbps Ethernet PC
> Card".
> Perhaps a different company of the same name?

It's likely the same OEM as the Linksys card, with the box printed in a
Asian country that doesn't enforce trademark laws.

> Mar  7 11:33:44 diogenes kernel: tulip.c:v0.93 11/7/2001  Written by Donald Becker <becker@scyld.com>
> Mar  7 11:33:44 diogenes kernel:   http://www.scyld.com/network/tulip.html
> Mar  7 11:33:44 diogenes kernel: cs: cb_config(bus 32)
> Mar  7 11:33:44 diogenes kernel:   fn 0 bar 1: io 0x800-0x8ff
> Mar  7 11:33:44 diogenes kernel:   fn 0 bar 2: mem 0x60060000-0x600603ff
> Mar  7 11:33:44 diogenes kernel:   fn 0 rom: mem 0x60040000-0x6005ffff
> Mar  7 11:33:44 diogenes kernel:   irq 9

Hmmm, these look like reasonable resource assignments.

> Mar  7 11:33:44 diogenes cardmgr[466]: get dev info on socket 0
failed: No such device 

I can't figure out what went wrong here.  The cardmgr program, which is
part of the PCMCIA package, couldn't find the device.

> Also, by default, my distribution runs i82365 with the option
> "poll-interval=100".  I *thought* that meant that no IRQ would be
> assigned to the i82365 module, but it appears I just don't know.

There are two kinds of IRQ usage:
  The CardBus/PCMCIA controller uses it to report that a card has been
  inserted or ejected
  The CardBus card uses it to raise a device interrupt.

For historical, structural reasons (support of ISA connected PCMCIA
controllers, and ISA-like 16-bit PCMCIA cards) the Linux PCMCIA code
doesn't like to put both types of interrupt sources on a single IRQ.
Setting the poll interval removes the need for the first type of
interrupt.

> This is the output from the diagnostic program:
> 
> -----------------------------------------------------------
> Unable to find a recognized card in /proc/pci.

Note that the program first looks in /proc/bus/pci/

> When I offer the options "-p 0x800 -t 17", I am told that a recognized
> chip has been found but does not appear to exist in I/O space.

A little misleading: it should say "I'm trusting that you the chip is
there, but I can't find a device at that address."

>  Interrupt sources are pending!  CSR5 is ffffffff.
>   Comet MAC address registers ffffffff ffffffff
>   Comet multicast filter ffffffffffffffff.

When no device exists the value returned is 0xffffffff

> And this is the relevant section of /proc/pci.
> 
> -----------------------------------------------------------
> PCI devices found:
>   Bus 32, device   0, function  0:
>     Ethernet controller: Unknown vendor Unknown device (rev 17).
>       Vendor id=13d1. Device id=ab08.

This explains part of the problem: This is a new device ID.

Try adding the following new table entry to tulip.c.

	{ "ADMtek Centaur-C (Linksys)", { 0xab0313d1, 0xffffffff },
	  TULIP_IOTYPE, TULIP_SIZE1, COMET },
+	{ "ADMtek Centaur-C (Linksys)", { 0xab0813d1, 0xffffffff },
+	  TULIP_IOTYPE, TULIP_SIZE1, COMET },
	{ "STMicro STE10/100 Comet", { 0x0981104a, 0xffffffff },
	  TULIP_IOTYPE, TULIP_SIZE1, COMET },

I've put this in v0.93b which will appear at
    ftp://www.scyld.com/pub/network/test/tulip.c
if you report that it works.

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Second Generation Beowulf Clusters
Annapolis MD 21403			410-990-9993