Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 07 Nov 2014 19:08:35 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 194884] New: [acpi] Asus UX31E USB hangs during suspend, due to putting the USB controllers into D3 state
Message-ID:  <bug-194884-8@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
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@FreeBSD.org
          Reporter: adrian@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@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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-194884-8>