Garrett D'Amore wrote: > I'm getting ready to write the kstat intr support for a revised audio > driver, and I noticed that it only reports hard, not spurious > interrupts. That got me thinking. > > On an x86 system at least, the interrupt chain logic keeps retrying the > interrupt until all devices report DDI_INTR_UNCLAIMED. So, a typical > device on an unshared bus will have at least 1 spurious interrupt for > each hard interrupt. (Ignoring the case where successive calls into the > drivers ISR return DDI_INTR_CLAIMED, of course.)
Well...there's "I got an interrupt indication, but I can't tell what device it's for" and there's "I'm looping to look for any other claimers because of ancient sharing rules", and I don't think they really both fall into the class of what I'd call "spurious", but...I'm not sure what you mean by spurious, or the need/desire to count them. > On a system with shared interrupts (more and more common, *especially* > on x86 systems) the spurious interrupt count is likely to be much higher > for some devices, because a busy device will cause spurious interrupts > (or the appearance thereof) in the less busy device(s) on the same > interrupt. > > The upshot of all this is, it seems to me that drivers cannot reliably > count spurious interrupts. > > The other observation is that very few drivers bother to use > kstat_intr. (Some drivers, such as NIC drivers, report interrupts > differently, such as in a named kstat.) > > There's the intrstat program which uses dtrace, but from what I can > tell, it seems to record entries into the interrupt handler, which > doesn't correctly count hard interrupts (see above for why not!) By "hard interrupts" you mean "an actual hardware indication of interrupt"? Note that, for level-triggered interrupts, you can't ever really count those accurately anyway, but...yeah, it counts ISR activations. While I'm not saying this is right or wrong, what do you see as a problem with this? > So what I'm thinking is that the interrupt framework itself could count > interrupts and keep track of this in a kstat. This is useful for debug, > but it would also be able to provide a more accurate picture than > intrstat does. (Furthermore, as much as I like dtrace, it might make it > possible to build a portable intrstat, that was able to report not just > PCI interrupts but other kinds of interrupts -- hard, soft, pci, pciex, > isa, usb, firewire, sbus, and maybe other kinds in the future (for > example SDcard can support IO devices that interrupt, although the > framework and nexus drivers I just putback into 97 don't have support > for SDIO yet.) > > The framework could also count spurious interrupts -- a spurious > interrupt being one where the top-level CPU or nexus specific interrupt > handler dispatched, but didn't find *any* handler that could service the > interrupt. (This could be counted as spurious interrupt for *each* > device on the bus, or it could be counted in a separate top-level > spurious interrupt counter for the bus.) > > Thoughts? I've mused from time to time about trying to clean that code up just from the "wasteful to call everyone again and again" aspect, but it would change semantics; probably in a way we can handle, but I'd have to think harder about it. I've never thought about deficiencies in the stats, though, and I'm not sure one way is better or worse than the other. What would you gain by knowing about 'spurious', where 'spurious' really relates to two different possible conditions? It's a negatively-charged term, but one of the two types is just "the way Solaris does it". What would be better about counting only 'hard interrupts'? _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
