On 01/04/2011 11:57 PM, Rafael J. Wysocki wrote: > On Tuesday, January 04, 2011, Jiri Slaby wrote: >> On 01/04/2011 02:40 PM, Jiri Slaby wrote: >>> On 12/24/2010 01:58 AM, akpm@xxxxxxxxxxxxxxxxxxxx wrote: >>>> The mm-of-the-moment snapshot 2010-12-23-16-58 has been uploaded to >>> >>> Hi, this kernel regresses with respect to suspend to ram in comparison >>> with mmotm 2010-12-16-14-56. >>> >>> This is OK: >>> echo devices > /sys/power/pm_test >>> pm-suspend >>> This hangs at suspend phase: >>> echo platform > /sys/power/pm_test >>> pm-suspend > > Hmm. So it looks like _PTS hangs? No _PST here :). >>> Note that this kernel is based on next-20101221. Should I try newer (and >>> clean) -next? >> >> Ok, bisected down to: >> 16dc39c98a6ca56a27f22f7ac6731d8223237a2e is first bad commit >> commit 16dc39c98a6ca56a27f22f7ac6731d8223237a2e ... >> Revert of that patch fixes the problem. > > Can you send a dmesg output and acpidump output from the failing system, please? Here they are: http://www.fi.muni.cz/~xslaby/sklad/panics/dmesg-no-susp.txt http://www.fi.muni.cz/~xslaby/sklad/adump.txt They are captured from the mmotm minus 16dc39c98a6ca56 if that's OK? Ignore the BUG there, it's caused by qemu and fixed in later -next. regards, -- js -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
