Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Jan 2000 11:37:36 -0800
From:      Mike Smith <msmith@freebsd.org>
To:        "Jonathan Sturges" <jonathan@sprintmail.com>
Cc:        "Bill Paul" <wpaul@skynet.ctr.columbia.edu>, freebsd-alpha@freebsd.org
Subject:   Re: Fw: FreeBSD Alpha and NICs 
Message-ID:  <200001281937.LAA02548@mass.cdrom.com>
In-Reply-To: Your message of "Thu, 27 Jan 2000 19:04:13 EST." <001f01bf6976$fff27380$0b01a8c0@stickybit.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001281937.LAA02548>