From owner-freebsd-usb@FreeBSD.ORG Fri Apr 1 19:45:09 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 61BBB16A4CE for ; Fri, 1 Apr 2005 19:45:09 +0000 (GMT) Received: from md1.swissinfo.org (md1.swissinfo.org [146.159.4.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8285343D39 for ; Fri, 1 Apr 2005 19:45:08 +0000 (GMT) (envelope-from sebastien.b@swissinfo.org) Received: from mail.swissinfo.org ([194.6.181.33]) by md1.swissinfo.org (phad1.swissinfo.org [146.159.6.9]) (MDaemon.PRO.v7.2.1.R) with ESMTP id 20-md50000378135.msg for ; Fri, 01 Apr 2005 21:41:54 +0200 Received: from AAmiens-152-1-45-158.w83-198.abo.wanadoo.fr (83.198.164.158) by mail.swissinfo.org (7.0.020) (authenticated as sebastien.b) id 4153942002DECB89; Fri, 1 Apr 2005 21:45:01 +0200 From: Sebastien B To: freebsd-usb@freebsd.org Date: Fri, 1 Apr 2005 21:44:10 +0200 User-Agent: KMail/1.8 References: <6.2.1.2.0.20050329222822.04f7c500@64.7.153.2> <6.2.1.2.0.20050331074641.04f72eb8@64.7.153.2> <200503311946.23151.hselasky@c2i.net> In-Reply-To: <200503311946.23151.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504012144.11468.sebastien.b@swissinfo.org> X-Spam-Processed: phad1.swissinfo.org, Fri, 01 Apr 2005 21:41:54 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 194.6.181.33 X-Return-Path: sebastien.b@swissinfo.org X-MDaemon-Deliver-To: freebsd-usb@freebsd.org X-MDAV-Processed: phad1.swissinfo.org, Fri, 01 Apr 2005 21:41:58 +0200 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 List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2005 19:45:09 -0000 > 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