I believe that this will work:

if you test the curproc pointer, a zero value implies no process is currently
running,
you would thus have hit the code path from the kernel's hardclock function.

i.e.

    if  (!curproc)
        {
        /* base level 0, unsafe to call tsleep */
        return;
        }

-paul

Matthew Jacob wrote:

> I have several possible entry points into a code path in a driver which can
> decide whether to ltsleep for an event or poll. If I know I've entered via an
> interrupt (e.g., the device interrupt service routine)- I can mark state so
> that I don't attempt to ltsleep.
>
> But it turns out that there is a normal callback via hardclock (in scsipi)
> that I have no means of distinguishing from any other call. How can I tell if
> I'm on the interrupt stack and it's not safe to call ltsleep?
>
> -matt