Date: Tue, 02 Nov 2010 12:24:10 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Alexander Motin <mav@FreeBSD.org> Cc: Hans Petter Selasky <hselasky@FreeBSD.org>, freebsd-usb@FreeBSD.org Subject: Re: usbconfig reset ugen4.2 hanging since an hour Message-ID: <20101102122410.1227532bno09pfs4@webmail.leidinger.net> In-Reply-To: <4CCFFDC9.1040002@FreeBSD.org> References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> <4CCFFDC9.1040002@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Alexander Motin <mav@FreeBSD.org> (from Tue, 02 Nov 2010 14:02:17 +0200): > Alexander Leidinger wrote: >> >> Quoting Hans Petter Selasky <hselasky@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101102122410.1227532bno09pfs4>