On Sun, Sep 12, 1999 at 05:19:36PM +0930, Brett Lymn wrote:
> 
> Folks,
>         Can tsleep be called within an interrupt context?  I have

No !

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

I looked at this code, it's not easy as it is structured here.
You will need to change the code to handle most timeout conditions from
within the process context (that is, tsleep() while in process context
and set a flag and call wakeup() from wttimer(), instead of handling the
timeout from here).

--
Manuel Bouyer <bouyer@antioche.eu.org>
--