The bug should not be closed though, since it's not fixed in Maverick yet. I've also opened a task for Lucid since the patch could be backported to benefit Acer users.
For kernel developers, here's the commit message:
ACPI: Store NVS state even when entering suspend to RAM
https://bugzilla.kernel.org/show_bug.cgi?id=13931 describes a bug where
a system fails to successfully resume after the second suspend. Maxim
Levitsky discovered that this could be rectified by forcibly saving
and restoring the ACPI non-volatile state. The spec indicates that this
is only required for S4, but testing the behaviour of Windows by adding
an ACPI NVS region to qemu's e820 map and registering a custom memory
read/write handler reveals that it's saved and restored even over suspend
to RAM. We should mimic that behaviour to avoid other broken platforms.
Cool, much thanks Maxim!
The bug should not be closed though, since it's not fixed in Maverick yet. I've also opened a task for Lucid since the patch could be backported to benefit Acer users.
For kernel developers, here's the commit message:
ACPI: Store NVS state even when entering suspend to RAM
https:/ /bugzilla. kernel. org/show_ bug.cgi? id=13931 describes a bug where
a system fails to successfully resume after the second suspend. Maxim
Levitsky discovered that this could be rectified by forcibly saving
and restoring the ACPI non-volatile state. The spec indicates that this
is only required for S4, but testing the behaviour of Windows by adding
an ACPI NVS region to qemu's e820 map and registering a custom memory
read/write handler reveals that it's saved and restored even over suspend
to RAM. We should mimic that behaviour to avoid other broken platforms.