From owner-freebsd-acpi@FreeBSD.ORG Sat Nov 8 17:25:16 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABF1D682; Sat, 8 Nov 2014 17:25:16 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1F56F7A4; Sat, 8 Nov 2014 17:25:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id sA8HP5li046557; Sun, 9 Nov 2014 04:25:05 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 9 Nov 2014 04:25:05 +1100 (EST) From: Ian Smith To: Adrian Chadd Subject: Re: [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state In-Reply-To: Message-ID: <20141109034218.X31139@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Nov 2014 17:25:16 -0000 On Fri, 7 Nov 2014 19:08:58 +0000, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194884 > > Adrian Chadd changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Assignee|freebsd-bugs@FreeBSD.org |freebsd-acpi@FreeBSD.org Not loving bugzilla all that much. I'm going to reply here, after reformatting from cut'n'paste; do what thou wilt if anything's useful. > The laptop won't suspend with the USB drivers (ehci, xhci) loaded. Won't suspend, or won't resume? > Suspend bounce works fine - everything gets powered down fine, then > comes back up. > > Unloading the USB drivers fixes the problem, but that's hiding the > underlying causes - the trick is the transition of the USB ports into > D3. > The ACPI BIOS has this: > > Device (EHC1) > { > Name (_ADR, 0x001D0000) // _ADR: Address > OperationRegion (PWKE, PCI_Config, 0x62, 0x04) > Field (PWKE, DWordAcc, NoLock, Preserve) > { > , 1, > PWUC, 8 > } > > Method (_PSW, 1, NotSerialized) // _PSW: Power State Wake > { > If (Arg0) > { > Store (Ones, PWUC) /* \_SB_.PCI0.EHC1.PWUC */ > } > Else > { > Store (0x00, PWUC) /* \_SB_.PCI0.EHC1.PWUC */ > } > } > > Method (_S3D, 0, NotSerialized) // _S3D: S3 Device State > { > Return (0x02) > } > > Method (_S4D, 0, NotSerialized) // _S4D: S4 Device State > { > Return (0x02) > } > > .. so, we should be trying to put it into D2, not D3. I can't figure this. Methods _S3D and _S4D aren't apparently referenced or called anywhere else?, and there's nothing similar (I could spot) for EHC2. Are you assuming 0x02 here is the requested power state? How? If so, even if it wanted to leave some? power on during suspend, what good would that do in S4 (hibernate/STDisk) when the power is turned right off? - not that we support that, but W*s and maybe Linux do .. > But then: > > ehci0 pnpinfo vendor=0x8086 device=0x1c26 subvendor=0x1043 > subdevice=0x1427 class=0x0c0320 at slot=29 function=0 > handle=\_SB_.PCI0.EHC1 > > ehci0@pci0:0:29:0: class=0x0c0320 card=0x14271043 chip=0x1c268086 > rev=0x05 hdr=0x00 > vendor = 'Intel Corporation' > device = '6 Series/C200 Series Chipset Family USB Enhanced Host Controller' > class = serial bus > subclass = USB > cap 01[50] = powerspec 2 supports D0 D3 current D0 > cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 > cap 13[98] = PCI Advanced Features: FLR TP > > .. we shouldn't be putting it into D2, because the device doesn't > support it. Right. Or at least, so we detect .. > However, we are actually transitioning it into D3. I don't have a > bootverbose output here, but just assume we are. [..] > The full files can be found at > http://people.freebsd.org/~adrian/asus_zenbook/ Actually a verbose boot - without the extra debugging - or with, if it's properly interleaved with ordinary verbose stuff - might be handy, even if it won't survive a suspend/resume, when it could be _really_ handy. > If I leave the driver loaded but I disable the suspend-to-d3 option, > things suspend/resume fine. > > If I set the unconfigured-devices-get-d3 option and unload the usb > modules, then the ehci controller ends up at d3 when I unload it. > Then if I suspend, the laptop hangs. Sorry, where are those options set? Is that what they're called? Probably not helpful, but have you considered changing the ASL? The only reason I can think of for leaving anything in D2 state is if that provides external power for phone charging and the like? My X200 has a BIOS option for that; pretty sure I turned it off. Does yours? cheers, Ian