> Fortunately for me I have KTRACE defined which means that curproc is
> referenced in tsleep - this is the point at which tsleep was causing
> the panic.  
> 
> I suppose what I need to do is modify the function so if it is called
> from within an interrupt it avoids tsleep.  I think the function is
> shared between interrupt & proc contexts so tsleep may be appropriate
> some of the time :-/

One common way to deal is to define FOO_NOWAIT/FOO_WAIT flags, and
pass them down the call chain as appropriate.

The interrupt handler passes NOWAIT, the device driver ops pass WAIT,
and you've given the routine enough of a hint that it knows when it's
safe to sleep and when it should do things in an event-driven way.

An alternative is to rewrite the code in a more event-driven way and
put the sleep higher up in the driver.. (I haven't looked at the
driver in question at all so I'm not sure which is most appropriate to
this situation..)

					- Bill