panic: uhci_abort_xfer: not in process context (was Re: uplcom / ucom problems on RELENG_5)

[Hans Petter Selasky]

On Friday 01 April 2005 21:44, Sebastien B wrote:
> > When one is designing a driver, it is very convenient if USB-transfers
> > can be stopped/started from the callback of another USB-transfer.
>
> I have run exactly into the same trouble by calling usbd_bulk_transfer()
> from a software interrupt handler (scheduled to run from the context of the
> start procedure of a network interface in order to send packets). 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. You can call usbd_transfer(), if the transfer is not 
synchronous.

But the panic is a bug, and it might be because the ehci_abort_xfer() function 
is called from the transfer's timeout function?

The solution is to use DELAY() instead of tsleep() and usb_delay_ms().

Yours
--HPS