Problems with Tulip on second PCI Bus
Andrew McMillan
Andrew@cat-it.co.nz
Sun Mar 14 22:24:44 1999
Hi,
I can't seem to get my Tulip card working under Linux, and I was
wondering if there is perhaps a bug somewhere in either the driver, or
the code to handle the second PCI bus. The only error message I can
seem to get out of the tulip driver (and only with debug on) is:
eth0: Too much work during an interrupt, csr5=0xfc90a000
Which scrolls off screen very quickly with vast numbers of repeats
(identical message) at which point the only retreat seems to be a hard
reset. I have tried lots of things, including the latest (0.90q)
version of the driver and the latest (2.2.3) kernel.
Any help would be appreciated. If there is any information which I can
provide, I am only to happy to do so. Following is a fairly exhaustive
log of my adventures so far, including full details of the environment I
am operating in.
Regards,
Andrew McMillan
_____________________________________________________________________
Andrew McMillan, e-mail: Andrew@cat-it.co.nz
Catalyst IT Ltd, PO Box 10-225, Level 21, 105 The Terrace, Wellington
Me: +64 (21) 635 694, Fax: +64 (4) 499 5596, Office: +64 (4) 499 2267
_____________________________________________________________________
[1.] One line summary of the problem:
Tulip Network drivers won't work for card on PCI bus 1
[2.] Full description of the problem/report:
I have a DEC21140-based network card (Kingston 10/100) in the
docking station for my laptop. We use these network cards all
around our office, including several other linux boxes. We use
the 'tulip' driver which works everywhere but on my laptop.
On my laptop when I 'modprobe tulip' things work fine, but when I
then 'ifconfig eth0 blah blah blah' the computer locks up
and only comes back with a hard reset (I have waited up
to ten minutes to see if it was a timeout, but the screen cursor
disappeared immediately which gave me a sinking feeling).
After I have done the 'modprobe tulip' I can see from the
logs that the tulip has been detected OK, including that it
has correctly found a 100MBps network.
The de4x5 is an alternative driver for these cards, so I have tried
using that. When I 'modprobe de4x5' the card is noticed and so
forth, although I do get some messages about a timeout. I can
then 'ifconfig eth0 blah blah blah' without locking up the computer
but when I try and ping something, the packets seem to go to the
wrong network, although the routing tables are OK.
I did have an ne2k-pci in the docking station in the past, and
that worked fine, but I wanted to upgrade to a 100MB card.
[3.] Keywords (i.e., modules, networking, kernel):
tulip kingston 10/100 networking de4x5 laptop docking-station pci
[4.] Kernel version (from /proc/version):
Linux version 2.2.2 (root@heidegger) (gcc version 2.7.2.3) #1 Sat Feb 27
09:13:13 NZDT 1999
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
No oops or other messages available :-(
I compiled version 0.90q of the tulip driver (latest testing version as
at
10 March 1999 and when I run it with debug=6 (maximum) it seems that the
system is in an infinite loop inside the tulip driver and giving out
this
message:
eth0: Too much work during an interrupt, csr5=0xfc90a000
At that point only the off switch gives any response in the system (as
with
other versions of the driver, or with debugging not on.
[6.] A small shell script or example program which triggers the
problem (if possible)
#!/bin/bash
modprobe tulip
ifconfig eth0 192.168.2.85 netmask 255.255.255.0 broadcast 192.168.2.255
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Linux heidegger 2.2.2 #1 Sat Feb 27 09:13:13 NZDT 1999 i586 unknown
Kernel modules 2.1.121
Gnu C 2.7.2.3
Binutils 2.9.1.0.19
Linux C Library 2.0.7
Dynamic linker ldd: version 1.9.10
Procps 1.9.0
Mount 2.9i
Net-tools (1999-01-01)
Kbd 0.96
Sh-utils 1.16
pcmcia support 3.09
[7.2.] Processor information (from /proc/cpuinfo):
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 8
model name : Mobile Pentium MMX
stepping : 1
cpu MHz : 233.867831
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : yes
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 mmx
bogomips : 466.94
[7.3.] Module information (from /proc/modules):
<No modules loaded>
[7.4.] SCSI information (from /proc/scsi/scsi)
<No scsi devices>
[7.5.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
[X.] Other notes, patches, fixes, workarounds:
The card I am using is a Kingston 10/100 card. It works fine with
Windows 95 or Windows 98. Other machines in our office are running
linux with the tulip driver and these cards without problems. I have
tried kernels 2.0.34, 2.0.36, 2.1.132, 2.2.0, 2.2.1 and 2.2.2 with
identical results. The chip on the card is labelled by 'digital'
and identified as a '21140'.
The card involved is in the docking station for my laptop. The docking
station has various other hardware in it including a CMD646-based IDE
interface which doesn't work brilliantly under Linux either (I can get
it to work, but I have to make sure that CMD646 support is NOT compiled
into my kernel). The docking station contains a PCI slot, space for IDE
hard drive(s) some sound hardware and two PCMCIA slots. The Kingston
10/100 is installed in the PCI slot and nothing is normally installed
in any of the PCMCIA slots (or the ones in the laptop itself while its
docked).
When Windows 98 is running on the docking station it sees slightly
different memory and I/O locations for the network card.
Following are some logs of doing various things on the machine:
# cat /proc/pci
PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel 82439TX (rev 1).
Medium devsel. Master Capable. Latency=32.
Bus 0, device 1, function 0:
ISA bridge: Intel 82371AB PIIX4 ISA (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable. No
bursts.
Bus 0, device 1, function 1:
IDE interface: Intel 82371AB PIIX4 IDE (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=64.
I/O at 0xfcd0 [0xfcd1].
Bus 0, device 1, function 2:
USB Controller: Intel 82371AB PIIX4 USB (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=64.
I/O at 0xfce0 [0xfce1].
Bus 0, device 1, function 3:
Bridge: Intel 82371AB PIIX4 ACPI (rev 1).
Medium devsel. Fast back-to-back capable.
Bus 0, device 2, function 0:
VGA compatible controller: Cirrus Logic Unknown device (rev 0).
Vendor id=1013. Device id=4c.
Medium devsel. IRQ 11.
Non-prefetchable 32 bit memory at 0xfd000000 [0xfd000000].
Bus 0, device 3, function 0:
CardBus bridge: Texas Instruments PCI1131 (rev 1).
Medium devsel. Master Capable. Latency=168. Min Gnt=192.Max
Lat=4.
Bus 0, device 3, function 1:
CardBus bridge: Texas Instruments PCI1131 (rev 1).
Medium devsel. Master Capable. Latency=168. Min Gnt=192.Max
Lat=4.
Bus 1, device 15, function 0:
CardBus bridge: Texas Instruments PCI1131 (rev 1).
Medium devsel. Master Capable. Latency=168. Min Gnt=192.Max
Lat=7.
Bus 1, device 15, function 1:
CardBus bridge: Texas Instruments PCI1131 (rev 1).
Medium devsel. Master Capable. Latency=168. Min Gnt=64.Max
Lat=7.
Bus 0, device 15, function 0:
PCI bridge: DEC DC21152 (rev 2).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=64. Min Gnt=4.
Bus 1, device 12, function 0:
Ethernet controller: DEC DC21140 (rev 34).
Medium devsel. Fast back-to-back capable. IRQ 11. Master
Capable. Latency=165. Min Gnt=20.Max Lat=40.
I/O at 0xe800 [0xe801].
Non-prefetchable 32 bit memory at 0xfcfff800 [0xfcfff800].
Bus 1, device 14, function 0:
IDE interface: CMD 646 (rev 1).
Medium devsel. Fast back-to-back capable. IRQ 11. Master
Capable. Latency=64. Min Gnt=2.Max Lat=4.
I/O at 0xe4d0 [0xe4d1].
I/O at 0xe4d8 [0xe4d9].
I/O at 0xe4e0 [0xe4e1].
I/O at 0xe4e8 [0xe4e9].
I/O at 0xe400 [0xe401].
# cat /proc/bus/pci/devices
0000 80867100 0 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0008 80867110 0 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0009 80867111 0 00000000 00000000 00000000 00000000 0000fcd1 00000000
00000000
000a 80867112 0 00000000 00000000 00000000 00000000 0000fce1 00000000
00000000
000b 80867113 0 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0010 1013004c b fd000000 00000000 00000000 00000000 00000000 00000000
00000000
0018 104cac15 0 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0019 104cac15 0 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0178 104cac15 0 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0179 104cac15 0 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0078 10110024 0 00000000 00000000 00000000 00000000 00000000 00000000
00000000
0160 10110009 b 0000e801 fcfff800 00000000 00000000 00000000 00000000
00000000
0170 10950646 b 0000e4d1 0000e4d9 0000e4e1 0000e4e9 0000e401 00000000
00000000
Log of what happens when 'modprobe tulip' is done:
Mar 1 14:57:20 heidegger kernel: The PCI BIOS has not enabled this
device! Updating PCI command 0003->0007.
Mar 1 14:57:20 heidegger kernel: tulip.c:v0.89H 5/23/98
becker@cesdis.gsfc.nasa.gov
Mar 1 14:57:20 heidegger kernel: eth0: Digital DS21140 Tulip at 0xe800,
00 c0 f0 40 a8 b9, IRQ 11.
Mar 1 14:57:20 heidegger kernel: eth0: EEPROM default media type
Autosense.
Mar 1 14:57:20 heidegger kernel: eth0: Index #0 - Media MII (#11)
described by a 21140 MII PHY (1) block.
Mar 1 14:57:20 heidegger kernel: eth0: MII transceiver found at MDIO
address 1, config 1000 status 782d.
After this if I 'ifconfig eth0 ...' then the computer locks up.
Changing to version
0.90q (latest version) made no difference to this.
Log of what happens when 'modprobe de4x5' is done:
Mar 3 08:02:20 heidegger kernel: eth0: DC21140 at 0xe800 (PCI bus 1,
device 12), h/w address 00:c0:f0:40:a8:b9,
Mar 3 08:02:20 heidegger kernel: and requires IRQ11 (provided by
PCI BIOS).
Mar 3 08:02:20 heidegger kernel: de4x5.c:V0.543 1998/12/30
davies@maniac.ultranet.com
Log of what happens when I do an 'ifconfig eth0 ...' after the de4x5 is
loaded:
Mar 3 08:05:40 heidegger kernel: eth0: Setup frame timed out, status
fc902000
Mar 3 08:05:40 heidegger kernel: eth0: Setup frame timed out, status
fc902000
Mar 3 08:05:41 heidegger kernel: eth0: media is 100Mb/s.
Script used to set up my network (a pretty standard Debian
installation):
#! /bin/sh
ifconfig lo 127.0.0.1
# route add -net 127.0.0.0
IPADDR=192.168.2.85
NETMASK=255.255.255.0
NETWORK=192.168.2.0
BROADCAST=192.168.2.255
GATEWAY=192.168.2.1
ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}
route add -net ${NETWORK} netmask ${NETMASK} dev eth0
[ "${GATEWAY}" ] && route add default gw ${GATEWAY} metric 1
The output from (route -n; ifconfig eth0; ping -c 100 192.168.2.80;
ifconfig eth0)
which I have split up into the appropriate commands:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
0.0.0.0 192.168.2.1 0.0.0.0 UG 1 0 0
eth0
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:C0:F0:40:A8:B9
inet addr:192.168.2.85 Bcast:192.168.2.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:11 Base address:0xe800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:1614 errors:0 dropped:0 overruns:0 frame:0
TX packets:1614 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
# ping -c 100 -l 100 192.168.2.80
PING 192.168.2.80 (192.168.2.80): 56 data bytes
--- 192.168.2.80 ping statistics ---
101 packets transmitted, 0 packets received, 100% packet loss
# ifconfig
eth0 Link encap:Ethernet HWaddr 00:C0:F0:40:A8:B9
inet addr:192.168.2.85 Bcast:192.168.2.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
Interrupt:11 Base address:0xe800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:1617 errors:0 dropped:0 overruns:0 frame:0
TX packets:1617 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
# tulip-diag -a
# tulip-diag -e
# tulip-diag -m
tulip-diag.c:v1.08 2/28/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Digital DS21140 Tulip adapter at 0xe800.
Digital DS21140 Tulip Tulip chip registers at 0xe800:
fe000000 ffffffff ffffffff eec9effe fddcffef fc000000 32000040
fffe0000
e0000000 fffc83ff ffffffff fffe0000 ffffff00 ffffffff 1c09fdc0
fffffec8
Port selection is 10mpbs-serial, half-duplex.
Transmit stopped, Receive stopped, half-duplex.
The Rx process state is 'Stopped'.
The Tx process state is 'Stopped'.
The transmit threshold is 72.
tulip-diag.c:v1.08 2/28/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Digital DS21140 Tulip adapter at 0xe800.
Port selection is 10mpbs-serial, half-duplex.
Transmit stopped, Receive stopped, half-duplex.
The Rx process state is 'Stopped'.
The Tx process state is 'Stopped'.
The transmit threshold is 72.
EEPROM transceiver/media description for the Digital DS21140 Tulip chip.
Leaf node at offset 30, default media type 0800 (Autosense).
CSR12 direction setting bits 00.
1 transceiver description blocks:
Media MII, block type 1.
MII interface PHY 0 (media type 11).
21140 MII Reset sequence is.
21140 MII initialization sequence is.
Media capabilities are 0000, advertising 7801.
MII interrupt on GPIO pin -1.
MII PHY found at address 1, status 0x7809.
MII PHY #1 transceiver registers:
3000 7809 0016 f831 01e1 0000 ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0022 ff00 08b0 fff0 00a0 ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff.
tulip-diag.c:v1.08 2/28/99 Donald Becker (becker@cesdis.gsfc.nasa.gov)
Index #1: Found a Digital DS21140 Tulip adapter at 0xe800.
Port selection is 10mpbs-serial, half-duplex.
Transmit stopped, Receive stopped, half-duplex.
The Rx process state is 'Stopped'.
The Tx process state is 'Stopped'.
The transmit threshold is 72.
MII PHY found at address 1, status 0x7809.
MII PHY #1 transceiver registers:
3000 7809 0016 f831 01e1 0000 ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff
0022 ff00 40a0 fff0 00a0 ffff ffff ffff
ffff ffff ffff ffff ffff ffff ffff ffff.