kernel/power/hibernate.c | 10 ++++++++-- kernel/power/power.h | 2 ++ 2 files changed, 10 insertions(+), 2 deletions(-)
Wakeup events that occur in the hibernation process's
hibernation_platform_enter() cannot wake up the system. Although the
current hibernation framework will execute part of the recovery process
after a wakeup event occurs, it ultimately performs a shutdown operation
because the system does not check the return value of
hibernation_platform_enter(). In short, if a wakeup event occurs before
putting the system into the final low-power state, it will be missed.
To solve this problem, check the return value of
hibernation_platform_enter(). When it returns -EAGAIN or -EBUSY (indicate
the occurrence of a wakeup event), execute the hibernation recovery
process, discard the previously saved image, and ultimately return to the
working state.
Signed-off-by: Chris Feng <chris.feng@mediatek.com>
---
[PATCH v2]:
- Optimize the "if" condition logic.
- Link to v1: https://lore.kernel.org/all/20231024091447.108072-1-chris.feng@mediatek.com
[PATCH v3]:
- Use pr_info instead of pr_err.
- Fix undeclared function 'swsusp_unmark' build error.
- Refine commit and printing message.
- Change the subject.
- Link to v2: https://lore.kernel.org/all/20231120081516.55172-1-chris.feng@mediatek.com
[PATCH v4]:
- Define an empty swsusp_unmark() function for scenarios where
CONFIG_SUSPEND is not defined.
- Link to v3: https://lore.kernel.org/all/20231204021155.10434-1-chris.feng@mediatek.com
---
kernel/power/hibernate.c | 10 ++++++++--
kernel/power/power.h | 2 ++
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index dee341ae4ace..621326b3e679 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -642,9 +642,9 @@ int hibernation_platform_enter(void)
*/
static void power_down(void)
{
-#ifdef CONFIG_SUSPEND
int error;
+#ifdef CONFIG_SUSPEND
if (hibernation_mode == HIBERNATION_SUSPEND) {
error = suspend_devices_and_enter(mem_sleep_current);
if (error) {
@@ -667,7 +667,13 @@ static void power_down(void)
kernel_restart(NULL);
break;
case HIBERNATION_PLATFORM:
- hibernation_platform_enter();
+ error = hibernation_platform_enter();
+ if (error == -EAGAIN || error == -EBUSY) {
+ swsusp_unmark();
+ events_check_enabled = false;
+ pr_info("Hibernation process aborted due to detected wakeup event.\n");
+ return;
+ }
fallthrough;
case HIBERNATION_SHUTDOWN:
if (kernel_can_power_off())
diff --git a/kernel/power/power.h b/kernel/power/power.h
index 17fd9aaaf084..8499a39c62f4 100644
--- a/kernel/power/power.h
+++ b/kernel/power/power.h
@@ -175,6 +175,8 @@ extern int swsusp_write(unsigned int flags);
void swsusp_close(void);
#ifdef CONFIG_SUSPEND
extern int swsusp_unmark(void);
+#else
+static inline int swsusp_unmark(void) { return 0; }
#endif
struct __kernel_old_timeval;
--
2.17.0Chris Feng <chris.feng@mediatek.com>:
> Wakeup events that occur in the hibernation process's
> hibernation_platform_enter() cannot wake up the system. Although the
> current hibernation framework will execute part of the recovery process
> after a wakeup event occurs, it ultimately performs a shutdown operation
> because the system does not check the return value of
> hibernation_platform_enter(). In short, if a wakeup event occurs before
> putting the system into the final low-power state, it will be missed.
>
> To solve this problem, check the return value of
> hibernation_platform_enter(). When it returns -EAGAIN or -EBUSY (indicate
> the occurrence of a wakeup event), execute the hibernation recovery
> process, discard the previously saved image, and ultimately return to the
> working state.
#regzbot introduced: 0c4cae1bc00d31c78858c184ede351baea232bdb
Hibernation doesn't work on my laptop.
My laptop is Dell Precision 7780.
Hibernation starts, then aborts. dmesg contains:
[ 28.283320] PM: hibernation: Wakeup event detected during hibernation, rolling back.
I did bisect. The bug reproduces starting with 0c4cae1bc00d.
The bug still reproduces on v6.18-rc2.
Note: there is another problem with PM on my laptop, which is tracked here:
https://lore.kernel.org/all/197ae95ffd8.dc819e60457077.7692120488609091556@zohomail.com/ .
So I always revert 1796f808e4bb in my kernels.
But this doesn't prevent this hibernation bug.
In other words, this hibernation bug still happens on v6.18-rc2 even
with 1796f808e4bb reverted.
Steps to reproduce:
1. Power off laptop, then power on
2. Hibernate ("sudo systemctl hibernate")
Hibernate will not work.
Note that to reproduce the bug you need power off laptop, and then power on
it in step 1. Merely reboot doesn't cause bug. I. e. reproducibilty
depends on whether last boot was reboot or cold power on.
Also: suspend works normally (assuming I reverted 1796f808e4bb), but hibernate
doesn't.
This is "dmesg --level=debug+" on v6.18-rc2-with-1796f808e4bb-reverted:
https://zerobin.net/?0459f6411446622d#8i0Ifo6o68By3+UlYUr2t2KL7YLXsKEXrkfszpE77Rw=
This is config of this kernel:
https://zerobin.net/?04e89ceab8284c1d#9bpaZKqVXFSaeav/WW6GOCwD4i3SozzQ8pBEJ6LWwVM=
--
Askar Safin
Askar Safin <safinaskar@gmail.com>: > This is "dmesg --level=debug+" on v6.18-rc2-with-1796f808e4bb-reverted: > > https://zerobin.net/?0459f6411446622d#8i0Ifo6o68By3+UlYUr2t2KL7YLXsKEXrkfszpE77Rw= This log contains WARNING. It is caused by unrelated bug, which is reproducible both on real hardware and in Qemu. I reported it here: https://lore.kernel.org/regressions/20251025050812.421905-1-safinaskar@gmail.com/ -- Askar Safin
On 10/21/2025 7:54 AM, Askar Safin wrote:
> Chris Feng <chris.feng@mediatek.com>:
>> Wakeup events that occur in the hibernation process's
>> hibernation_platform_enter() cannot wake up the system. Although the
>> current hibernation framework will execute part of the recovery process
>> after a wakeup event occurs, it ultimately performs a shutdown operation
>> because the system does not check the return value of
>> hibernation_platform_enter(). In short, if a wakeup event occurs before
>> putting the system into the final low-power state, it will be missed.
>>
>> To solve this problem, check the return value of
>> hibernation_platform_enter(). When it returns -EAGAIN or -EBUSY (indicate
>> the occurrence of a wakeup event), execute the hibernation recovery
>> process, discard the previously saved image, and ultimately return to the
>> working state.
>
> #regzbot introduced: 0c4cae1bc00d31c78858c184ede351baea232bdb
>
> Hibernation doesn't work on my laptop.
>
> My laptop is Dell Precision 7780.
>
> Hibernation starts, then aborts. dmesg contains:
>
> [ 28.283320] PM: hibernation: Wakeup event detected during hibernation, rolling back.
>
> I did bisect. The bug reproduces starting with 0c4cae1bc00d.
>
> The bug still reproduces on v6.18-rc2.
>
> Note: there is another problem with PM on my laptop, which is tracked here:
> https://lore.kernel.org/all/197ae95ffd8.dc819e60457077.7692120488609091556@zohomail.com/ .
>
> So I always revert 1796f808e4bb in my kernels.
>
> But this doesn't prevent this hibernation bug.
>
> In other words, this hibernation bug still happens on v6.18-rc2 even
> with 1796f808e4bb reverted.
>
> Steps to reproduce:
> 1. Power off laptop, then power on
> 2. Hibernate ("sudo systemctl hibernate")
>
> Hibernate will not work.
>
> Note that to reproduce the bug you need power off laptop, and then power on
> it in step 1. Merely reboot doesn't cause bug. I. e. reproducibilty
> depends on whether last boot was reboot or cold power on.
>
> Also: suspend works normally (assuming I reverted 1796f808e4bb), but hibernate
> doesn't.
>
> This is "dmesg --level=debug+" on v6.18-rc2-with-1796f808e4bb-reverted:
>
> https://zerobin.net/?0459f6411446622d#8i0Ifo6o68By3+UlYUr2t2KL7YLXsKEXrkfszpE77Rw=
>
> This is config of this kernel:
>
> https://zerobin.net/?04e89ceab8284c1d#9bpaZKqVXFSaeav/WW6GOCwD4i3SozzQ8pBEJ6LWwVM=
>
To me it sounds like it's potentially the same root cause for the early
suspend wakeup as well as the hibernate wakeup.
Assuming the GPIO pointed out in that other thread
(https://lore.kernel.org/all/20250918183336.5633-1-safinaskar@gmail.com/)
is indeed the touchpad GPIO I had a suspicion. Are you closing the lid
and putting the laptop in a bag or putting anything on top of it?
I wonder if the touchpad is not disabled by the hardware and getting
pressure through the lid and physically clicking/activating.
I've seen this exact issue occur on a Framework 16 as well. The
workaround is to disable wakeup from touchpad before suspend/hibernate.
On Tue, Oct 21, 2025 at 5:29 PM Mario Limonciello <mario.limonciello@amd.com> wrote: > To me it sounds like it's potentially the same root cause for the early > suspend wakeup as well as the hibernate wakeup. Adding "gpiolib_acpi.ignore_wake=VEN_0488:00@355" or "gpiolib_acpi.ignore_wake=INTC1085:00@355" doesn't fix this bug. > Are you closing the lid > and putting the laptop in a bag or putting anything on top of it? No. I just click "Hibernate" button using touchpad in GUI, and hibernate fails. I just did some printf-debugging. Results: We call https://elixir.bootlin.com/linux/v6.18/source/kernel/power/hibernate.c#L870 , it calls https://elixir.bootlin.com/linux/v6.18/source/kernel/power/hibernate.c#L723 , it calls https://elixir.bootlin.com/linux/v6.18/source/kernel/power/hibernate.c#L636 , it calls dpm_suspend https://elixir.bootlin.com/linux/v6.18/source/drivers/base/power/main.c#L2265 , that dpm_suspend returns error, and this error leads to "Wakeup event detected during hibernation" message. Any further pointers? How to debug? -- Askar Safin
On 12/9/2025 12:02 AM, Askar Safin wrote: > On Tue, Oct 21, 2025 at 5:29 PM Mario Limonciello > <mario.limonciello@amd.com> wrote: >> To me it sounds like it's potentially the same root cause for the early >> suspend wakeup as well as the hibernate wakeup. > > Adding "gpiolib_acpi.ignore_wake=VEN_0488:00@355" or > "gpiolib_acpi.ignore_wake=INTC1085:00@355" > doesn't fix this bug. > >> Are you closing the lid >> and putting the laptop in a bag or putting anything on top of it? > > No. I just click "Hibernate" button using touchpad in GUI, and hibernate fails. > Can you try using command line instead in case it's actually the touchpad click still being registered? > I just did some printf-debugging. Results: > > We call > https://elixir.bootlin.com/linux/v6.18/source/kernel/power/hibernate.c#L870 , > it calls > https://elixir.bootlin.com/linux/v6.18/source/kernel/power/hibernate.c#L723 , > it calls > https://elixir.bootlin.com/linux/v6.18/source/kernel/power/hibernate.c#L636 , > it calls dpm_suspend > https://elixir.bootlin.com/linux/v6.18/source/drivers/base/power/main.c#L2265 , > that dpm_suspend returns error, and this error leads to > "Wakeup event detected during hibernation" message. > > Any further pointers? How to debug? > If you haven't already; turn on /sys/power/pm_debug_messages and /sys/power/pm_print_times. This should help clarify the last functions that are run and any debug level PM related messages that are emitted that lead to the failure. You can also check /sys/power/pm_wakeup_irq after the failure to confirm which interrupt woke the system (assuming that was the source of the early wakeup event).
On Wed, Dec 13, 2023 at 9:33 AM Chris Feng <chris.feng@mediatek.com> wrote:
>
> Wakeup events that occur in the hibernation process's
> hibernation_platform_enter() cannot wake up the system. Although the
> current hibernation framework will execute part of the recovery process
> after a wakeup event occurs, it ultimately performs a shutdown operation
> because the system does not check the return value of
> hibernation_platform_enter(). In short, if a wakeup event occurs before
> putting the system into the final low-power state, it will be missed.
>
> To solve this problem, check the return value of
> hibernation_platform_enter(). When it returns -EAGAIN or -EBUSY (indicate
> the occurrence of a wakeup event), execute the hibernation recovery
> process, discard the previously saved image, and ultimately return to the
> working state.
>
> Signed-off-by: Chris Feng <chris.feng@mediatek.com>
> ---
> [PATCH v2]:
> - Optimize the "if" condition logic.
> - Link to v1: https://lore.kernel.org/all/20231024091447.108072-1-chris.feng@mediatek.com
> [PATCH v3]:
> - Use pr_info instead of pr_err.
> - Fix undeclared function 'swsusp_unmark' build error.
> - Refine commit and printing message.
> - Change the subject.
> - Link to v2: https://lore.kernel.org/all/20231120081516.55172-1-chris.feng@mediatek.com
> [PATCH v4]:
> - Define an empty swsusp_unmark() function for scenarios where
> CONFIG_SUSPEND is not defined.
> - Link to v3: https://lore.kernel.org/all/20231204021155.10434-1-chris.feng@mediatek.com
> ---
> kernel/power/hibernate.c | 10 ++++++++--
> kernel/power/power.h | 2 ++
> 2 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index dee341ae4ace..621326b3e679 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -642,9 +642,9 @@ int hibernation_platform_enter(void)
> */
> static void power_down(void)
> {
> -#ifdef CONFIG_SUSPEND
> int error;
>
> +#ifdef CONFIG_SUSPEND
> if (hibernation_mode == HIBERNATION_SUSPEND) {
> error = suspend_devices_and_enter(mem_sleep_current);
> if (error) {
> @@ -667,7 +667,13 @@ static void power_down(void)
> kernel_restart(NULL);
> break;
> case HIBERNATION_PLATFORM:
> - hibernation_platform_enter();
> + error = hibernation_platform_enter();
> + if (error == -EAGAIN || error == -EBUSY) {
> + swsusp_unmark();
> + events_check_enabled = false;
> + pr_info("Hibernation process aborted due to detected wakeup event.\n");
> + return;
> + }
> fallthrough;
> case HIBERNATION_SHUTDOWN:
> if (kernel_can_power_off())
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 17fd9aaaf084..8499a39c62f4 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -175,6 +175,8 @@ extern int swsusp_write(unsigned int flags);
> void swsusp_close(void);
> #ifdef CONFIG_SUSPEND
> extern int swsusp_unmark(void);
> +#else
> +static inline int swsusp_unmark(void) { return 0; }
> #endif
>
> struct __kernel_old_timeval;
> --
Applied as 6.8 material, but I have rephrased the pr_info() message
added by this patch.
Thanks!
© 2016 - 2025 Red Hat, Inc.