[tulip] many tulip problems with a cogent 4port nic
Donald Becker
becker@scyld.com
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*21040
4*21140
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
issue.
> 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
> right.
> 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
> sort.
Uhmmm, what makes you believe that the de4x5 driver has the interrupt
assignment "right"?
Please try my driver with 2.2 and 2.4, and send a report.
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