Hello,

On Fri, 10 Dec 2004 20:29:28 +0000, Bill Studenmund wrote:

> On Fri, Dec 03, 2004 at 12:40:31PM -0500, Tim Kelly wrote:

>> After I went over the code extensively, and after not once seeing a lock
>> panic (LOCKDEBUG) or a re-entrancy into do_pending_intr after setting
>> the panic semaphore, I had to conclude the problem was not a lock or
>> race and was elsewhere. Along the way, however, I changed some code in
>> extintr.c to bring it in line with simple lock requirements, which is
>> that the irq should not be enabled until after the simple lock is
>> acquired and released. For the non-openpic Macs, the original code was
>> re-enabling the irq before acquiring the lock. I also added another
>> layer of IPL to the MULTIPROCESSOR case, to also bring it in line with
>> the kern_lock.c notes. This places an IPL_IPI in between IPL_HIGH and
>> IPL_SERIAL. Putting IPL_IPI at the same level as IPI_SERIAL led to some
>> problems with the serial console. Putting IPL_IPI above IPI_HIGH ensures
>> that even during a simple lock any deferred IPI interrupts get
>> processed, but nothing else will.
> 
> I agree with Pavel and think that we need to be careful about having
> IPL_IPI above IPI_HIGH. Well, specifically above SPL_LOCK. And actually I
> really think we shouldn't. I realize that you may have changed your mind
> on this (the last patch I've seen is just turning interrupts on a bit
> earlier) and thus the comment is just accademic. :-) I think it would be
> difficult in the long run to ensure that IPIs never need to grab locks
> (especially if they can on other platforms), and so we can get into a
> mess.

In fact, i386 has an IPL_IPI which is above IPL_HIGH.
See also the log for PR 28541. I don't understand the acquire() function
enough to tell if not having an IPL_IPI above IPL_LOCK can lead to
deadlock or not.

Bye	Pavel