Date: Fri, 1 Apr 2005 23:31:39 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: Hans Petter Selasky <hselasky@c2i.net>, iedowse@freebsd.org Cc: freebsd-usb@freebsd.org Subject: Re: panic: uhci_abort_xfer: not in process context (was Re: uplcom / ucom problems on RELENG_5) Message-ID: <20050401213138.GQ2072@cicely12.cicely.de> In-Reply-To: <200504012317.54966.hselasky@c2i.net> References: <6.2.1.2.0.20050329222822.04f7c500@64.7.153.2> <200503311946.23151.hselasky@c2i.net> <200504012144.11468.sebastien.b@swissinfo.org> <200504012317.54966.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 01, 2005 at 11:17:53PM +0200, Hans Petter Selasky wrote: > 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. this is not really true. Under 5.x only fast interrupt handlers are running in interrupt context. It should be perfectly OK to sleep in a callback function. > But the panic is a bug, and it might be because the ehci_abort_xfer() function > is called from the transfer's timeout function? Likely something in this line. AFAIK timer events are directly called from the interrupt handler. > 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. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050401213138.GQ2072>