What's the right way to wait for an USB transfer to complete ?

[Bernd Walter]

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 at bwct.de                                  info at bwct.de