Created attachment 72904 [details] dmesg with touchpad failing after 1st s2ram, working after 2nd and 3rd On HP dv5-1250eo laptop the touch pad doesn't work after s2ram. Kernel 3.3 works, 3.4-rc1 does not. The dmesg contains these (see the full log attached): ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20120320/evregion-501) ACPI Error: Method parse/execution failed [\_SB_.WMID.GDKS] (Node ffff88013b03e550), AE_TIME (20120320/psparse-536) ACPI Error: Method parse/execution failed [\_SB_.WMID.HWMC] (Node ffff88013b03e370), AE_TIME (20120320/psparse-536) ACPI Error: Method parse/execution failed [\_SB_.WMID.WMAD] (Node ffff88013b03e4d8), AE_TIME (20120320/psparse-536) ACPI Exception: AE_TIME, Returned by Handler for [EmbeddedControl] (20120320/evregion-501) ACPI Error: Method parse/execution failed [\_SB_.WMID.GDKS] (Node ffff88013b03e550), AE_TIME (20120320/psparse-536) ACPI Error: Method parse/execution failed [\_SB_.WMID.HWMC] (Node ffff88013b03e370), AE_TIME (20120320/psparse-536) ACPI Error: Method parse/execution failed [\_SB_.WMID.WMAD] (Node ffff88013b03e4d8), AE_TIME (20120320/psparse-536) PM: resume of devices complete after 17388.013 msecs i8042: Can't write CTR while closing AUX port i8042: Can't reactivate AUX port At this state, the laptop's touch pad doesn't work. Also the capslock led doesn't work, but otherwise the keyboard seems to work. If I try to reboot at this phase, the machine will hang just before actually rebooting. At least once the end of the printout contained Restarting system. machine restart ACPI MEMORY or I/O RESET_REG. ACPI Error: Unsupported register bit width: 0x0 (20120320/hwregs-121) ACPI MEMORY or I/O RESET_REG. ACPI Error: Unsupported register bit width: 0x0 (20120320/hwregs-121) although the ACPI messages don't appear with every hang. It seems the touchpad comes back to live after a second s2ram. The attached dmesg log spans three suspends with PCI and i8042 debug options turned on, with the touchpad failing only between the first and second s2ram. I bisected this problem to the following commit. Reverting this on top of 3.4.0-rc2 (3.4.0-rc2-CUST-00269-g4166fb6 to be exact) fixes the problem for me. 26f41062f28de65e11d3cf353e52d0be73442be1 is the first bad commit commit 26f41062f28de65e11d3cf353e52d0be73442be1 Author: Kay, Allen M <allen.m.kay@intel.com> Date: Thu Jan 26 10:25:53 2012 -0800 PCI: check for pci bar restore completion and retry On some OEM systems, pci_restore_state() is called while FLR has not yet completed. As a result, PCI BAR register restore is not successful. This fix reads back the restored value and compares it with saved value and re-tries 10 times before giving up. Signed-off-by: Jean Guyader <jean.guyader@eu.citrix.com> Signed-off-by: Eric Chanudet <eric.chanudet@citrix.com> Signed-off-by: Allen Kay <allen.m.kay@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> :040000 040000 c7fcf515fdc69ecaa6698f3a6b49a8f14dada300 ea3c0b306e860e186838e9956cb3b4c29704bcb3 M drivers
Created attachment 72905 [details] dmesg of 3.4.0-rc2+ with 26f41062f28 reverted dmesg with the commit 26f41062f28de65e11d3cf353e52d0be73442be1 reverted, one s2ram, touchpad works
I should add that this machine suffers from https://bugzilla.kernel.org/show_bug.cgi?id=35452 ("Devices not available after resume from suspend to RAM") which explains a lot of the noise in the logs.
Is the problem in comment #2 independent of whether or not the problematic commit is reverted?
Yes, they are independent. (My part of) Bug #35452 was reported with 2.6.39-rc7, but that problem existed before and still does. Commit 26f41062f28de65e11d3cf353e52d0be73442be1 was merged in mainline for v3.4-rc1 on Fri Mar 23 14:02:12 2012 -0700. ---- I did some testing today removing pcie_aspm=force from kernel parameters. Without it I get this message: pci 0000:08:00.0: disabling ASPM on pre-1.1 PCIe device. You can enable it with 'pcie_aspm=force' Unfortunately, having/not having the parameter makes no difference to any of the problems. The touchpad seemed to survive without the pcie_aspm=force option and without X (in single user mode) a s2ram in one test run only, but it failed when I tried to confirm by testing again.
I posted a patch to try to the lists: https://lkml.org/lkml/2012/4/14/214
Fixed by ebfc5b802fa76baeb4371311ff9fc27a2258d90d "PCI: Fix regression in pci_restore_state(), v3" and a6cb9ee7cabe68002c3f2ab07224ea27d2617cf1 "PCI: Retry BARs restoration for Type 0 headers only" around v3.4-rc3. Hopefully the OEM systems fixed by 26f41062f28d are still working, too.