From owner-freebsd-usb@FreeBSD.ORG Fri Apr 1 21:16:56 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 EB64116A4CE for ; Fri, 1 Apr 2005 21:16:56 +0000 (GMT) Received: from swip.net (mailfe08.swip.net [212.247.154.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28CF243D31 for ; Fri, 1 Apr 2005 21:16:56 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-228-195.daxnet.no ([193.217.228.195] verified) by mailfe08.swip.net (CommuniGate Pro SMTP 4.2.9) with ESMTP id 135480545; Fri, 01 Apr 2005 23:16:54 +0200 From: Hans Petter Selasky To: Sebastien B Date: Fri, 1 Apr 2005 23:17:53 +0200 User-Agent: KMail/1.7 References: <6.2.1.2.0.20050329222822.04f7c500@64.7.153.2> <200503311946.23151.hselasky@c2i.net> <200504012144.11468.sebastien.b@swissinfo.org> In-Reply-To: <200504012144.11468.sebastien.b@swissinfo.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504012317.54966.hselasky@c2i.net> 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: hselasky@c2i.net 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:16:57 -0000 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. But the panic is a bug, and it might be because the ehci_abort_xfer() function is called from the transfer's timeout function? The solution is to use DELAY() instead of tsleep() and usb_delay_ms(). Yours --HPS