Thanks for your debug information.
>
>> 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
Hmm, could you file dmesges with tmermal module loaded and
unloaded?
>
>> I need the full log for S3 suspend failure not just snippets.
>> Please attach it on bugzilla.kernel.org
>
>Done.
I saw this acpi_debug=0xffffffff.
I used to used to use acpi_debug_layer=0x10 acpi_debug_level=0x10
Could you try that?
> Hmm, could you file dmesgs with thermal module loaded and unloaded?
Filed at bugzilla.
> I saw this acpi_debug=0xffffffff.
Sorry, it's a legacy from trying to debug #5112, and I've removed it
for getting the above dmesgs. I'm not even sure what that option does
since it's not documented in the kernel-parameters.txt, but it does
increase the amount of debugging info.
> I used to used to use acpi_debug_layer=0x10 acpi_debug_level=0x10
> Could you try that?
For the above dmesgs I booted with acpi_dbg_level=0x10
acpi_dbg_layer=0x10 and then did two sleep-wake cycles with no thermal
module (both went fine), then one cycle with the thermal module loaded
(went fine), and then the usual failing second sleep with the thermal
module still loaded. The sleep-wake cycles themselves (i.e. once the
system booted) were done with acpi_debug_level=0x1F rather than the
0x10 boot value.
Let me know if there's a different permutation of debug options that I
should try. I wasn't sure whether you meant that I should leave all
the debug values at 0x10. Or whether I should still include
acpi_debug=0xffffffff on top of the other options.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.