Date: Fri, 9 Apr 1999 14:34:27 -0500 From: "Gooderum, Mark" <mark@jumpweb.com> To: "'freebsd-alpha@freebsd.org'" <freebsd-alpha@freebsd.org> Subject: FreeBSD Alpha and NICs Message-ID: <50C732FEDE87D211954300A024786203A69F@archeron.good.com>
next in thread | raw e-mail | index | archive | help
I've been working on a few things now that I've gotten things up...mostly
NIC related.
Earlier I made an attempt to get the rl0 (RealTek) driver working and ran
into some problems. More recently I grabbed the updated Ethernet drivers and
tried with a Netgear 310FX and the pn0 driver. The changes I made to if_rl.c
were similar to what was done to if_pn.c (substitute some of the x86
constants with Alpha ones, adjust a couple of virtual to physical
expressions).
What's odd is that both drivers (with the appropriate card) crash exactly
the name way.
In xx_attach() the code makes it through the function and prints the initial
line for the card (w/irq, etc). Both pn_attach() and rl_attach()
successfully get through mapping the I/O (and/or memory, I've built both
drivers both ways) can get to the call to pci_map_int(). pci_map_int()
calls pci_map_int_right() which calls intr_connect(). intr_connect() gets
as far calling intr_create(). intr_create() crashes because
BUS_ALLOC_RESOURCE returns NULL and intr_create() calls BUS_SETUP_INTR where
the deferference of the NULL pointer for "res" causes the crash, the
offending code from pcibus.c looks like:
res = BUS_ALLOC_RESOURCE(pcib, NULL, SYS_RES_IRQ, &zero,
irq, irq, 1, RF_SHAREABLE | RF_ACTIVE);
/** NOTE: res is NULL at this point if duplicate irq probed so BOOM **/
if (BUS_SETUP_INTR(pcib, pcib, res, (driver_intr_t *)handler,fg
arg, &cookie))
return 0;
From the printf() debugging the call sequence appears (with the pn0 driver,
the rl0 driver looks the same other than some code motion). This is the
actual dmesg output with my debugging statements:
pn0: <82c168/82c169 PNIC 10/100BaseTX> rev 0x21 int a irq 15 on pci0.12.0
pn0: pn_attach(0xfffffe0000231c90, 0)
pn0: Doing power mgmt...
pn0: Mapping control/status regs...
pn0: Mapping IO/Memory...
pn0: Calling pci_map_int(ci=0xfffffe0000231c90, pi=0xfffffc0000467da8,
sc=0xfffffe0000236000, ni=0xfffffc00005915ec/0)
pci_map_int: Calling pci_map_int_right(cfg=0xfffffe0000231c90,
ha=0xfffffc0000467da8, a=0xfffffe0000236000, maskptr=0xfffffc00005915ec/0,
fl=0)
pci_map_int_right: Calling intr_create(di=0xffffffffffffffff, irq=15,
hand=0xfffffc0000467da8, arg=0xfffffe0000236000, mp=0xfffffc00005915ec/0,
fl=0)
intr_create(di=0xffffffffffffffff, irq=15, ihand=0xfffffc0000467da8,
arg=0xfffffe0000236000, imaskp=0xfffffc00005915ec/0, fl=0)
intr_create: BUS_ALLOC_RESOURCE=0
fatal kernel trap:
trap entry = 0x2 (memory management fault)
a0 = 0x50
a1 = 0x1
a2 = 0x0
pc = 0xfffffc0000388d1c
ra = 0xfffffc00004cd1d4
curproc = 0
ddbprinttrap(0x50, 0x1, 0x0, 0x2)
panic: trap
panic
For comparison the sucessfull sequence for de0 looks like:
de0: <Digital 21040 Ethernet> rev 0x23 int a irq 15 on pci0.8.0
pci_map_int: Calling pci_map_int_right(cfg=0xfffffe0000231f90,
ha=0xfffffc000045f548, a=0xfffffe0000233800, maskptr=0xfffffc00005915ec/0,
fl=0)
pci_map_int_right: Calling intr_create(di=0xffffffffffffffff, irq=15,
hand=0xfffffc000045f548, arg=0xfffffe0000233800, mp=0xfffffc00005915ec/0,
fl=0)
intr_create(di=0xffffffffffffffff, irq=15, ihand=0xfffffc000045f548,
arg=0xfffffe0000233800, imaskp=0xfffffc00005915ec/0, fl=0)
intr_create: BUS_ALLOC_RESOURCE=0xfffffe0000231f00
intr_create: returning 0xfffffe0000229940
pci_map_int_right: Calling intr_connect(id=0xfffffe0000229940)
de0: DEC 21040 [10Mb/s] pass 2.3
de0: address 08:00:2b:e2:c7:eb
It's worth noting that both the RealTek and the Netgear card probe at IRQ 15
(same as de0). I've tried to get the de to probe 2nd to see if there is
some kind of order dependency to the crash, but order in the config file
doesn't seem to make a difference. I'm assuming the PCI probs end up
happening in card number order (making de0 on the motherboard always come
first).
So...any ideas on how to:
* Share IRQ's
* Get the Multia to change the autoconf of the card to a seperate IRQ
* Force the software (kernel) to remap the card to an alternate IRQ
For now,
--
Mark
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50C732FEDE87D211954300A024786203A69F>