From owner-freebsd-usb@FreeBSD.ORG Tue Nov 2 10:01:44 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 B0EA4106564A; Tue, 2 Nov 2010 10:01:44 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id 575858FC13; Tue, 2 Nov 2010 10:01:44 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A76A.dip.t-dialin.net [87.179.167.106]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id DBFE484400D; Tue, 2 Nov 2010 11:01:40 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id BC9FC144A; Tue, 2 Nov 2010 11:01:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1288692097; bh=CvQW7b80P98MMlY/PgwI+SeXDvRY+0dNH4l7JwhJkpk=; h=Message-ID:Date:From:To:Cc:Subject:References:In-Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding; b=d19eHTWV9Kz8mX/WqIF63du1L1tts5xJ6jGe8Dtb42cjRa+pywpDJBW7nTjkzJxYt ZvMumOVk7ltOdLYGDoMyhcwQqDF3zeBdkV/yktgfXA/Yv14MWJJXSaaAB0qKoETy1n KSD5YB2AdRhBimTYqKGIsZMd9xkkg0SOvdAxYYnRoZM2bVWG8O6Wp4g2TPrJD4W/Lb BbkZ7/68/ccxIuiZ/MEsWYOUSud5DduNiOusTw+meh0u5LPrtHjTCIVrFlT6t7bZkp j0s9Sl+m4KnYz4F9OiNSc5B/RJ0joSFNQvj5y0OnQeXP+24GXS9WF+ewohOVmftwjz 8cxqGxY18KsbA== Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oA2A1a54056232; Tue, 2 Nov 2010 11:01:36 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Tue, 02 Nov 2010 11:01:34 +0100 Message-ID: <20101102110134.53027bx6btjokpgc@webmail.leidinger.net> Date: Tue, 02 Nov 2010 11:01:34 +0100 From: Alexander Leidinger To: Hans Petter Selasky References: <20101102103208.45064dxs60sp833w@webmail.leidinger.net> <201011021036.41617.hselasky@freebsd.org> In-Reply-To: <201011021036.41617.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: DBFE484400D.A6C28 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.854, required 6, autolearn=disabled, ALL_TRUSTED -1.00, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, J_CHICKENPOX_24 0.60, J_CHICKENPOX_32 0.60, J_CHICKENPOX_34 0.60, TW_UH 0.08, TW_XD 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1289296901.91698@U+eXD96+huxJ8aK+glXuLA X-EBL-Spam-Status: No Cc: Alexander Motin , 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 10:01:44 -0000 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... > 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. Bye, Alexander. -- I hate small towns because once you've seen the cannon in the park there's nothing else to do. -- Lenny Bruce http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137