From owner-freebsd-current@FreeBSD.ORG Wed Feb 25 00:14:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACEEE16A4CE for ; Wed, 25 Feb 2004 00:14:00 -0800 (PST) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id F15C443D3F for ; Wed, 25 Feb 2004 00:13:59 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from mailproxy2.pacific.net.au (mailproxy2.pacific.net.au [61.8.0.87])i1P8Dt5O007199; Wed, 25 Feb 2004 19:13:55 +1100 Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246]) i1P8Dqch030346; Wed, 25 Feb 2004 19:13:53 +1100 Date: Wed, 25 Feb 2004 19:13:52 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Ion-Mihai Tetcu In-Reply-To: <20040225085917.3b813e5d@it.buh.cameradicommercio.ro> Message-ID: <20040225184209.R10284@gamplex.bde.org> References: <20040222185325.GA97979@cserv62.csub.edu> <53996.192.168.0.97.1077661722.squirrel@webmail.thilelli.net> <20040225085917.3b813e5d@it.buh.cameradicommercio.ro> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julien Gabel cc: freebsd-current@freebsd.org Subject: Re: Stray irq7. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2004 08:14:00 -0000 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