From owner-freebsd-usb@FreeBSD.ORG Fri Apr 1 21:32:45 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 867E016A4CF; Fri, 1 Apr 2005 21:32:45 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id A001F43D1D; Fri, 1 Apr 2005 21:32:44 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j31LWasf018687 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 1 Apr 2005 23:32:39 +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 j31LVehs024325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Apr 2005 23:31:40 +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 j31LVdWQ071789; Fri, 1 Apr 2005 23:31:39 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j31LVdoj071788; Fri, 1 Apr 2005 23:31:39 +0200 (CEST) (envelope-from ticso) Date: Fri, 1 Apr 2005 23:31:39 +0200 From: Bernd Walter To: Hans Petter Selasky , iedowse@freebsd.org Message-ID: <20050401213138.GQ2072@cicely12.cicely.de> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504012317.54966.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.0022] 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 (was Re: uplcom / ucom problems on RELENG_5) 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: Fri, 01 Apr 2005 21:32:45 -0000 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