Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 11 Sep 2008 22:32:03 +0200
From:      Volker <volker@vwsoft.com>
To:        Julian Elischer <julian@elischer.org>
Cc:        Antony Mawer <fbsd-current@mawer.org>, freebsd-usb@freebsd.org
Subject:   usbdrain problem (was: Re: "legacy" usb stack fixes)
Message-ID:  <48C98043.3040807@vwsoft.com>
In-Reply-To: <48C97C04.6030603@elischer.org>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48C98043.3040807>