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 [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message