Subject: Re: reproducible kernel panic w/ 2.0RC4MP
To: Tim Kelly <hockey@dialectronics.com>
From: Pavel Cahyna <pavel.cahyna@st.mff.cuni.cz>
List: port-macppc
Date: 12/03/2004 20:42:56
On Fri, 03 Dec 2004 17:40:31 +0000, Tim Kelly wrote:

> 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.

Some comments:

1/ there is a possibility for different IPL_LOCK and IPL_HIGH. Quoting
the manual: 

     spllock()        blocks all hard and soft interrupts that can acquire a
                      simple lock.  This is provided as a distinct level from
                      splhigh() as some platforms may need to make use of
                      extremely high priority interrupts while locks are spin-
                      ning, which would be blocked by splhigh().

So, instead of defining a new SPL_IPI, maybe it could be possible to make
SPL_LOCK distinct from SPL_HIGH, and to spllock() block all interrupts
that splhigh() blocks, except IPIs. So you new IPL_IPI would become
IPL_HIGH and your IPL_HIGH would become IPL_LOCK.

2/ Either way, the manual states that spllock blocks all interrupts that
can acquire a simple lock. As IPIs won't be blocked by spllock(), you'll
have to audit the IPI handler if it doesn't attempt to take a simple lock.

Bye	Pavel