Date: Sat, 10 Feb 1996 03:43:57 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: Terry Lambert <terry@lambert.org> Cc: hackers@freebsd.org Subject: Re: scanpci.c and pci-related stuff Message-ID: <199602100243.AA22467@Sysiphos> In-Reply-To: Terry Lambert <terry@lambert.org> "Re: scanpci.c and pci-related stuff" (Feb 9, 13:03)
next in thread | previous in thread | raw e-mail | index | archive | help
On Feb 9, 13:03, Terry Lambert wrote: } Subject: Re: scanpci.c and pci-related stuff } > 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. Hmm, I'm not sure what you mean with the BusLogic SCSI problem. But in fact the "bt" driver suffered from the same problem as the "lnc". It was an ISA driver, that happened to work fine with the PCI card, since that offered a full emulation of the ISA predecessor ... There is now a /sys/pci/bt9xx.c in -current and -stable, and a similar wrapper ahs to be written for the Lance ... } 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. Shared PCI interrupts are supported for quite some time. } 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. True. All devices that share an IRQ are polled to find the one that caused the interrupt. A PCI interrupt handler should first check whether there is anything to do with as little cycles as possible, for this reason. The code applies the correct interrupt mask before calling each handler. } 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. I guess that shared interrupts will cost much less than 1% performance even on a heavily loaded server machine with thousands of interrupts a second. Nothing to really worry about ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602100243.AA22467>