Hi,
Since 2.6.20 is out and nobody else seem to complain, I thought
it's time to ask --
>From kernel version 2.6.18 on my JVC XP731 (a centrino-based
subnotebook) would freeze when resuming from
echo -n mem > /sys/power/state
where it woke up flawlessly before. Turns out it did this because in
drivers/acpi/thermal.c, function acpi_thermal_resume, a call to
acpi_thermal_check was introduced (that's line 1415 in 2.6.20). The
lockup at resume time is deterministic, i.e., it is independent of
the actual temperature of the device(s).
Commenting it out results in a flawless wakeup (as does removing the
thermal module at suspend time).
Now, I have to admit I didn't investigate matters much further, but
still: acpi_thermal_check does quite a few rather fancy things, and
regardless if the freeze on resume is an issue of the JVC (as the
lack of other complaints suggests) or not -- is it absolutely
necessary to run it during resume, when things are a nightmare to
debug (which is one reason I didn't investigate further)? I for one
would appreciate if it were only called after the system is up and
running, when one could at least see what the kernel thinks it's
doing...
Disclaimer: I only have very shady ideas what's actually going on
with ACPI thermal management. If not calling acpi_thermal_check
actually significantly increases the likelihood of fried machines,
disregard all this as layman babble, and I'll just add thermal to the
list of modules that don't survive a suspend to RAM.
Cheers,
Markus
-
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
