Re: 2.3.18ac9 and tulip.c (?)

Richard Dynes (rdynes@varcom.com)
Tue, 28 Sep 1999 09:40:05 -0400


"Petr Vandrovec Ing. VTEI" wrote:
>
> Hi Richard,
> (1) boot your system and do 'cat /proc/iomem'.
> You should see, except other,
> e0000000-e000007f : DEC DC21142
> or something like that. Subtract both numbers and add one - for me
> it was 0x80.
d0041000-d00413ff : eth0
d0043400-d00437ff : eth1 0x400
d0045000-d00453ff : eth2 0x400
d0047400-d00477ff : eth3 0x400
d0049800-d0049bff : eth4 0x400
d004bc00-d004bfff : eth5 0x400
^ these match the first five below

f0000000-f00003ff : DEC DC21142 0x400 < eth0: interrupts not received
f0000400-f00007ff : DEC DC21142 (#2) 0x400 < eth1: works ok
f4100000-f41003ff : DEC DC21142 (#3) 0x400 < eth2: same as eth0
f4100400-f41007ff : DEC DC21142 (#4) 0x400 < not tested
f4100800-f4100bff : DEC DC21142 (#5) 0x400 < not tested
f4100c00-f4100fff : DEC DC21142 (#6) 0x400 < not tested

f4200000-f420007f : DEC DC21142 (#7) 0x80 < not recognized by tulip,
so no
f4200400-f420047f : DEC DC21142 (#8) 0x80 < eth 6 or 7 device created

> (2) Then do 'lspci', find which slot is used by your tulip
> (00:0b.0 for example) and do 'lspci -n -s 00:0b.0'. You'll get
> something like
> 00:0b.0 Class 0200: 1011:0019 (rev 30).

00:05.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43
00:06.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43
03:04.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43
03:05.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43
03:06.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43
03:07.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43
04:04.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43
04:07.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43

[root@probe2 linux-2.3.18ac8]# lspci -n -s 00:05.0

00:05.0 Class 0200: 1011:0019 (rev 41)

[root@probe2 linux-2.3.18ac8]# lspci -n -s 04:04.0
04:04.0 Class 0200: 1011:0019 (rev 30)

> (3) Write 1011:0019 down to paper together with 0x80 from above,
> open linux/drivers/net/tulip.c and searc for
> 00191011 (first device, then vendor).

{ "Digital DS21143 Tulip", { 0x00191011, 0xffffffff },
TULIP_IOTYPE, TULIP_SIZE, DC21142 },

> (4) On line below you'll find exact number and/or TULIP_SIZE* constant
> in second column. Replace this number with 0x80 you'll determined in
> step (1), recompile tulip and try insmod... It should work.

from tulip.c:

#ifdef USE_IO_OPS
#define TULIP_IOTYPE PCI_USES_MASTER | PCI_USES_IO | PCI_ADDR0
#define TULIP_SIZE 0x80
#else
#define TULIP_IOTYPE PCI_USES_MASTER | PCI_USES_MEM | PCI_ADDR1
#define TULIP_SIZE 0x400
#endif

USE_IO_OPS is not defined in tulip.c, so it would seem that the size
is correct except for the ports (#7 #8) which tulip does not create
devices for. Their size is set at the USE_IO_OPS value for whatever
reason. That's a clue into the rest of the problems with those
ports... a different topic altogether.

So I don't think I need the patch.

> (5) If does not, report output of
> lspci -v -s 00:0b.0 (where 00:0b.0 is your DEC slot) to me or
> to linux-kernel, go to top of tulip.c and add
> #define USE_IO_OPS
> somewhere before first #ifndef USE_IO_OPS. It turns tulip.c back
> to I/O instead of MMIO mode and everything should start work again for
> you. But MMIO is faster...

Previously to this, I had been looking at the io_apic code, since my
apparent problem is that the interrupt is either not enabled (although
eth0 appears in /proc/interrupts when it is configured), or not
serviced.

I instrumented tulip.c to printk if a non-eth1 irq (5 on my system) is
received in tulip, and the printk never occurs. eth1 is the only port
I've gotten to work with 2.3.18ac8. With ac9, I can't even insmod the
driver.

So AFAIK, eth0 never gets a service routine called for it. I _know_
eth0 has traffic entering it, and can watch the drop count (via
ifconfig eth0) incrementing correctly.

In io_apic I noticed a bunch of SMP related comments, so I rebuilt ac8
without SMP (My system is UP, although I've never had SMP/UP be an
issue). Maybe this is a big RTFM. If so, how did it work at all???
:(

With 2.3.18ac8 in UP, eth0 and eth1 work. Eth6 and eth7 still aren't
created, however. Eth2-5 don't work, either. I'll try the USE_IO_OPS
to see if that returns things back to normal.

-Richard

-- 
    Richard Dynes
    rdynes@varcom.com

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/