usbconfig reset ugen4.2 hanging since an hour

[Alexander Leidinger]

Quoting Alexander Motin <mav at FreeBSD.org> (from Tue, 02 Nov 2010  
14:02:17 +0200):

> Alexander Leidinger wrote:
>>
>> Quoting Hans Petter Selasky <hselasky at freebsd.org> (from Tue, 2 Nov 2010
>> 10:36:41 +0100):

>>> If you dump all threads in this state I think you will see that USB is
>>> waiting
>>
>> # procstat -kk 29213
>>   PID    TID COMM             TDNAME           KSTACK
>> 29213 100291 usbconfig        -                mi_switch+0x188
>> sleepq_switch+0x13c sleepq_timedwait+0x40 _sleep+0x320 pause+0x30
>> usb_pause_mtx+0x94 usb_ioctl+0x171 devfs_ioctl_f+0x73 kern_ioctl+0x9d
>> ioctl+0xc5 syscallenter+0x1af syscall+0x34 Xint0x80_syscall+0x21
>>
>>> somewhere in umass_detach(), which is preventing the usbconfig reset from
>>
>> No umass_detach in there...
>
> umass_detach() (if there) should be in some other thread.

Not here:
---snip---
# procstat -kka | grep umass_detach

---snip---

>>> grabbing the SX-lock associated with serialisation. Because
>>> umass_detach() is
>>> not returning we are stuck.
>>
>> And there is no way to use some kind of timeout for cases which cause
>> problem reports (like umass_detach() and maybe this one)? I could
>> imagine several possibilities: usbconfig tries a trylock first (maybe
>> several times) and if it does not succeed in a specified timeperiode, it
>> returns an error. Adidtionally there is maybe the possibility to
>> determine if a command did not finish in a given timeperiode and print
>> out a warning message (syslog) to have an indication, that somthing is
>> not in a good condition.
>
> Not sure what should it give. We should track the real problem, not the
> consequences. Possible reason could be that due to some error umass/CAM
> leaked some references, which made impossible to destroy CAM bus on
> stick disconnection. But to diagnose it we need much more info.

Something I could provide? Some kdb magic I could copy&paste?

Bye,
Alexander.

-- 
Phosflink, v.:
	To flick a bulb on and off when it burns out (as if, somehow,
	that will bring it back to life).
		-- Rich Hall & Friends, "Sniglets"

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137