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>