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