Date: Sat, 2 Apr 2005 11:01:10 +0200 From: Sebastien B <sebastien.b@swissinfo.org> To: freebsd-usb@freebsd.org, hselasky@c2i.net Subject: Re: panic: uhci_abort_xfer: not in process context (was Re: uplcom / ucom problems on RELENG_5) Message-ID: <200504021101.11602.sebastien.b@swissinfo.org> In-Reply-To: <200504012317.54966.hselasky@c2i.net> References: <6.2.1.2.0.20050329222822.04f7c500@64.7.153.2> <200504012144.11468.sebastien.b@swissinfo.org> <200504012317.54966.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200504021101.11602.sebastien.b>