From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 11:02:32 2010 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 657AA106566B; Tue, 2 Nov 2010 11:02:32 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id AD3888FC12; Tue, 2 Nov 2010 11:02:31 +0000 (UTC) Received: by bwz3 with SMTP id 3so5481779bwz.13 for ; Tue, 02 Nov 2010 04:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=p1ulE2eYysFcEgbVLHl6lJPkw35PwlBGbT+e2n+dtGw=; b=u7EOugjTqE7gnepAfO4RkZUpTGC7349ydOjse5ZkoMvk6Ft8bZ54DE1IbkFkLCIULW 3Adl982RWDMzA9KdWQwgRZo2YndTe2a6DLrFdOX1bSv4ubP4EKzLCqrwCTxsW4mrkJat SkZ2bY4HEymQ9xL31j8I5fhovSFPOmymPzcBc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=WPxC+epSl1y+NVED1CIK+RNakt+8UvfY/wyLvfLHw4awSvD92EP1pfKH1svSh2shuU ymrldXeFi+Yq9Wb+MrocD/pjJMCV1mdzDE451N/rqC0BAbZqhZWwFS4I8OsFouoV4dIc aYNybJzxTCXnvfSPivhcKHKHUBVSZdNdglaBA= Received: by 10.204.123.14 with SMTP id n14mr3735955bkr.33.1288695750699; Tue, 02 Nov 2010 04:02:30 -0700 (PDT) Received: from mavbook2.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id f21sm4440319bkf.12.2010.11.02.04.02.28 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 04:02:29 -0700 (PDT) Sender: Alexander Motin Message-ID: <4CCFFDC9.1040002@FreeBSD.org> Date: Tue, 02 Nov 2010 14:02:17 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Alexander Leidinger References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> <201011021036.41617.hselasky@freebsd.org> <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> In-Reply-To: <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Hans Petter Selasky , freebsd-usb@freebsd.org Subject: Re: usbconfig reset ugen4.2 hanging since an hour X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2010 11:02:32 -0000 Alexander Leidinger wrote: > > Quoting Hans Petter Selasky (from Tue, 2 Nov 2010 > 10:36:41 +0100): > >> On Tuesday 02 November 2010 10:32:08 Alexander Leidinger wrote: >>> Hi, >>> >>> I have a memory stick which made problems (the stick is used as a ZFS >>> cache and it moaned about 8xxM write problems) in 9-current r214509. I >>> removed the device from the config, made a camcontrol reset all, >>> camcontrol rescan all (-> device disappeared), and then tried an >>> usbconfig reset ugen4.2 (relevant devlist part from before the call is >>> below). The usbconfig reset does not return to the shell. >>> >>> I do not know if the problem with the USB memory stick is related to >>> software or hardware. The stick survived just a weekend, I replaced it >>> because the old one showed similar problems after surviving about 9 >>> months... I updated -current just before the problems appeared (and >>> then again after a week or two), but I do not remember from which >>> revision of -current I was updating from. I will try to stress-test >>> the memory sticks on a 8.1 system so see if it is some software problem. >>> >>> The big question I have for now is: shouldn't there be some kind of >>> safety mechanism kicking in (timeout) with the usbconfig command (in >>> this case the reset)? >>> >>> devlist: >>> ---snip--- >>> ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH >>> (480Mbps) pwr=SAVE >>> ugen4.2: at usbus4, cfg=0 md=HOST spd=HIGH >>> (480Mbps) pwr=ON >>> ---snip--- >>> >>> dmesg | grep -i usb: >>> ---snip--- >>> uhci0: port 0xdc00-0xdc1f >>> irq 16 at device 29.0 on pci0 >>> usbus0: on uhci0 >>> uhci1: port 0xe000-0xe01f >>> irq 19 at device 29.1 on pci0 >>> usbus1: on uhci1 >>> uhci2: port 0xe400-0xe41f >>> irq 18 at device 29.2 on pci0 >>> usbus2: on uhci2 >>> uhci3: port 0xe800-0xe81f >>> irq 16 at device 29.3 on pci0 >>> usbus3: on uhci3 >>> ehci0: mem >>> 0xfe77fc00-0xfe77ffff irq 23 at device 29.7 on pci0 >>> usbus4: EHCI version 1.0 >>> usbus4: on ehci0 >>> usbus0: 12Mbps Full Speed USB v1.0 >>> usbus1: 12Mbps Full Speed USB v1.0 >>> usbus2: 12Mbps Full Speed USB v1.0 >>> usbus3: 12Mbps Full Speed USB v1.0 >>> usbus4: 480Mbps High Speed USB v2.0 >>> ugen0.1: at usbus0 >>> uhub0: on usbus0 >>> ugen1.1: at usbus1 >>> uhub1: on usbus1 >>> ugen2.1: at usbus2 >>> uhub2: on usbus2 >>> ugen3.1: at usbus3 >>> uhub3: on usbus3 >>> ugen4.1: at usbus4 >>> uhub4: on usbus4 >>> Root mount waiting for: usbus4 >>> Root mount waiting for: usbus4 >>> Root mount waiting for: usbus4 >>> Root mount waiting for: usbus4 >>> ugen4.2: at usbus4 >>> umass0: on usbus4 >>> Root mount waiting for: usbus4 >>> pass3: Removable Direct Access SCSI-2 device >>> da0: Removable Direct Access SCSI-2 device >>> Root mount waiting for: usbus4 >>> ugen1.2: at usbus1 >>> ugen1.3: at usbus1 >>> ulpt0: >> 3> on usbus1 >>> ugen2.2: at usbus2 >>> uhub5: >> addr 2> on usbus2 >>> ugen2.3: at usbus2 >>> ukbd0: >> addr 3> on usbus2 >>> ugen2.4: at usbus2 >>> ums0: >> addr 4> on usbus2 >>> ---snip--- >> >> Hi, >> >> 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. >> 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. -- Alexander Motin