Date: Sat, 8 Nov 2014 09:47:29 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Ian Smith <smithi@nimnet.asn.au> Cc: "freebsd-acpi@freebsd.org" <freebsd-acpi@freebsd.org> Subject: Re: [Bug 194884] [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state Message-ID: <CAJ-VmonuO6wL84kPXjApRR6pz2v3s1kfUogcq9n3cX_ztbdjgQ@mail.gmail.com> In-Reply-To: <20141109034218.X31139@sola.nimnet.asn.au> References: <bug-194884-13733@https.bugs.freebsd.org/bugzilla/> <bug-194884-13733-T6mLK4Pufn@https.bugs.freebsd.org/bugzilla/> <20141109034218.X31139@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On 8 November 2014 09:25, Ian Smith <smithi@nimnet.asn.au> wrote: > 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 <adrian@freebsd.org> 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? Won't suspend - it hangs before it powers everything off. > > 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? It's apparently in the spec and we do check for it - grep for _S%dD in sys/dev/acpica/ . > 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 .. I think it likely needs to be powered on during the transition to S3/S4, but then for S4 you can just yank the power. I doubt the USB controllers need to be on if the rest of th machine is powered off. > > 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 .. Right, but we don't. If you check the .txt files, we are actually probing the bus itself to find the _SxD node, when apparently this ACPI table has it in the device. ie: acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP01: dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP01: now dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3 acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3 ath_hal_reg_write: reg=0x000000a0, val=0x00000000, pm=1 ath_hal_reg_write: reg=0x000000ac, val=0x00000000, pm=1 .. it's actually checking PCI0 all the time, including when it's trying to power down the atheros NIC. That's what's confusing about all of this. > > 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. The verbose boot + suspend just says "going to D3" for all the devices. :-) > > 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? hw.pci.do_power_nodriver: 0 hw.pci.do_power_resume: 1 hw.pci.do_power_suspend: 1 > 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? Sure, but please keep in mind that it may also keep it in D2 state so some external device can wake the laptop up upon some event. And even if you don't /want/ that, the BIOS ACPI / SMI code may be expecting the device to actually be active and reachable when the transition to S3/S4 occurs. We can't really control that. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonuO6wL84kPXjApRR6pz2v3s1kfUogcq9n3cX_ztbdjgQ>