From owner-freebsd-usb@FreeBSD.ORG Sat Apr 2 20:08:54 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 70F9D16A4CF for ; Sat, 2 Apr 2005 20:08:54 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9588643D2D for ; Sat, 2 Apr 2005 20:08:53 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j32K8msf052047 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 2 Apr 2005 22:08:50 +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 j32K7whs031811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2005 22:07:58 +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 j32K7vRh031261; Sat, 2 Apr 2005 22:07:57 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j32K7uQ4031260; Sat, 2 Apr 2005 22:07:56 +0200 (CEST) (envelope-from ticso) Date: Sat, 2 Apr 2005 22:07:56 +0200 From: Bernd Walter To: Ian Dowse Message-ID: <20050402200756.GV2072@cicely12.cicely.de> References: <20050402171938.GU2072@cicely12.cicely.de> <200504021902.aa86365@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504021902.aa86365@salmon.maths.tcd.ie> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-0.9 required=3.0 tests=BAYES_30 autolearn=no version=2.64 X-Spam-Report: * -0.9 BAYES_30 BODY: Bayesian spam probability is 30 to 40% * [score: 0.3353] 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: 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 20:08:54 -0000 On Sat, Apr 02, 2005 at 07:02:18PM +0100, Ian Dowse wrote: > In message <20050402171938.GU2072@cicely12.cicely.de>, Bernd Walter writes: > >I fully agree with you - in general. > >You see the inetrrupt routine as non-blocking context. > >Fine - abort_xfer is bad as it blocks for a long time - agreed. > >But we need any kind of syncronisation with top half. > >Although taking a mutex may block I don't consider it bad as it should > >not be hold for long time and therefor waiting a long time is unlikely. > >Allowing to wait for a Mutex in the bottom half is the whole reason we > >have interrupt threads. > >But that is the current problem - we are not even allowed to take > >a Mutex, just because intr_context isn't safe. > >The panic was triggered by a userland call that was claimed to be in > >interrupt context. > >OK - I was wrong in that it was not close, but that doesn't change > >anything with the basic problem: > >The panic triggered when it shouldn't. > > Maybe I'm misunderstanding the cause of some of these panics, so > correct me if this sounds wrong. There seem to be two ways for the > "not in process context" panic to occur. One is where usbd_abort_pipe() > is called directly from an interrupt thread. The other way is for > a callback to be called from interrupt thread and that callback > sleeps. This allows other threads to enter the USB code with > intr_context > 0, so the panic can be incorrectly triggered. > > In both cases, the bug is that a callback function is sleeping and > allowing other threads to run. I'm not sure I understand your > comments about locking mutexes though. It is fine for a callback > function to acquire a mutex, because acquiring a mutex is not really > sleeping, because currently held locks are not dropped even if the > mutex cannot be acquired immediately. For example, the USB system > will hold Giant at the time that the interrupt thread is calling > completion callbacks. Even if one of those callbacks needs to acquire > another mutex that is currently locked, Giant will not be dropped > while that mutex is acquired, so no other threads can enter the USB > code. The problem is limited to tsleep/msleep where all mutexes are > dropped. > > A more specific statement of the original comments would be that > callbacks in asynchronous event systems should not call tsleep or > msleep, no matter what the calling context is. Yes - you are right - my fault. I missread the panic - in fact it is called from a callback, and I somehow asumed that mtx_lock could release GIANT. The panic is justified. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de