Date: Wed, 11 Jun 1997 23:05:20 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Terry Lambert <terry@lambert.org> Cc: stesin@gu.net, bob@luke.pmr.com, matt@3am-software.com, hackers@FreeBSD.ORG, smp@FreeBSD.ORG Subject: Re: Does SMC9332BDT work in 2.2.2R?? Message-ID: <19970611230520.22463@mi.uni-koeln.de> In-Reply-To: <199706101816.LAA02784@phaeton.artisoft.com>; from Terry Lambert on Tue, Jun 10, 1997 at 11:16:14AM -0700 References: <19970610101445.26928@mi.uni-koeln.de> <199706101816.LAA02784@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jun 10, Terry Lambert <terry@lambert.org> wrote: > > Why should that cause ANY problems > > for a bus-master card in slot 5 ??? > > > > | It has to do with PCI interrupt sharing. > ********************* > > This was broken in SMP, and seems to have been broken in general > on integration of SMP into the main line source tree. Really ? Don't think so ... There are in fact SMP systems that work with shared PCI interrupts ... > In addition, the card itself might object to interrupt sharing. No. All PCI cards must support shared interrupts, and I have yet to find one that doesn't. (There were a few cards before PCI 2.0, that tried to fully emulate some ISA card and could be made to use edge-triggered interrupts, but even those use level interrupts by default ...) > Finally, does the video card claim a vertical retrace interrupt? > If not, does it do one anyway? If so, the way the poll does not > happen to detect the card responsible on a shared interrupt with > a single attach can also be a problem. All PCI drivers are required to have a test on *this* card being the source of the interrupt as the first action in the interrupt handler. A PCI driver that fails to do so is broken! If the driver does the right thing, then it doesn't matter whether there are retrace interrupts (well, they definitely would reduce system performance, but by less than 20%), and you should be able to see the interrupts in the "systat -vm" screen ... > I realize that the explanations other than the first one rely > on bogus PCI card hardware. Broken PCI card hardware or a driver problem ... But the card in question uses a known good Ethernet chip. If you exclude the possibility that this particular device is defective, then it must be something else ... Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970611230520.22463>