[tulip] Tulip driver hangs detecting MAC
Bernardo Reino
reinob@gmx.net
Wed Nov 6 08:11:01 2002
Hi everyone,
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.
Here is the relevant 'dmesg' dump:
--<<--
pci-scan.c:v1.10 7/13/2002 Donald Becker <becker@scyld.com>
http://www.scyld.com/linux/drivers.html
tulip.c:v0.95b 8/2/2002 Written by Donald Becker <becker@scyld.com>
http://www.scyld.com/network/tulip.html
The PCI BIOS has not enabled the device at 0/72! Updating PCI command
0003->0007.
eth0: Conexant LANfinity rev 8 at 0xd0877000, 00:50:8B:FA:D1:93, IRQ 9.
eth0: MII transceiver #1 config 1000 status 782d advertising 01e1.
eth0: MII transceiver #0 config 1000 status 782d advertising 01e1.
--<<--
(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..)
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:
--<<--
pci-scan.c:v1.10 7/13/2002 Donald Becker <becker@scyld.com>
http://www.scyld.com/linux/drivers.html
tulip.c:v0.95b 8/2/2002 Written by Donald Becker <becker@scyld.com>
http://www.scyld.com/network/tulip.html
The PCI BIOS has not enabled the device at 0/72! Updating PCI command
0003->0007.
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)
AFAIK the last thing printed by the driver occurs inside the
'tulip_probe1' function:
--<<--
printk(KERN_INFO "%s: %s rev %d at %#3lx,",
dev->name, pci_id_tbl[pci_tbl_idx].name, chip_rev, ioaddr);
--<<--
If it helps, the 'mii-diag' tool shows this:
--<<--
# mii-diag eth0
Basic registers of MII PHY #1: 1000 782d 0022 1720 01e1 45e1 0007 2001.
The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
Basic mode control register 0x1000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx
10baseT-FD 10baseT, w/ 802.3X flow control.
End of basic transceiver information.
--<<--
And 'tulip-diag' (v2.11 6/7/2002), with option '-a' shows:
--<<--
# tulip-diag -f -aa
tulip-diag.c:v2.11 6/17/2002 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a Conexant LANfinity adapter at 0x1400.
Conexant LANfinity chip registers at 0x1400:
0x00: fff88000 ffffffff ffffffff 0fecc800 0fecca00 f4660000 e0042202 7bffebef
0x40: fffe0000 fff080e8 fffe0000 fffe0000 ffffffff ffffffff ffffffff f7f9fec8
Extended registers:
0x80: cc660000 cbffebef f0000019 00000000 ffffffff 0feccab0 0fecc8b0 00000000
0xa0: ffffffff 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0xc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
0xe0: 00000000 00000000 00000000 00000000 ffffffff 00000000 00000000 00000000
Port selection is MII, full-duplex.
Transmit started, Receive started, full-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 128.
--<<--
Using '-ee' to display the EEPROM displays the following:
--<<--
# tulip-diag -ee
tulip-diag.c:v2.11 6/17/2002 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a Conexant LANfinity adapter at 0x1400.
Port selection is MII, full-duplex.
Transmit started, Receive started, full-duplex.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 128.
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
0x10: 4349 2053 1304 0000 1500 0329 5200 636f
0x18: 776b 6c65 006c 7445 6568 6e72 7465 4d2f
0x20: 646f 6d65 4120 6164 7470 7265 7600 2e31
0x28: 3030 ff00 0607 0001 0000 0001 0f04 0103
0x30: 0000 0000 0000 0000 0100 0101 1c01 0203
0x38: ffd8 0221 0002 0422 0200 5c0f 0922 1f05
0x40: 000f 0003 0300 2200 0609 0f1f 04cc cc00
0x48: 0004 0922 1f07 cc0f 0004 04cc 2200 020d
0x50: 0006 393f 0303 070f 0100 ffb5 0922 0613
0x58: 1f00 7a00 b500 22ff 2309 0006 001f 0032
0x60: ffb5 1222 0684 0b00 0702 0014 0010 0008
0x68: 0004 0002 0000 ffff ffff ffff ffff ffff
0x70: ffff ffff ffff ffff ffff ffff ffff ffff
0x78: ffff ffff ffff ffff ffff ffff ffff ffff
0x80: 1803 14f1 0200 0000 0000 1002 0023 0e11
0x88: 2814 0000 0000 0000 0000 0000 c000 00a2
0x90: 0313 4349 2053 1304 0000 1500 0329 5200
0x98: 636f 776b 6c65 006c 7445 6568 6e72 7465
0xa0: 4d2f 646f 6d65 4120 6164 7470 7265 7600
0xa8: 2e31 3030 ff00 0607 0011 0100 0000 0607
0xb0: 0002 1000 0000 0f04 0103 0000 0000 0000
0xb8: 0000 0100 0101 1c01 0203 ffd8 0221 0005
0xc0: 0222 0201 0522 8002 9896 2200 0205 e100
0xc8: 05f5 0222 0103 0822 0604 5000 fa8b 93d1
0xd0: 0222 0005 ffff ffff ffff ffff ffff ffff
0xd8: ffff ffff ffff ffff ffff ffff ffff ffff
0xe0: ffff ffff ffff ffff ffff ffff ffff ffff
0xe8: ffff ffff ffff ffff ffff ffff ffff ffff
0xf0: ffff ffff ffff ffff ffff ffff ffff ffff
0xf8: ffff ffff ffff ffff ffff ffff ffff ef2a
ID block CRC 0x91 (vs. 0x14).
Full contents CRC 0xa581 (read as 0x1f05).
--<<--
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, but the driver manages to read the MAC and whatever
is necessary, but only after a power off.
I will try to add a few printk()'s here and there, to try to
locate the problem more precisely..
Regards,
Bernardo Reino.