From owner-freebsd-usb@FreeBSD.ORG Tue Jun 17 15:44:57 2014 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 87974B72; Tue, 17 Jun 2014 15:44:57 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 64CC62D07; Tue, 17 Jun 2014 15:44:57 +0000 (UTC) Received: from [192.168.200.204] (c-50-131-5-126.hsd1.ca.comcast.net [50.131.5.126]) (using SSLv3 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 4934F1936DE; Tue, 17 Jun 2014 15:44:56 +0000 (UTC) Subject: Re: Lenovo T61, USB fails to power on after resume [solved?] From: Sean Bruno Reply-To: sbruno@freebsd.org To: Hans Petter Selasky In-Reply-To: <538E2E55.6000202@selasky.org> References: <1401807398.96874.3.camel@bruno> <538DEFD3.2010406@selasky.org> <1401813374.1114.0.camel@bruno> <538DFEA8.3090607@selasky.org> <1401820088.1120.9.camel@bruno> <538E292A.6090804@selasky.org> <1401826306.1282.2.camel@bruno> <538E2E55.6000202@selasky.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 17 Jun 2014 08:44:55 -0700 Message-ID: <1403019895.39699.5.camel@bruno> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 15:44:57 -0000 On Tue, 2014-06-03 at 22:21 +0200, Hans Petter Selasky wrote: > On 06/03/14 22:11, Sean Bruno wrote: > > On Tue, 2014-06-03 at 21:59 +0200, Hans Petter Selasky wrote: > >> On 06/03/14 20:28, Sean Bruno wrote: > >>> On Tue, 2014-06-03 at 18:58 +0200, Hans Petter Selasky wrote: > >>>> On 06/03/14 18:36, Sean Bruno wrote: > >>>>> On Tue, 2014-06-03 at 17:54 +0200, Hans Petter Selasky wrote: > >>>>>> On 06/03/14 16:56, Sean Bruno wrote: > >>>>>>> Noted that on resume, the USB ports on my T61 don't seem to be active. > >>>>>>> > >>>>>>> How should I go about debugging this? > >>>>>>> > >>>>>>> sean > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> The USB stack performs the same EHCI/OHCI/UHCI/XHCI reset which is does > >>>>>> during power on, when it resumes. Ensure the ports are powered. +5V. > >>>>>> Might be a BIOS/PCI/ACPI issue. > >>>>>> > >>>>>> --HPS > >>>>>> > >>>>> > >>>>> > >>>>> Is there something in the output of usbconfig that I can poke at to see > >>>>> if the hardware *thinks* it is powered on? > >>>>> > >>>>> sean > >>>>> > >>>>> > >>>> > >>>> Yes, there is the port status. > >>>> > >>>> struct usb_port_status { > >>>> uWord wPortStatus; > >>>> #define UPS_CURRENT_CONNECT_STATUS 0x0001 > >>>> #define UPS_PORT_ENABLED 0x0002 > >>>> #define UPS_SUSPEND 0x0004 > >>>> #define UPS_OVERCURRENT_INDICATOR 0x0008 > >>>> #define UPS_RESET 0x0010 > >>>> #define UPS_PORT_L1 0x0020 /* USB 2.0 only */ > >>>> /* The link-state bits are valid for Super-Speed USB HUBs */ > >>>> #define UPS_PORT_LINK_STATE_GET(x) (((x) >> 5) & 0xF) > >>>> #define UPS_PORT_LINK_STATE_SET(x) (((x) & 0xF) << 5) > >>>> #define UPS_PORT_LS_U0 0x00 > >>>> #define UPS_PORT_LS_U1 0x01 > >>>> #define UPS_PORT_LS_U2 0x02 > >>>> #define UPS_PORT_LS_U3 0x03 > >>>> #define UPS_PORT_LS_SS_DIS 0x04 > >>>> #define UPS_PORT_LS_RX_DET 0x05 > >>>> #define UPS_PORT_LS_SS_INA 0x06 > >>>> #define UPS_PORT_LS_POLL 0x07 > >>>> #define UPS_PORT_LS_RECOVER 0x08 > >>>> #define UPS_PORT_LS_HOT_RST 0x09 > >>>> #define UPS_PORT_LS_COMP_MODE 0x0A > >>>> #define UPS_PORT_LS_LOOPBACK 0x0B > >>>> #define UPS_PORT_LS_RESUME 0x0F > >>>> #define UPS_PORT_POWER 0x0100 > >>>> #define UPS_PORT_POWER_SS 0x0200 /* super-speed only */ > >>>> #define UPS_LOW_SPEED 0x0200 > >>>> #define UPS_HIGH_SPEED 0x0400 > >>>> #define UPS_OTHER_SPEED 0x0600 /* currently FreeBSD > >>>> specific */ > >>>> #define UPS_PORT_TEST 0x0800 > >>>> #define UPS_PORT_INDICATOR 0x1000 > >>>> #define UPS_PORT_MODE_DEVICE 0x8000 /* currently FreeBSD > >>>> specific */ > >>>> uWord wPortChange; > >>>> #define UPS_C_CONNECT_STATUS 0x0001 > >>>> #define UPS_C_PORT_ENABLED 0x0002 > >>>> #define UPS_C_SUSPEND 0x0004 > >>>> #define UPS_C_OVERCURRENT_INDICATOR 0x0008 > >>>> #define UPS_C_PORT_RESET 0x0010 > >>>> #define UPS_C_PORT_L1 0x0020 /* USB 2.0 only */ > >>>> #define UPS_C_BH_PORT_RESET 0x0020 /* USB 3.0 only */ > >>>> #define UPS_C_PORT_LINK_STATE 0x0040 > >>>> #define UPS_C_PORT_CONFIG_ERROR 0x0080 > >>>> } __packed; > >>>> > >>>> It is probed regularly by the UHUB driver and the port status is printed > >>>> in dmesg. > >>>> > >>>> Turn on like this: > >>>> > >>>> sysctl hw.usb.uhub.debug=16 > >>>> > >>>> By resetting the root HUB, you can write new power on bits: > >>>> > >>>> usbconfig -d X.1 set_config 255 > >>>> usbconfig -d X.1 set_config 0 > >>>> > >>>> --HPS > >>> > >>> Well, that's problematic. The USB tree looks like this normally: > >>> > >>> ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL > >>> (12Mbps) pwr=SAVE (0mA) > >>> ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL > >>> (12Mbps) pwr=SAVE (0mA) > >>> ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH > >>> (480Mbps) pwr=SAVE (0mA) > >>> ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL > >>> (12Mbps) pwr=SAVE (0mA) > >>> ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL > >>> (12Mbps) pwr=SAVE (0mA) > >>> ugen5.1: at usbus5, cfg=0 md=HOST spd=FULL > >>> (12Mbps) pwr=SAVE (0mA) > >>> ugen6.1: at usbus6, cfg=0 md=HOST spd=HIGH > >>> (480Mbps) pwr=SAVE (0mA) > >>> ugen0.2: at usbus0, cfg=0 > >>> md=HOST spd=FULL (12Mbps) pwr=ON (100mA) > >>> > >>> > >>> But, on resume ... sometimes ... ugen0.1 is just flatout gone (along > >>> with the ugen0.2 device, obviously). This only seems to happen with > >>> various USB device plugged in (tried about 4 different make/model usb > >>> sticks and ext drives). > >>> > >>> So, resetting doesn't work as the device is literally gone. Thoughts? > >>> > >>> sean > >>> > >> > >> Setting hw.usb.debug=15 should give you some hints. Are you sure the PCI > >> device is still there after resume? > >> > >> --HPS > >> > > > > I did a pre/post resume pciconf -lv and I see no difference between the > > two. > > > > On initial resume, ugen0.1 appears to be there in usbconfig output, but > > trying to set_config on it, causes it to dissapear and causes usbconfig > > to hang: > > > > root@bruno:/home/sbruno # usbconfig -d 0.1 set_config 255 > > load: 0.36 cmd: usbconfig 1540 [UGONE] 4.19r 0.00u 0.00s 0% 2064k > > load: 0.36 cmd: usbconfig 1540 [UGONE] 5.00r 0.00u 0.00s 0% 2064k > > load: 0.36 cmd: usbconfig 1540 [UGONE] 5.16r 0.00u 0.00s 0% 2064k > > load: 0.36 cmd: usbconfig 1540 [UGONE] 5.35r 0.00u 0.00s 0% 2064k > > load: 0.36 cmd: usbconfig 1540 [UGONE] 5.51r 0.00u 0.00s 0% 2064k > > > > > > Hi, > > What kind of USB devices are attached? Are any of these USB devices > preventing detach? Could you check the USB threads using kgdb? > > --HPS > Btw, this appears to be solvable with a patch to acpi_ibm(4) from trasz: http://lists.freebsd.org/pipermail/freebsd-current/2014-June/050721.html