Quoting Alexander Motin <m...@freebsd.org> (from Tue, 02 Nov 2010
Alexander Leidinger wrote:
Quoting Hans Petter Selasky <hsela...@freebsd.org> (from Tue, 2 Nov 2010
If you dump all threads in this state I think you will see that USB is
# 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.
# procstat -kka | grep umass_detach
grabbing the SX-lock associated with serialisation. Because
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?
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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"