Date: Wed, 11 Jun 1997 14:57:47 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: se@freebsd.org (Stefan Esser) Cc: terry@lambert.org, 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: <199706112157.OAA07206@phaeton.artisoft.com> In-Reply-To: <19970611230520.22463@mi.uni-koeln.de> from "Stefan Esser" at Jun 11, 97 11:05:20 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 ... This may just be a broken PCI BIOS, then. > > 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! Isn't this a PCI framework issue, where it should explicitly call a card routine or check a bit in a flag in the card data struct to see if it originated the interrupt? It seems to me that if the PCI driver wasn't written correctly, you'd want it to fail absolutely (so it got caught in the author's testing) instead of under conditions which might not be universal (ie: the authors machine might not exhibit the problem). This seems to be an interface design issue. ...On the other hand, if there is a standard PCI (not card-specific) way of polling to see who interrupted, then it shouldn't involve the driver at all (I don't think there is, given that we don't use the PCI BIOS, right? Seems to me that we need a "did_you_interrupt" entry point for the card instance for the driver to allow procedural polling, instead of calling the driver and expecting it to obey hidden interface assumptions). > 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 ... It should be architecturally impossible for the driver to not do the right thing (ie: they don't fill out the "did_you_interrupt" function pointer in the device instance struct, and they get an error message on boot). This should be explicit in the DDI architecture for PCI devices, not implicit, IMO. > > 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 ... Yes, I had totally discounted that idea. I thought he had said the card worked in a three PCI slot machine? I guess that still leaves PCI BIOS autodetection/card-mapping bugs. 8-(. Regards, 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?199706112157.OAA07206>