From owner-freebsd-usb@FreeBSD.ORG Sun Apr 3 15:53:06 2005 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B719B16A4CE for ; Sun, 3 Apr 2005 15:53:06 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD4C043D2D for ; Sun, 3 Apr 2005 15:53:05 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j33Fqxsf088466 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 3 Apr 2005 17:53:02 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j33Fqchs038685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Apr 2005 17:52:39 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j33Fqc5j037763; Sun, 3 Apr 2005 17:52:38 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j33FqcSo037762; Sun, 3 Apr 2005 17:52:38 +0200 (CEST) (envelope-from ticso) Date: Sun, 3 Apr 2005 17:52:38 +0200 From: Bernd Walter To: Hans Petter Selasky Message-ID: <20050403155237.GC36141@cicely12.cicely.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504031706.39252.hselasky@c2i.net> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: Sebastien B cc: freebsd-usb@freebsd.org Subject: Re: panic: uhci_abort_xfer: not in process context X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Apr 2005 15:53:06 -0000 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