From owner-freebsd-hackers Thu Apr 18 12:27:38 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 6854237B400 for ; Thu, 18 Apr 2002 12:27:34 -0700 (PDT) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g3IJRXf86618 for ; Thu, 18 Apr 2002 12:27:33 -0700 (PDT) (envelope-from mjacob@feral.com) Date: Thu, 18 Apr 2002 12:27:33 -0700 (PDT) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: hackers@freebsd.org Subject: naive i386 && FreeBSD interrupt question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 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. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message