On Wednesday, January 05, 2011, Jiri Slaby wrote:
> On 01/05/2011 11:39 PM, Rafael J. Wysocki wrote:
> > On Wednesday, January 05, 2011, Jiri Slaby wrote:
> >> 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 :).
> >
> > I really meant _PTS and yes, there is one and it does quite a lot of
> > interesting stuff.
>
> Yeah, I grepped for _PTS, but in a wrong file. My bad.
>
> > Are you able to collect serial console (or equivalent) logs from that machine?
>
> Unfortunately I don't have a second machine with serial port. What
> exactly you want to dig out of the logs? Will netconsole work at that phase?
I don't think so, the adapter will have been already suspended.
Hmm. I guess you can boot with no_console_suspend in the kernel command line
and use the video console to get some debug info. At this point we would like
to know where exactly it hangs, so you'd need to enable AML tracing in the
kernel and basically see what's printed last. :-)
Two more questions:
(1) Does the failing machine power off correctly with the kernel that fails to
suspend?
(2) Is the failing suspend behavior reproducible if you run
"echo disk > /sys/power/state" instead of "pm-suspend" in the platform test?
Rafael
--
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
