From owner-freebsd-usb@FreeBSD.ORG Fri Nov 5 14:42:11 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 2415C106564A; Fri, 5 Nov 2010 14:42:11 +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 762578FC19; Fri, 5 Nov 2010 14:42:10 +0000 (UTC) Received: from outgoing.leidinger.net (p57B3A3BC.dip.t-dialin.net [87.179.163.188]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 8877784400A; Fri, 5 Nov 2010 15:42:05 +0100 (CET) Received: from webmail.leidinger.net (unknown [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 52DA325F2; Fri, 5 Nov 2010 15:42:02 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id oA5Efv9u044085; Fri, 5 Nov 2010 15:41:57 +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; Fri, 05 Nov 2010 15:41:56 +0100 Message-ID: <20101105154156.12764ne6zf5rahs0@webmail.leidinger.net> Date: Fri, 05 Nov 2010 15:41:56 +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: 8877784400A.A64FC X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=3.228, required 6, autolearn=disabled, J_CHICKENPOX_24 0.60, J_CHICKENPOX_32 0.60, J_CHICKENPOX_34 0.60, RDNS_NONE 1.27, TW_UH 0.08, TW_XD 0.08) X-EBL-MailScanner-SpamScore: sss X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1289572926.37056@bbT0L77HQ6LPaBPgVBugBQ 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: Fri, 05 Nov 2010 14:42:11 -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 > somewhere in umass_detach(), which is preventing the usbconfig reset from > grabbing the SX-lock associated with serialisation. Because umass_detach() is > not returning we are stuck. I made some tests. I've used the initial stick in question on Solaris 10u9 (no ZFS errors for several postmark runs) and FreeBSD 9 (r214509, own zpool with only the stick, one postmark run and I get I/O errors -> any access to the stick hangs now due to 'failmode=wait'). On FreeBSD 9 as of r212247 I do not have problems with the second stick with which I experienced errors more quickly. I do not know yet if this is because of failed hardware, or because of a problem in the USB stack. As the first traces of this appeared after an update, I lean towards a regression... I will have a look at getting some time to update the older FreeBSD 9 system to something in between the working and not working version. Bye, Alexander. -- There must be at least 500,000,000 rats in the United States; of course, I never heard the story before. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137