From owner-freebsd-usb@FreeBSD.ORG Sat Mar 26 23:33:24 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 5519416A4CE for ; Sat, 26 Mar 2005 23:33:24 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7290243D46 for ; Sat, 26 Mar 2005 23:33:23 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j2QNXIsf034360 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 27 Mar 2005 00:33:21 +0100 (CET) (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 j2QNWGVK075776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 27 Mar 2005 00:32:16 +0100 (CET) (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 j2QNWFF2017833; Sun, 27 Mar 2005 00:32:15 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j2QNWFrM017832; Sun, 27 Mar 2005 00:32:15 +0100 (CET) (envelope-from ticso) Date: Sun, 27 Mar 2005 00:32:15 +0100 From: Bernd Walter To: Sebastien B Message-ID: <20050326233214.GM14532@cicely12.cicely.de> References: <200503261558.21943.sebastien.b@swissinfo.org> <20050326181317.GE14532@cicely12.cicely.de> <200503262158.32320.sebastien.b@swissinfo.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503262158.32320.sebastien.b@swissinfo.org> 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.0091] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: ticso@cicely.de cc: freebsd-usb@freebsd.org Subject: Re: What's the right way to wait for an USB transfer to complete ? 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, 26 Mar 2005 23:33:24 -0000 On Sat, Mar 26, 2005 at 09:58:31PM +0000, Sebastien B wrote: > Hello, > > > > Locking the mutex in the software interrupt handler causes a kernel panic > > > in propagate_priority (it seems to occur only when the mutex is already > > > held by another thread, therefore mtx_lock() blocks) : > > > > > > Fatal trap 12: page fault while in kernel mode > > > fault virtual address = 0x24 > > > > Likely you are using a NULL pointer as mutex. > > No, it is not NULL, the instruction I believe to have caused the fault is > "mtx_lock(&sc->brg_rx.comp_mp)". > "&sc->brg_rx.comp_mp" can't be NULL, AFAIK. > You can have a look at my code, it's at > http://yoshiyo.ath.cx/seb/download/prism54u-bsd-20050326.tar.bz2 > See the "bottom halves" section of usb_transport.c Havn't looked at your code yet, but the panic is by accessing a memory location near address 0, so it's very likely that you are accesing a structure member from a NULL pointer. A stack trace from kernel debugger should easily tell you which function made the access - with the instruction offset inside the function you can also find out the excat instruction causing this. Or you could trigger a crash dump and analyse it. > > If you want your driver GIANT free that's fine, but don't forget > > that calling USB layer requires you to acquire GIANT first. > > You mean I must hold Giant every time I call any USB function ? I've never > seen any driver doing this... Yes - holding GIANT ist required. You don't see this because currently all USB drivers are already entered with GIANT held. .d_flags conating D_NEEDGIANT will enable this for access from userland via devnodes. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de