Subject: Re: reproducible kernel panic w/ 2.0RC4MP
To: Matt Thomas <matt@3am-software.com>
From: Tim Kelly <hockey@dialectronics.com>
List: port-macppc
Date: 12/03/2004 13:59:41
At 10:26 AM -0800 12/3/04, Matt Thomas wrote:
>>+               if (!(emsr & PSL_EE)) {
>>+                       emsr |= PSL_EE;
>>+                       /* already pending interrupts get processed */
>>+                       /* because the mask is against earlier pcpl */
>>+                       /* new interrupts get marked pending */
>>+                       splraise(imask[IPL_IPI]);
>>+               }
>>+
>>+
>>  #endif
>>
>>just comment out the
>>
>>         splraise(imask[IPL_IPI]);
>
>
>which means this comes to
>
>     tmsr = emsr;
>     if (ci->ci_cpuid == 0) {
>         emsr |= PSL_EE;



Yeah, I guess so :-) I've been preferring to err on the side of caution in
this patch.

if (!(emsr & PSL_EE))

was also remnant of reporting how often the CPU came to do_pending_int with
its PSL_EE off (not always). Plus it seemed that if CPU1 came with its
PSL_EE off and I turned it back on, it wasn't happy. I have not yet
reviewed testing of this. Mainly I wanted to get a bug fix posted and
refine the code after testing showed it was solid.

I've also reviewed my notes and the problems I had with IPL_IPI being
higher than IPL_SERIAL came before I had fully implementing turning on
PSL_EE. Since it's possible (?) that a serial connection could end up
requiring a vfork*, I will revise the hierarchy to place IPL_IPI above
IPL_SERIAL and test. It seems to me that IPIs need to be processed no
matter what is going on, as the requesting process may be tying up some
resources.

tim

* author freely admits he may not know what he is talking about and could
be wrong