On Wed, 25 Feb 2004, Ion-Mihai Tetcu wrote: > Speaking of stray, where does the following come from and what does it mean ? > (-CURRENT from after kse, APIC, ...) > > # vmstat -i | grep 13 > irq13: npx0 1 0 > stray irq13 1 0 The first is a normal consequence of the npx probe for the non-SMP case, at least if irq13 is handled by the PIC or the APIC is very compatible with the PIC (quite likely). I forget the exact mechanism. Either there is an interrupt pending when irq13 is enabled (due to ISA tri-state line driver behaviour), or the probe causes an interrupts. I think it is the former, since I vaguely remember that this interrupt used to be reported as a stray one due to the race initializing the interrupt name and counter (the race was always lost if the interrupt was pending when irqN is enabled). The exact mechanism can be determined by stepping through the probe and watching where the interrupt becomes pending. I can't completely explain the stray irq13. I don't get it here (at least on a system without an APIC). Perhaps the old race is not completely fixed, but more likely it is from a race detaching the interrupt handler. npx doesn't normally use irq13, so it tears down its interrupt attachment. If there is an npx interrupt pending at teardown time (it would have to be masked at some level, else it wouldn't remain pending), or if such an interrupt becomes pending during teardown time when it should be masked, or if it becomes pending later, then it will be acked later and counted as a stray irq13 (since irq13 is reserved for npx in practice). However, npx shouldn't generate such an interrupt except on old i386's and i486's that have a separate npx (FPU). BruceReceived on Tue Feb 24 2004 - 23:14:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:44 UTC