> Ok, let me go slow to make sure _I_ am hearing you right. There are places
> in the code where you register a callback of some sort, and that same
> callback can get called both in an interrupt context and out of an
> interrupt context. Correct?
>
> What callback is this?
>
> Sounds like an interface needs tweaking.

No and yes.

To be more specific- the entry point for SCSI HBAs to start requests may be
called either from process context or from clock timer context (the latter of
which I hadn't paid noted) or from interrupt context.

I was handling the case of interrupt context because the only way this can be
entered from interrupt context is if the interrupt had come through my
interrupt service routine- in which case I'd marked softc state that was "on
interrupt stack"- and thus should not use tsleep to wait for mailbox commands
to complete (if I were to start any) but instead poll for completion.


The specific error condition is that the return of BUSY status from a device
causes gets propagated back to the SCSI midlayer- which then schedules a
thread to deal with the exception. The thread then does a callout reset to
rerun the command in one second (if it had retries). This then calls my HBA
driver from the clock interrupt context, and kaboom....

I think I can and should fix this specific case by just having the (U!$)(!$*
scsipi completion thread run the command itself after a timer expires- tha is,
the timer just wakes the thread again and it can run things in process context
which is peachy.


The generic case, which is something I'll still hold to, is that I assert that
any piece of random kernel code should be able to ask:

	"Is it safe for me to call tsleep or not?"


-matt