Tim Kelly <hockey@dialectronics.com> writes:

> 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?

Attachment of SCSI devices happens after the main configuration tree,
usually in a kthread, for this reason. So yes, a few devices require
interrupts for configuration, but they are specially deferred until
after the normal configuration tree is finished.

> >> 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?

Yes. Look at the code; instead of setting PSL_EE in the MSR, it
selects the old value of PSL_EE from the saved MSR (srr1) and or's
that in to the current MSR (which would have it cleared, as nearly all
MSR bits are cleared on entry to an exception handler).

        - Nathan