Date: Fri, 9 Feb 1996 13:03:39 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Cc: terry@lambert.org, se@zpr.uni-koeln.de, hackers@FreeBSD.org Subject: Re: scanpci.c and pci-related stuff Message-ID: <199602092003.NAA10981@phaeton.artisoft.com> In-Reply-To: <199602091746.SAA02888@labinfo.iet.unipi.it> from "Luigi Rizzo" at Feb 9, 96 06:46:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Make sure the ISA portion of your motherboard is PlugNPlay capable > > and that *all* your ISA cards are PlugNPlay cards, and you won't > > have this problem. > > i.e. "avoid the problem and you won't have the problem". I'll keep in > mind next time... :) Yeah. That's basically it. 8-). > > The PCI motherboards from the Intel OEM products division assign the > > same interrupt to all PCI slots. It is up to the interrupt handling > > isn't it "the same interrupt to all boards with the same PCI id ?" > otherwise why the meteor and the ethernet get different IRQs ? I'm not sure. The BusLogic SCSI problem seemed to be generic, but I could be wrong here. > > in your OS software to realize that this is allowable (but never > > desirable, Intel, if you are listening) under the spec to require the > > OS to demux PCI interrupts. > > > > In general, there are Intel motherboards that "Do The Right Thing", but > > Intel typically does not sell them (as Rod Grimes about this one). I > > recommend against Intel OEM Products Division boards. > > so what are your recommendations ? For comparable prices, of course. I recommend ASUS motherboards. I don't know if the prices are comparable or not, since I never priced the non-working motherboards. For what it's worth, I think "doesn't work" is the highest price you can pay, no matter what the actual cost. The jury (Stephan) is still out on whether or not the -current code handles PCI interrupt demuxxing trasnparently or not. It's a general problem, so it *should* be succeptible to a general soloution. If so, then the only thing you are paying for on shared interrupts in reduced concurrency. Assuming the code is there, then worst case is poorer performance than unshared interrupts because of average traversal time for the demux being higher than if you didn't have to do a demux. That is, there is a software work-around that may or may not be there yet, and even if it's there, you should avoid the motherboards because they will have lower performance than motherboards that don't rely on the software work-around. And I'm *really* going to let this go now and let Stephan respond to the interrupt mux issue... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602092003.NAA10981>