panic: uhci_abort_xfer: not in process context

[Bernd Walter]

On Fri, Apr 01, 2005 at 03:02:54PM -0700, Warner Losh wrote:
> > > The solution is to use DELAY() instead of tsleep() and usb_delay_ms().
> > 
> > This is wrong either way - wasting cycles in interrupt context is bad.
> > IMO the timeout function should trigger a softint doing the real job.
> > Maybe Ian has an idea about this - he did a lot in respect to timeout
> > and aborting xfers lately and should be familar with this point.
> > To be shure it still exists you should verify with latest code.
> 
> I have a set of patches that convert the bridge interrupt routines
> into a taskqueue.  I did that so that we can mark them as non-giant
> holding ISRs.  This would be a reasonable context to do things like
> sleeping from.  However, you'd want to avoid that as much as possible
> because sleeping for one request would block all the others in the
> queue....

bridge = host controller?
Sounds interesting.

But I also don't understand the panic either.
Timeouts seem to be handled but usbtask already, but this isn't a
timeout anyway.
It is aborting the receive xfer on ucom close and this is triggered
by a userland close(2) call - no interrupt.

In ohci.c it does:
        if (xfer->device->bus->intr_context || !curproc)
                panic("ohci_abort_xfer: not in process context");
OK - this one is from ohci, but they are all the same.
intr_context is raised on interrupt handler start and decreased later.
It seems that there is an artifical limitation that we are not allowed
to sleep when processing USB interrupts.
If one really goes to sleep a userland call might come in and has
this variable raised.
I don't know why it enforces not to be in interrupt context, maybe
because of the long delays required to take an abort.
But in this case it triggers wrong.
In the meantime it should be safe not to check the intr_context part.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd at bwct.de                                  info at bwct.de