At 12:35 PM -0500 3/17/05, Nathan J. Williams wrote:
>> 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.
>
>Nope. See src/sys/arch/macppc/macppc/autoconf.c. Devices are probed
>from the root by calling config_rootfound(), and *after* that has
>probed the entire device tree, device interrupts are intentionally
>enabled.

While my understanding of SCSI and mesh is limited, in working with it
while porting OpenBSD to Old World Macs
(http://www.dialectronics.com/OldWorldMacs), my understanding is that
discovering scsi devices requires probing the scsi devices and waiting for
interrupts in mesh_intr.

Is this incorrect?

>> 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.
>
>But the rfi after the trap restored the state of the MSR, which has
>PSL_EE disabled, which is why do_pending_int() saw it off and
>panic'd. PSL_EE was only enabled for the duration of the trap
>handling, not enabled from that point forward.

Ah, perhaps I'm focused on one aspect of your commit message. In preserving
the interrupt state, this does include when it was on before trap was
called, correct?

thanks again,
tim