From owner-freebsd-usb@FreeBSD.ORG Sat Apr 2 20:22:03 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 78D2116A4CE for ; Sat, 2 Apr 2005 20:22:03 +0000 (GMT) Received: from md1.swissinfo.org (md1.swissinfo.org [146.159.4.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9004D43D2F for ; Sat, 2 Apr 2005 20:22:01 +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 02-md50000379598.msg for ; Sat, 02 Apr 2005 22:18:41 +0200 Received: from AAmiens-152-1-35-123.w83-198.abo.wanadoo.fr (83.198.34.123) by mail.swissinfo.org (7.0.020) (authenticated as sebastien.b) id 4153942002E19647; Sat, 2 Apr 2005 22:21:46 +0200 From: Sebastien B To: hselasky@c2i.net Date: Sat, 2 Apr 2005 22:20:48 +0200 User-Agent: KMail/1.8 References: <6.2.1.2.0.20050329222822.04f7c500@64.7.153.2> <200504021101.11602.sebastien.b@swissinfo.org> <200504021316.59434.hselasky@c2i.net> In-Reply-To: <200504021316.59434.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504022220.49835.sebastien.b@swissinfo.org> X-Spam-Processed: phad1.swissinfo.org, Sat, 02 Apr 2005 22:18:41 +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, Sat, 02 Apr 2005 22:18:45 +0200 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 List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2005 20:22:03 -0000 > > > You can call usbd_transfer(), if the transfer is not > > > synchronous. > > > > But it is. To send network packets, I must perform two USB transfers on > > two different endpoints, and I must wait for the first one to complete > > before initiating the second. > > What you need to do is to allocate two [non synchronous] transfers besides > from the data transfer. The callback of the first transfer starts the > second transfer. The callback of the second transfer starts the data > transfer. Then you need to make a flag so that the first transfer is not > started again, before the data transfer has been started. This requires a quite complex locking mechanism by comparison to scheduling a software interrupt handler. Why is using a software interrupt handler and synchronous transfers wrong ? I've disabled the timeout in usbd_bulk_transfer() and it does not panic anymore. So this is indeed the timeout function which causes the panic when it is called.