From owner-freebsd-usb@FreeBSD.ORG Sat Mar 26 17:36:31 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 BC58016A4CE for ; Sat, 26 Mar 2005 17:36:31 +0000 (GMT) Received: from md1.swissinfo.org (md1.swissinfo.org [146.159.4.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD1F543D41 for ; Sat, 26 Mar 2005 17:36:30 +0000 (GMT) (envelope-from sebastien.b@swissinfo.org) Received: from mail.swissinfo.org ([194.6.181.33]) by md1.swissinfo.org (phad1.swissinfo.org [146.159.6.9]) (MDaemon.PRO.v7.2.1.R) with ESMTP id 30-md50000369906.msg for ; Sat, 26 Mar 2005 18:24:06 +0100 Received: from AAmiens-152-1-36-150.w83-198.abo.wanadoo.fr (83.198.35.150) by mail.swissinfo.org (7.0.020) (authenticated as sebastien.b) id 4153942002C7E583 for freebsd-usb@freebsd.org; Sat, 26 Mar 2005 15:58:20 +0100 From: Sebastien B To: freebsd-usb@freebsd.org Date: Sat, 26 Mar 2005 15:58:20 +0000 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503261558.21943.sebastien.b@swissinfo.org> X-Spam-Processed: phad1.swissinfo.org, Sat, 26 Mar 2005 18:24:06 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 194.6.181.33 X-Return-Path: sebastien.b@swissinfo.org X-MDaemon-Deliver-To: freebsd-usb@freebsd.org X-MDAV-Processed: phad1.swissinfo.org, Sat, 26 Mar 2005 18:36:14 +0100 Subject: 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 List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2005 17:36:31 -0000 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 ? 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 fault code = supervisor read, page not present instruction pointer = 0x8:0xc05fa002 stack pointer = 0x10:0xd4ca5c20 frame pointer = 0x10:0xd4ca5c48 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 9747 (swi8: dev_tx_bh+++*) 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. Thanks, Sebastien