>> I need the acpi trace log before _PTS to see what kind of thermal
>> related methods got called.
>
>Alas, I've included all the dmesg's.
I need the full log for S3 suspend failure not just snippets.
Please attach it on bugzilla.kernel.org
The log for S3 suspend success cannot help me to track down.
>
>Below is the script that I use to enter S3 sleep. It unloads rid of
>troublesome modules and stop services that don't sleep well. Then
>(for debugging) it sends the kernel version and boot parameters across
>the serial console (the @@@@ SLEEP line), raises the debug level to
>0x1F, does a sync (in case the sleep hangs, since this is my
>production machine), and then enters mem sleep.
>
>So nothing in it should trigger any thermal methods; except that I
>usually have the THM2 trip point raised to 45C with a polling time of
>100 seconds. So once in a while a thermal poll will happen sleep is
>being set up. I am not sure whether it would be reported in the
>dmesgs if it happened; but the S3 failure happens much more often than
>such a thermal polling would happen, so I doubt the S3 failure
>requires a thermal poll.
Could you try to mute thermal poll?
> Could you try to mute thermal poll?
Done. The sleep.sh script now has
echo 0 > /proc/acpi/thermal_zone/THM2/polling_frequency
echo 0 > /proc/acpi/thermal_zone/THM0/polling_frequency
sleep 1
> I need the full log for S3 suspend failure not just snippets.
> Please attach it on bugzilla.kernel.org
Done.
> The log for S3 suspend success cannot help me to track down.
For completeness, I didn't excise that portion of the log. It's not
many lines, plus it doesn't make it harder to find the failing
portion: The suspend failure happens after the second "@@@@ SLEEP" in
the log.
Should I turn on more acpi_debug_level debugging?
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.