From owner-freebsd-usb@FreeBSD.ORG Sat Apr 2 10:37:00 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 B97DC16A4CE; Sat, 2 Apr 2005 10:37:00 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DD7C43D55; Sat, 2 Apr 2005 10:37:00 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j32Aamsf039054 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 2 Apr 2005 12:36:49 +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 j32AaWhs028653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2005 12:36:33 +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 j32AaWdN028651; Sat, 2 Apr 2005 12:36:32 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j32AaPJ5028650; Sat, 2 Apr 2005 12:36:25 +0200 (CEST) (envelope-from ticso) Date: Sat, 2 Apr 2005 12:36:25 +0200 From: Bernd Walter To: Warner Losh Message-ID: <20050402103624.GS2072@cicely12.cicely.de> References: <200504012144.11468.sebastien.b@swissinfo.org> <200504012317.54966.hselasky@c2i.net> <20050401213138.GQ2072@cicely12.cicely.de> <20050401.150254.74727545.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050401.150254.74727545.imp@bsdimp.com> 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.0010] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: ticso@cicely12.cicely.de cc: sebastien.b@swissinfo.org cc: iedowse@FreeBSD.ORG cc: ticso@cicely.de 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: ticso@cicely.de List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2005 10:37:00 -0000 On Fri, Apr 01, 2005 at 03:02:54PM -0700, Warner Losh wrote: > > > 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. > > I have a set of patches that convert the bridge interrupt routines > into a taskqueue. I did that so that we can mark them as non-giant > holding ISRs. This would be a reasonable context to do things like > sleeping from. However, you'd want to avoid that as much as possible > because sleeping for one request would block all the others in the > queue.... bridge = host controller? Sounds interesting. But I also don't understand the panic either. Timeouts seem to be handled but usbtask already, but this isn't a timeout anyway. It is aborting the receive xfer on ucom close and this is triggered by a userland close(2) call - no interrupt. In ohci.c it does: if (xfer->device->bus->intr_context || !curproc) panic("ohci_abort_xfer: not in process context"); OK - this one is from ohci, but they are all the same. intr_context is raised on interrupt handler start and decreased later. It seems that there is an artifical limitation that we are not allowed to sleep when processing USB interrupts. If one really goes to sleep a userland call might come in and has this variable raised. I don't know why it enforces not to be in interrupt context, maybe because of the long delays required to take an abort. But in this case it triggers wrong. In the meantime it should be safe not to check the intr_context part. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de