Date: Sun, 27 Mar 2005 00:32:15 +0100 From: Bernd Walter <ticso@cicely12.cicely.de> To: Sebastien B <sebastien.b@swissinfo.org> Cc: freebsd-usb@freebsd.org Subject: Re: What's the right way to wait for an USB transfer to complete ? Message-ID: <20050326233214.GM14532@cicely12.cicely.de> In-Reply-To: <200503262158.32320.sebastien.b@swissinfo.org> References: <200503261558.21943.sebastien.b@swissinfo.org> <20050326181317.GE14532@cicely12.cicely.de> <200503262158.32320.sebastien.b@swissinfo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050326233214.GM14532>