Date: Sun, 3 Apr 2005 17:52:38 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: panic: uhci_abort_xfer: not in process context Message-ID: <20050403155237.GC36141@cicely12.cicely.de> In-Reply-To: <200504031706.39252.hselasky@c2i.net> References: <6.2.1.2.0.20050329222822.04f7c500@64.7.153.2> <200504021316.59434.hselasky@c2i.net> <200504022220.49835.sebastien.b@swissinfo.org> <200504031706.39252.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Apr 03, 2005 at 05:06:38PM +0200, Hans Petter Selasky wrote: > On Saturday 02 April 2005 17:32, Ian Dowse wrote: > > It would be possible to implement an asynchronous version of > > usbd_abort_pipe() that invokes a callback on completion. That seems > > like a good idea, as it would allow us to handle the cases where > > we need to initiate the abort from a callback. > > If one doesn't block when a transfer is aborted, one has to block when the > transfer is started again, so the problem is not solved. But I don't > understand: If usbd_abort_pipe() is called from a non-blocking context for > example an USB-callback, and it is able to detect this, why does it not pass > a flag to the hardware abort routine to use DELAY() instead of tsleep()? Even > if it is not efficient, that is a driver design problem. Also if a > synchronous transfer is started from an USB-callback, why does the existing > driver not poll the hardware until the transfer has finished? No - Ian is right - the panic has to be there. My original complains where not about the panic itself - I errously asumed it triggers in wrong cases. The panic is there to enforce proper driver design. While DELAY would allow the machine to run in principle it is that bad for system speed that you can't allow. Abort_pipe for currently supported host controller require a delay for a whole USB frame. If you block the interrupt routine for that long you can easily break performance to almost zero. And you loose two whole frames which break isochronous and interrupt pipe requirements. Not to speak about wasted CPU time. Overall it is nothing really new to driver programmers - it was never OK to waste time in upcalls. -- 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?20050403155237.GC36141>