[tulip] many tulip problems with a cogent 4port nic
Tue, 17 Jul 2001 08:14:09 -0400 (EDT)
On Sat, 14 Jul 2001 Dave@keston.u-net.com wrote:
> i seem to be in the unfortunate position of owning a motherboard
> with an AMI bios, and a 4 port NIC. The NIC is a cogent 4port thingy,
> with four DEC 21040 chips and the 21050 ( i think) pci-pci bridge. (i
> am sorry i cannot be more specific but i cant gain access to the card,
> and am working from memory on what it is)
There are several Cogent (now Adaptec) 4 port cards.
4*21143 w/ SYM
4*21143 w/ MII
> Firstly, i am running linux kernel 2.4.5, and using the tulip driver
> built with the kernel sources.
> It would seem that i have a problem with the probing of the card, ie,
> the card has one (S?)ROM and the probing is being done in the wrong
> order (apparently a bios problem, yes ?)
I haven't checked the 2.4 scan code -- the scan order could be a Linux
> here is the output from dmesg with respect to the tulip driver:
> Linux Tulip driver version 0.9.15-pre2 (May 16, 2001)
> eth0: Digital DC21040 Tulip rev 36 at 0xfc80, EEPROM not present, 00:4C:69:6E:75:79, IRQ 11.
> eth3: Digital DC21040 Tulip rev 36 at 0xf800, 00:00:92:92:39:58, IRQ 3.
> the first three eth ports have incorrect MAC addresses, bassed on
> \0LINUX (this is why i am guessing the probing is in the wrong order),
> and am i also correct in thinking the IRQ's are wrong ?
A common x86 BIOS bug is failing to correctly assign the IRQs to the
devices on the other side of a PCI bus bridge. Few cards use bus
bridges, so this problem was around for years.
I worked around the IRQ problem in my drivers by copying the IRQ setting
from the first device.
> here is an output from # ./lspci -vv
> 00:0d.0 Class 0604: 1011:0001 (rev 02)
> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> I/O behind bridge: 0000f000-0000ffff
> Memory behind bridge: ff900000-ff9fffff
> 01:04.0 Class 0200: 1011:0002 (rev 24)
> Interrupt: pin A routed to IRQ 3
> Region 0: I/O ports at f800 [size=128]
> Region 1: Memory at ff9ff000 (32-bit, non-prefetchable) [size=128]
> 01:05.0 Class 0200: 1011:0002 (rev 24)
> Interrupt: pin A routed to IRQ 9
> Region 0: I/O ports at f880 [size=128]
> Region 1: Memory at ff9ff400 (32-bit, non-prefetchable) [size=128]
> 01:06.0 Class 0200: 1011:0002 (rev 24)
> Interrupt: pin A routed to IRQ 10
> Region 0: I/O ports at fc00 [size=128]
> Region 1: Memory at ff9ff800 (32-bit, non-prefetchable) [size=128]
> 01:07.0 Class 0200: 1011:0002 (rev 24)
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at fc80 [size=128]
> Region 1: Memory at ff9ffc00 (32-bit, non-prefetchable) [size=128]
> i was under the impression that the drivers now didnt have a problem
> with reverse probing, the options in your latest sources apear to be
> depreciated, and dont exist anywhere else.
My driver has explicit code to back-copy the media information to
previously discovered chips.
> however, i am under the impression that your drivers are incompatable
> with the 2.4.x kernels (i cant get them to compile, and you say
> something about it on your site)
The versions in the 'test' directly mostly work with 2.4, however I do
not test with the 2.4 kernel.
> i have tried the de4x5 driver (in the kernel tree) and it doesnt seem
> to want to play ball either, however, it does seemingly get the IRQ's
> the final thing, which may be related is the fact with either driver,
> tulip or de4x5 in the kernel tree, i can bring up any of the four
> interfaces, onely one of which works, however, if i try to bring up
> two interfaces the whole system locksup with out any messages of any
Uhmmm, what makes you believe that the de4x5 driver has the interrupt
Please try my driver with 2.2 and 2.4, and send a report.
Donald Becker email@example.com
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
Annapolis MD 21403 410-990-9993