>At 11:41 AM -0500 3/16/05, Nathan J. Williams wrote:
>>Timo Schoeler <wanker4freedom@web.de> writes:
>>
>>> NetBSD 2.99.16 (GENERIC) #0: Wed Mar  2 13:39:16 CET 2005
>>>
>>>tis@mcbain.es43-bln.macfinity.net:/usr/obj/sys/arch/macppc/compile/
>>> panic: kernel diagnostic assertion "emsr & PSL_EE" failed: file
>>> "/usr/src/sys/ar
>>> ch/macppc/macppc/extintr.c", line 809
>>> Stopped in pid 0.1 (swapper) at netbsd:cpu_Debugger+0x18:       lwz
>>> r11, r1,
>>>   0x0
>>
>>This looks an awful lot like my PR port-macppc/29559, which I fixed a
>>few days after that (sys/arch/powerpc/powerpc/trap_subr.S rev 1.57, on
>>4 March). Can you try slightly newer sources and see if it helps?
>>
>>        - Nathan

According to the commit message, your patch doesn't enable interrupts if
they were already off. The KASSERT in extintr.c in do_pending_int() checks
that interrupts are enabled (per a suggestion I made some time ago,
although my approach reported this condition and corrected it while in
do_pending_int() instead of panic'ing). As I see it, by preserving
interrupt status, your patch would highlight problems in which PSL_EE was
off after traps when it wasn't supposed to be, rather than eliminate the
problem outright (but determining where PSL_EE is off incorrectly is highly
needed).

It seems to me that this code:

_C_LABEL(extint_call):
        bl      _C_LABEL(extint_call)   /* to be filled in later */

intr_exit:
/* Disable interrupts (should already be disabled) and MMU here: */
        mfmsr   %r3
        andi.   %r3,%r3,~(PSL_EE|PSL_ME|PSL_RI|PSL_DR|PSL_IR)@l
        mtmsr   %r3
        isync


in trap_subr.S could leave PSL_EE off, if where rfi returns to doesn't
enable it. Should this code also preserve interrupt status before it exits?

tim