From owner-freebsd-alpha Fri Apr 9 18:27:35 1999 Delivered-To: freebsd-alpha@freebsd.org Received: from archeron.good.com (mgooderum1.dsl.uswest.net [209.180.19.145]) by hub.freebsd.org (Postfix) with ESMTP id D67881518D for ; Fri, 9 Apr 1999 18:27:25 -0700 (PDT) (envelope-from mark@jumpweb.com) Received: by archeron.good.com with Internet Mail Service (5.5.2448.0) id <2SW368CC>; Fri, 9 Apr 1999 14:35:40 -0500 Message-ID: <50C732FEDE87D211954300A024786203A69F@archeron.good.com> From: "Gooderum, Mark" To: "'freebsd-alpha@freebsd.org'" Subject: FreeBSD Alpha and NICs Date: Fri, 9 Apr 1999 14:34:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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: 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