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 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
