At 11:53 AM -0500 3/17/05, Nathan J. Williams wrote:
>Tim Kelly <hockey@dialectronics.com> writes:
>
>> According to the commit message, your patch doesn't enable interrupts if
>> they were already off.
>
>Correct.
>
>> 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).
>
>"The problem" was interrupts happening in trap() before the rest of
>the kernel had enabled PSL_EE for mainstream use, and do_pending_int()
>checking for that condition.

Unless I'm mistaken, several (all?) devices require interrupts to be on
during the attachment process, and as Timo's panic occured immmediately
after attaching USB devices, I infer that the kernel had made PSL_EE
available for mainstream use. My point being that you had stated that the
trap patch you committed might fix this problem, but the panic is from
PSL_EE being off during a deferred interrupt. Since the original code
turned interrupts on, do_pending_int() would not have seen PSL_EE off after
the trap call and therefore not panic'd. Your patch should therefore
illuminate more times in which PSL_EE has been turned off, as it preserves
the interrupt status when called into the trap.

By extension, and I'm thinking out loud here, a deferred interrupt could
only occur if interrupts were already on during the attachment process
(perhaps while the IPL was at high during the grackle conf_read).
Therefore, my focus was on identifying locations in which PSL_EE is turned
off incorrectly, and that further investigation is warranted.

If I am not grasping something here, I'd like to fix that.

tim