panic: uhci_abort_xfer: not in process context

[Hans Petter Selasky]

On Saturday 02 April 2005 11:01, Sebastien B wrote:
> > > The
> > > kernel panics with "ehci_abort_xfer: not in process context" a few
> > > while after the transfer. Is it the same problem ? Is a software
> > > interrupt handler unsuitable for the abort xfer function ? How can I
> > > fix it, by using a task queue instead of a software interrupt handler ?
> > > Regards,
> > > Sebastien
> >
> > With the existing USB driver you cannot call usbd_abort_pipe() nor
> > usbd_bulk_transfer(), from an interrupt context or callback, because
> > those functions will sleep.
>
> Does a software interrupt handler run in interrupt context?
> And what about task queue threads ?
> Anyway, it doesn't crash while my software interrupt handler is running,
> but later in the "usbtask" thread.

The problem is that the USB-callback() must return, in order to have other 
USB-callbacks() called, because the callbacks are called in serial from the 
same thread. While you are in the callback you are blocking "the USB system". 
In my USB driver I have introduced a transfer flag called "USBD_USE_POLLING" 
that will allow this. When one starts a transfer from a callback with this 
flag set, it will poll the interrupt handler until the transfer is finished. 
This will block the USB-system for less than 1 ms. Using this flag can save 
some code and complexity. But the best solution is to "chain" transfers, 
having the callback of a transfer call the start routine of the next 
transfer.

>
> > You can call usbd_transfer(), if the transfer is not
> > synchronous.
>
> But it is. To send network packets, I must perform two USB transfers on two
> different endpoints, and I must wait for the first one to complete before
> initiating the second.

What you need to do is to allocate two [non synchronous] transfers besides 
from the data transfer. The callback of the first transfer starts the second 
transfer. The callback of the second transfer starts the data transfer. Then 
you need to make a flag so that the first transfer is not started again, 
before the data transfer has been started. Also you need to make sure that 
these extra transfers are aborted at device attach.

Yours
--HPS