Re: Tulip driver hangs detecting MAC

On Wed, 6 Nov 2002, Bernardo Reino wrote:

> I have a Compaq Presario 17XL573 laptop, with a 'Conexant LANfinity'
> network card (14f1/1803, rev 08).
> 
> It works correctly using the netdrivers.tgz package from Donald
> Becker (pci-scan.c v1.10 7/13/2002, and tulip.c v0.95b 8/2/2002),
> using the 2.4.19 kernel version (compiled with gcc 2.95.3, like
> the tulip module) but only when I start the computer from a power-off
> state.
...
> (I don't know why the BIOS doesn't enable the NIC, and I can't
> seem to change that, but that doesn't seem to be a/the problem..)

It's not a problem -- the pci-scan code activates the card.  The Linux
kernel didn't activate the card until recent versions.  The message
is there to indicate that pci-scan did a good thing.

> The problem is that when I reboot Linux, or reboot from Windows 2000
> to Linux, the initialization hangs before displaying the MAC address,
> so I get something like this:

That's new.

> eth0: Conexant LANfinity rev 8 at 0xd0877000, [ HERE IT LOCKS ]
>
> I have tried waiting for a reasonable amount of time (5 minutes..),
> but it seems to stop responding to anything. All I can do is turn
> off the computer (btw. I can use the kernel 'magic' sequence for
> that, so the kernel is itself not being locked, but only the
> driver initialization)

Is

> And 'tulip-diag' (v2.11 6/7/2002), with option '-a' shows:

What does 'tulip-diag -ee' report in the situation where the driver
would hang if loaded.  (This likely means disabling the automatic driver
loading.)

> # tulip-diag  -ee
> EEPROM 256 words, 8 address bits.
> Conexant EEPROM format is undocumented.
> EEPROM contents (256 words):
> 0x00:  1815 14f1 0780 0000 0000 1002 0042 0e11
> 0x08:  2814 0000 0000 0000 0000 0000 c1af 0313
...
> I hope somebody can tell me what the problem might be, or how
> to fix it. It appears that the Conexant EEPROM format is not
> documented,

That's not a problem.  Reading the station address from the EEPROM is
the only thing required.  The address location is trivial to
reverse-engineer once you can read the EEPROM.

> I will try to add a few printk()'s here and there, to try to
> locate the problem more precisely..

Almost all driver debugging is done with the 'printk' debugger...

-- 
Donald Becker				[email protected]
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		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