From owner-freebsd-usb@FreeBSD.ORG Sat Apr 2 11:16: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 0AA3216A4CE for ; Sat, 2 Apr 2005 11:16:06 +0000 (GMT) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C4FB43D31 for ; Sat, 2 Apr 2005 11:16:05 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-228-17.daxnet.no ([193.217.228.17] verified) by mailfe03.swip.net (CommuniGate Pro SMTP 4.2.9) with ESMTP id 136272821; Sat, 02 Apr 2005 13:16:03 +0200 From: Hans Petter Selasky To: Sebastien B Date: Sat, 2 Apr 2005 13:16:55 +0200 User-Agent: KMail/1.7 References: <6.2.1.2.0.20050329222822.04f7c500@64.7.153.2> <200504012317.54966.hselasky@c2i.net> <200504021101.11602.sebastien.b@swissinfo.org> In-Reply-To: <200504021101.11602.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: <200504021316.59434.hselasky@c2i.net> 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: hselasky@c2i.net List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2005 11:16:06 -0000 On Saturday 02 April 2005 11:01, Sebastien B wrote: > > > 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. > > Does a software interrupt handler run in interrupt context? > And what about task queue threads ? > Anyway, it doesn't crash while my software interrupt handler is running, > but later in the "usbtask" thread. The problem is that the USB-callback() must return, in order to have other USB-callbacks() called, because the callbacks are called in serial from the same thread. While you are in the callback you are blocking "the USB system". In my USB driver I have introduced a transfer flag called "USBD_USE_POLLING" that will allow this. When one starts a transfer from a callback with this flag set, it will poll the interrupt handler until the transfer is finished. This will block the USB-system for less than 1 ms. Using this flag can save some code and complexity. But the best solution is to "chain" transfers, having the callback of a transfer call the start routine of the next transfer. > > > 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. Also you need to make sure that these extra transfers are aborted at device attach. Yours --HPS