[Maverick SRU][PATCH] Fix memcpy oops after multiple S4 cycles

Manoj Iyer manoj.iyer at canonical.com
Sat Jan 15 23:21:52 UTC 2011

That is just AWESOME!

On Sat, Jan 15, 2011 at 4:43 AM, Colin King <colin.king at canonical.com> wrote:
> From: Colin Ian King <colin.king at canonical.com>
> SRU Request:
> After repeated S4 cycles, a memcpy() Oops occurs in suspend_nvs_save.
> This error occurs because the ioremap of the NVS region fails, returning
> NULL and the subsequent memcpy() tries to copy to a NULL pointer,
> hence the oops.
> The ioremap fails because we run out of mappable regions. This is because
> suspend_nvs_save() is called twice during hibernation, and yet the
> unmapping via suspend_nvs_free() is only called once, hence we have a leak.
> Looking at create_image() in kernel/power/hibernate.c, we can see that we
> call the __acpi_pm_prepare() via arch_prepare_suspend() and this does the
> first call to suspend_nvs_save(). A little later on we call
> platform_pre_snapshot() which calls acpi_hibernation_pre_snapshot()
> and this duplicates the call of suspend_nvs_save() and hence the double
> ioremap. We need to drop one of these.
> The following upstream patch addresses this issue.
> BugLink: http://bugs.launchpad.net/bugs/703228
> Impact: mempcpy() oops after multiple S4 cycles. Number of cycles depends
> on how much (or little) mappable NVS region is available.
> Fix: Remove extraneous call to suspend_nvs_save()
> Testcase: Without this patch, a test machine fails after just 12 S4 cycles.
> With the patch, it no longer gets the memcpy() oops.
> I've also soak tested this patch overnight on a another machine with 250
> S4 cycles: no regression with this patch is observed.
> Rafael J. Wysocki (1):
>  ACPI / Sleep: Consolidate suspend and hibernation routines
>  drivers/acpi/sleep.c |   42 ++++++++++++++++--------------------------
>  1 files changed, 16 insertions(+), 26 deletions(-)
> --
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team


More information about the kernel-team mailing list