From owner-freebsd-hackers Thu Apr 18 13:40:25 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 304EF37B404 for ; Thu, 18 Apr 2002 13:40:19 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g3IKdwe96005; Thu, 18 Apr 2002 14:39:58 -0600 (MDT) (envelope-from ken) Date: Thu, 18 Apr 2002 14:39:58 -0600 From: "Kenneth D. Merry" To: Matthew Jacob Cc: hackers@FreeBSD.ORG Subject: Re: naive i386 && FreeBSD interrupt question Message-ID: <20020418143958.A95892@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from mjacob@feral.com on Thu, Apr 18, 2002 at 12:27:33PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Apr 18, 2002 at 12:27:33 -0700, Matthew Jacob wrote: > > This was -stable- but it's really a hacker's question. > > I really am *not* much of an i386 weenie and I'll have to admit that I don't > fully understand the interrupt mask scheme and I ran into a troubling problem. > > I was running some very extensive tests on a dual processor (but not SMP > configured) system- I was in the middle of calling busdma_load from the isp > driver when I got interrupted and blew up fielding an isp interrupt. > > Now- this shouldn't have happened. When I entered the isp driver, I'd called > splcam- this should have blocked me from being interrupted. However, in > calling busdma_load, I'd also called splsoftvm() (this is code copied, > blindly, from other drivers). > > Now- if I was running on a 68020 or a Sparc or an Alpha, I would simply have > assumed that the splsoftvm had (*smack*) forcibly lowered PIL. Oops. It was > just for this reason that in SunOS all named spl calls were turned into > > s = splr(pritospl(device_interrupt_priority)); > > which would only raise (if needed) priority- never lower it. > > So- when I went to try and deduce what was going on for i386, I become a bit > confused because, haha, that's right, all interrupts are separately maskable > and have nothing really to do (I *think*- I'm paying the price for not really > knowing i386 well enough) with a global processor priority level. > > So- what's the deal here? Why did a call to splsoftm *apparently* unmask the > CAM device blockage such that I got interrupted when I thought I was blocked? > > A short "RTFC" is a fine answer- but if somebody could clue me in, that'd be > nice. I'm no expert on this, but from sys/i386/isa/ipl_funcs.c, it looks like both splsoftvm() and splcam() are |= masks, so they should be in addition to whatever mask you had before. So it looks like things should work as you expected. So why didn't it work as you expected? I dunno. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message