Date: Thu, 27 Jan 2000 19:04:13 -0500 From: "Jonathan Sturges" <jonathan@sprintmail.com> To: "Bill Paul" <wpaul@skynet.ctr.columbia.edu> Cc: <freebsd-alpha@freebsd.org> Subject: Re: Fw: FreeBSD Alpha and NICs Message-ID: <001f01bf6976$fff27380$0b01a8c0@stickybit.org> References: <200001272306.SAA26620@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Bill Paul" <wpaul@skynet.ctr.columbia.edu> To: "Jonathan Sturges" <jonathan@sprintmail.com> Sent: Thursday, January 27, 2000 6:06 PM Subject: Re: Fw: FreeBSD Alpha and NICs > I'm a bit confused. I recently loaded a FreeBSD 4.0 snapshot into > my AlphaStation 200 and stuck my RealTek 8139 card in it, and it worked > fine. *But* my alpha assigns a unique IRQ to the card. From some > discussions I've had with others, the alpha is not supposed to share > interrupts like that in the first place (you're supposed to have more > than enough IRQs to go around, unlike the PC architecture). > > I don't see any way to control how PCI IRQs are assigned on my > AlphaStation, so I'm not entirely sure what to tell you. The driver > itself doesn't appear to be the problem (given that it works for > me). The snapshot that I loaded is from alpha.viper.usi.net. I would > suggest downloading the install floppies from there and trying to boot > the install kernel with the RealTek card installed. If it blows up, I > would ask about this on the freebsd-alpha mailing list. (Make sure to say > exactly what kind of Alpha you have.) OK... here's how it went. I tried the 3.4 "kern" floppy, and it panics just like the 3.3 I'm already running. BUT... the 01/26 snapshot of 4.0 is better... it doesn't panic!! But when the kernel initializes the NIC (oops, sorry, this is with the Netgear NIC I bought, not the 8139): dc0: <82c169 PNIC 10/100BaseTX> port 0x10000-0x100ff mem 0x81000000-0x810000ff i rq 15 at device 12.0 on pci0 dc0: couldn't map interrupt device_probe_and_attach: dc0 attach returned 6 so although it's definitely not your driver at fault, there's still something fishy about this IRQ business. (The Multia seems to assign *any* card in its one-and-only PCI slot to IRQ 15.) 1) Why is the Multia assigning the 8139 or Netgear to IRQ 15, which is already in use by the built-in de0 interface? I realize this is within PCI spec., but it seems unnecessary. 2) If IRQ sharing is within PCI spec, why does the kernel not cope well with it? 3) What, if anything, can Multia users do? I was hoping there was some magic we could do with the SRM console to affect PCI IRQ selection. I will send this to freebsd-alpha as well (hmm, does the list take posts from non-subscribers?).... thanks, Jonathan jonathan@sprintmail.com 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?001f01bf6976$fff27380$0b01a8c0>