Date: Sat, 26 Mar 2005 19:13:18 +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: <20050326181317.GE14532@cicely12.cicely.de> In-Reply-To: <200503261558.21943.sebastien.b@swissinfo.org> References: <200503261558.21943.sebastien.b@swissinfo.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 26, 2005 at 03:58:20PM +0000, Sebastien B wrote: > Hello, > I'm trying to wait for an USB device to send me data over a bulk pipe. So I > set up the pipe and send an xfer to it with a callback. The callback function > then triggers a software interrupt handler which locks a mutex (required for > cv_broadcast()), calls cv_broadcast() to unblock threads waiting for the data > transfer and then unlocks the mutex. > Is it the proper way to do, or is there a simpler solution ? This is OK, but often just calling usbd_bulk_transfer for sync transfers if enough. > 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. > Other device drivers use wakeup() instead of cv_broadcast() (therefore there > is no need for software interrupt handlers, since wakeup() won't block) and > rely on the spl() function family to avoid race conditions. However, > according to the manual page, spl() is obsolete. They rely on GIANT - most of USB is under GIANT right now. spl calls are nop under 5.x and 6.x, but are still in the code to reduce diffs with 4.x and other BSDs. If you want your driver GIANT free that's fine, but don't forget that calling USB layer requires you to acquire GIANT first. -- 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?20050326181317.GE14532>