[Bug 194884] New: [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Fri Nov 7 19:08:35 UTC 2014
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194884
Bug ID: 194884
Summary: [acpi] Asus UX31E USB hangs during suspend, due to
putting the USB controllers into D3 state
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: adrian at freebsd.org
The laptop won't suspend with the USB drivers (ehci, xhci) loaded.
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.
But then:
ehci0 pnpinfo vendor=0x8086 device=0x1c26 subvendor=0x1043
subdevice=0x1427 class=0x0c0320 at slot=29 function=0 handle=\_SB_.PCI0.EHC1
ehci0 at 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.
However, we are actually transitioning it into D3. I don't have a bootverbose
output here, but just assume we are.
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.
So, jhb@ asked me to add some debugging. Which I did, and I got this:
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
acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP02: dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP02: now dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP02: dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP02: 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.RP04: dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP04: now dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=3
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=3
uhub0: at usbus0, port 1, addr 1 (disconnected)
ugen0.2: <vendor 0x8087> at usbus0 (disconnected)
uhub1: at uhub0, port 1, addr 2 (disconnected)
ugen0.3: <Azurewave> at usbus0 (disconnected)
ugen0.4: <Generic> at usbus0 (disconnected)
ugen0.5: <Atheros Communications> at usbus0 (disconnected)
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: dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=0
info: [drm] Enabling RC6 states: RC6 off, RC6p off, RC6pp off
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP02: dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0.RP02: now dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: dstate=0
acpi_device_pwr_for_sleep: \134_SB_.PCI0: now dstate=0
uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
uhub_attach: Turning port 1 power on
uhub_attach: Turning port 2 power on
uhub0: 2 ports with 2 removable, self powered
ugen0.2: <vendor 0x8087> at usbus0
uhub1: <vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2> on
usbus0
uhub_attach: Turning port 1 power on
uhub_attach: Turning port 2 power on
uhub_attach: Turning port 3 power on
uhub_attach: Turning port 4 power on
uhub_attach: Turning port 5 power on
uhub_attach: Turning port 6 power on
uhub_attach: Turning port 7 power on
uhub_attach: Turning port 8 power on
uhub1: 8 ports with 8 removable, self powered
ugen0.3: <Azurewave> at usbus0
ugen0.4: <Generic> at usbus0
ugen0.5: <Atheros Communications> at usbus0
These printf()s are in acpi_device_pwr_for_sleep(), printing out the
acpi_name(handle) for the handle we're doing the lookup on. It turns out that
'dev' here is the underlying bus, not the device it's attached to. So, all
these lookups are for PCIx, not the leaf devices - and it never sees the EHC*
nodes.
So I'm not sure what to do here. Should acpi_device_pwr_for_sleep() be being
called for leaf nodes rather than just the busses?
As a side note - I think the xhci controller does the same thing, but I'm going
to worry about that particular problem -after- we solve the ehci problem.
The full files can be found at http://people.freebsd.org/~adrian/asus_zenbook/
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list