Folks,
        Can tsleep be called within an interrupt context?  I have
found a 100% sure-fire way to panic a reasonably current NetBSD by
popping a QIC tape out of the drive at the wrong time during a restore
(I always seem to do this - I rip the tape out at the volume prompt
instead of waiting for the device prompt).  It appears that the wt
driver is calling tsleep from within it's interrupt handler and tsleep
is referencing cur_proc (I have KTRACE defined in my kernel build)
which is null (i.e. machine is idle, no?).  At this point the machine
panics, this is the trace I get from ddb:

tsleep(f0201d40, 20, f0253288, 1) at tsleep + 0x80
wtsoft(f04a6900, 1, 1) at wtsoft + 0xbe
wtstatus(f04a6900) at wtstatus + 0xa4
wtsense(f04a6900, 1, 10, f04a6900, 80000000) at wtsense + 0x14
wtintr(f04a6900) at wtintr + 0x60
wttimer(f04a6900) at wttimer + 0x59
softclock(f04f3ca0, f66cb3c0, f66cb3c0, 1, f66dbe64) at softclock + 0x6a
hardclock(f66dbe70, f66dbe66c, f0100e86, f66dbe70, 0) at hardclock + 0x1a5
clockintr(f66dbe70) at clockintr + 0xb
Xintr0() at Xintr0 + 0x6c

If tsleep is not appropriate here, what do we use?

-- 
===============================================================================
Brett Lymn, Computer Systems Administrator, British Aerospace Australia
===============================================================================