From owner-freebsd-usb@FreeBSD.ORG Thu Sep 11 20:32:28 2008 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BAC11065686 for ; Thu, 11 Sep 2008 20:32:28 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id 29DFF8FC1C for ; Thu, 11 Sep 2008 20:32:27 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7ccf.q.ppp-pool.de [89.53.124.207]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 9511C128844; Thu, 11 Sep 2008 22:32:16 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id 7A2EB2E90F; Thu, 11 Sep 2008 22:29:36 +0200 (CEST) Message-ID: <48C98043.3040807@vwsoft.com> Date: Thu, 11 Sep 2008 22:32:03 +0200 From: Volker User-Agent: Thunderbird 2.0.0.16 (X11/20080727) MIME-Version: 1.0 To: Julian Elischer References: <20080819211814.6CD685B4D@mail.bitblocks.com> <48B0EA50.2090105@mawer.org> <48B3299F.5080101@vwsoft.com> <200809111013.23994.hselasky@c2i.net> <48C97ACA.70307@vwsoft.com> <48C97C04.6030603@elischer.org> In-Reply-To: <48C97C04.6030603@elischer.org> X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MailScanner-NULL-Check: 1221769786.15703@XtbLvj9LxVqJkIFu02wOlw X-MailScanner-ID: 7A2EB2E90F.C52B1 X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: Antony Mawer , freebsd-usb@freebsd.org Subject: usbdrain problem (was: Re: "legacy" usb stack fixes) X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2008 20:32:28 -0000 On 09/11/08 22:13, Julian Elischer wrote: > Volker wrote: >> On 09/11/08 10:13, Hans Petter Selasky wrote: >>> On Monday 25 August 2008, Volker wrote: >>>> Anyway, I've already had those crashes even with the "new" usb stack >>>> (but it doesn't happen everytime - YMMV). >>>> >>> Hi, >>> >>> I also see crashes with my new stuff and the umass driver when the >>> USB device is un-plugged too early. The backtraces I've got so far >>> does not indicate a USB problem, though .... >>> >>> --HPS >>> >> >> // dropped current@ from CC >> >> Hans Petter, >> >> the device unplug problem is not just with usb, but these devices are >> the most frequent unplugged devices so far. >> >> Early this week, I discovered a new problem. I've fetched fresh RELENG_7 >> sources, patched your usb stack in and recompiled kernel (using usb, not >> usb2). >> >> I've seen situations with a process holding open file descriptors for a >> ugen device being killed but a thread was still hanging in "usbdrain" >> state (sleeping on a mutex for draining). The process is still holding >> open file descriptors (I see output from ``fstat | grep ugen'' listing >> the already killed process), even while the process itself is already >> killed and not in the process list as a whole. >> >> Only a thread of that former process can be seen by ``ps -alxcH'', but >> it can't be killed. > > what is the thread waiting on? I have no idea as I was unable to find time to debug this. The kill signal may come in the middle of a transfer (or even not - ENOTIME for deep inspection). While the process is on the usbdrain lock, I'm unable to attach gdb to it (gdb complains about 'no such process' for the pid). Debugging the ugen driver is hard as I don't have a serial debugger at work (and I don't feel that comfortable with DDB at the console, but will try to look at that, also ;). >From looking at the sources, the ugen driver is seeing the transfer flag being set before closing the device, sets the drain flag and sleeping on the usbdrain mutex. It never wakes up. Without finding time to debug this (too much interrupts at work), I thought I might try to set a timeout value for the mutex and see if I can find a deal out of that situation. Hopefully I'll find some time tomorrow for that problem, as it's causing a lot of trouble. Again, this is for the hps stack, not what the old $subject said (changed now). Volker