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/