Date: Tue, 2 Nov 2010 22:25:44 +0000 From: Alexander Best <arundel@freebsd.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Alexander Motin <mav@FreeBSD.org>, Hans Petter Selasky <hselasky@FreeBSD.org>, freebsd-usb@FreeBSD.org Subject: Re: usbconfig reset ugen4.2 hanging since an hour Message-ID: <20101102222544.GA30447@freebsd.org> In-Reply-To: <20101102122410.1227532bno09pfs4@webmail.leidinger.net> References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> <4CCFFDC9.1040002@FreeBSD.org> <20101102122410.1227532bno09pfs4@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue Nov 2 10, Alexander Leidinger wrote: > 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? i believe you're experiencing the same i issue i have [1]. cheers. alex [1] http://www.mail-archive.com/freebsd-usb@freebsd.org/msg07599.html > > 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 -- a13x
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101102222544.GA30447>