From owner-freebsd-smp Wed Dec 3 16:25:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26902 for smp-outgoing; Wed, 3 Dec 1997 16:25:43 -0800 (PST) (envelope-from owner-freebsd-smp) Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id QAA26893 for ; Wed, 3 Dec 1997 16:25:38 -0800 (PST) (envelope-from jre@ipsilon.com) Received: from radio.ipsilon.com (radio.Ipsilon.COM [205.226.28.3]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id QAA02870; Wed, 3 Dec 1997 16:24:34 -0800 Message-ID: <3485F851.3F54BC7E@ipsilon.com> Date: Wed, 03 Dec 1997 16:24:49 -0800 From: Joe Eykholt Organization: Ipsilon Software Engineering X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.1.0-RELEASE i386) MIME-Version: 1.0 To: Steve Passe CC: smp@freebsd.org Subject: Re: SMP References: <199712032347.QAA10070@Ilsa.StevesCafe.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Steve Passe wrote: > > Hi, > > > 5. The APIC vectors need to be re-arranged into a priority order so > > that interrupts > > don't need to access the I/O APIC to mask off the interrupt during > > handling. > > (Or maybe there's a better way to do this). I noticed that > > level-sensitive > > interrupts are getting taken twice, because the first interrupt only > > masks with CPL, > > so after the EOI and sti, the interrupt is still pending and is taken > > again. Only > > the second time does it get masked in the I/O APIC. Being a central > > sounds like you are describing our "lazy masking" an attempt to skip blocking > an INT unless we get hit a second time. If what you are saying about the > second hit being automatic is true, its something for me to tackle real soon. > Have you actually demonstrated this to occur all times? Or just ocassionally? > OR just via code examination? Could you descibe a specific example that would > help me grok the specific situation? I think so. I added a counter for interrupts deferred due to cpl and that counter was 1/2 the total interrupt count (I counted all interrupts whether deferred or not). All my interrupts were PCI devices (level sensitive), so I'm pretty sure that's what's happening. I also saw a stack trace that showed that the second interrupt occurred just after the first handler did the sti instruction. I've made other changes to the INTR() macro, but I think the same thing would happen in the -current APIC version. Joe