lots of malloc(M_WAITOK)'s in interrupt context from camisr

[M. Warner Losh]

In message: <12432.1051717236 at critter.freebsd.dk>
            "Poul-Henning Kamp" <phk at phk.freebsd.dk> writes:
: In message <16047.59842.60959.352839 at grasshopper.cs.duke.edu>, Andrew Gallatin 
: writes:
: >
: >Poul-Henning Kamp writes:
: > > In message <16047.59314.532227.475952 at grasshopper.cs.duke.edu>, Andrew Gallatin
: > >  writes:
: > > >
: > > >John Baldwin writes:
: > > >
: > > > > If you need to do more work in your interrupt routine than just wakeups
: > > > > and dinking with registers, you can always wake up a software interrupt
: > > > > handler or some other random kthread to do things that take a long amount
: > > >
: > > >Dumb question: Exactly what is one allowed to do in an INTR_FAST
: > > >interrupt context?  Obviously, you can't sleep.  But can you call
: > > >wakeup()?
: > > 
: > > Calling wakeup() is just about it, but we should actually define it
: > > more precisely in a suitable man-page.
: >
: >That would be cool.  Since wakeup() uses a spinlock,  I assume that
: >spinlocks are generally OK too..
: 
: I'm not sure you should infer too much yet...

Yes.  A spinlock in the context of wakeup being safe might be
radically different than spinlocks generally being safe.

I'm not sure that wakeup is safe in a fast interrupt context even.
I've always had to create a soft interrupt and call the sched routine
to get it to run.

We definitely need to document what's allowed in a fast interrupt
handler.  Generally as little as possible to placate the hardware and
the 'expensive' parts of the driver should be in a soft interrupt
thread.

Warner