Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Feb 2004 19:13:52 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Ion-Mihai Tetcu <itetcu@apropo.ro>
Cc:        freebsd-current@freebsd.org
Subject:   Re: Stray irq7.
Message-ID:  <20040225184209.R10284@gamplex.bde.org>
In-Reply-To: <20040225085917.3b813e5d@it.buh.cameradicommercio.ro>
References:  <20040222185325.GA97979@cserv62.csub.edu> <53996.192.168.0.97.1077661722.squirrel@webmail.thilelli.net> <20040225085917.3b813e5d@it.buh.cameradicommercio.ro>

next in thread | previous in thread | raw e-mail | index | archive | help
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).

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040225184209.R10284>