From owner-freebsd-alpha Fri Jan 28 11:28:45 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from mass.cdrom.com (castles561.castles.com [208.214.165.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F13915DE2 for ; Fri, 28 Jan 2000 11:28:38 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Received: from mass.cdrom.com (localhost [127.0.0.1]) by mass.cdrom.com (8.9.3/8.9.3) with ESMTP id LAA02548; Fri, 28 Jan 2000 11:37:36 -0800 (PST) (envelope-from msmith@mass.cdrom.com) Message-Id: <200001281937.LAA02548@mass.cdrom.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Jonathan Sturges" Cc: "Bill Paul" , freebsd-alpha@freebsd.org Subject: Re: Fw: FreeBSD Alpha and NICs In-reply-to: Your message of "Thu, 27 Jan 2000 19:04:13 EST." <001f01bf6976$fff27380$0b01a8c0@stickybit.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jan 2000 11:37:36 -0800 From: Mike Smith Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 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). That's not always true. Alphas vary a lot from machine to machine, and some of them are very PC-like. > 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.) The above looks like something else has claimed the interrupt in a non-shareable fashion. > 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. Call it a 'feature' of the PCI implementation on the Multia. That's more or less "just the way it works". > 2) If IRQ sharing is within PCI spec, why do es the kernel not cope well > with it? As above; it looks like something else has insisted that it's not happy with sharing the interrupt. > 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 doubt it; I think the PCI IRQ routing in the Multia is fixed. You might check what the NetBSD folks do about this. > I will send this to freebsd-alpha as well (hmm, does the list take posts > from non-subscribers?).... Obviously. 8) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message