[REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Askar Safin]

Hi. This commit:

#regzbot introduced: 1796f808e4bb2c074824dc32258ed1e719370cb3

caused a regression. Dell Precision 7780 often wakes up on its own from suspend.
Sometimes wake up happens immediately (i. e. within 7 seconds), sometimes it happens after, say, 30 minutes.

(The laptop comes with Ubuntu preinstalled, but I didn't test this bug on preinstalled Ubuntu)

That commit already caused a lot of other regressions on other laptops:

#regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cb786180dfb5258ff3111181b5e4ecb1d4a297b
#regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d63f11c02b8d3e54bdb65d8c309f73b7f474aec4
#regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a69982c37cd0586e6832268155349301b87f2e35
#regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=782eea0c89f7d071d6b56ecfa1b8b0c81164b9be

I will be available for testing in coming days, then I will switch to other things, and so will not be available for testing.
If you want more time, then, please, ask for it, i. e. say me something like "Please, be available for testing in more 10 days".

Here is config I used for testing:

https://zerobin.net/?5c4e4b8f6e7a6a0d#W35/IXYAxzjFyp7yP71V0EZ6jcF83HOWB/52ldl5jig=

In other words, this is config I used for bisecting. In other words, the bug reproduces
with this config on 1796f808, but doesn't reproduce on d86388c9.

This config was created using localmodconfig, so it is quite possible it will not boot on other computers.

Also, the bug reproduces on pretty standard Debian kernels, for example, on

http://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.12.32-amd64_6.12.32-1_amd64.deb

with standard Debian config.

Here is "bad" dmesg:
https://zerobin.net/?525f36df8d698fba#e3+DHsvv3Lsqmi91d1TqHx19mrilYNDR0bL8DbeNxw0=

I. e. this is dmesg generated during attempts to reproduce the bug on "bad" kernel, i. e. on 1796f808
with minimized config provided above.

And here is "good" dmesg:
https://zerobin.net/?09b26bfcfa523eff#zDMKsIGmfXBLgpml3qDjwW0NnclErstolYEjCMzmmsA=

I. e. it was generated the same way, but with d86388c9.

This is script I used for bisecting:

https://zerobin.net/?a2acfc92e5a33cc3#L7/Z0jY47FFFp7UJ1GPmbhmfrcMTr0zBZst82ubyDs8=

The script uses "rtcwake" to automatize bisecting. Note that the bug reproduces
not only with "rtcwake", but also with normal suspend initiated from GUI without any timer.

This bug causes "rtcwake" to wake up BEFORE specified time.

Bug sometimes reproduces and sometimes not, so script above makes multiple attempts.

The script writes some info to /dev/kmsg , and you may see its output in dmesg above.

If you need more info, ask me. But again: I will be available within some days and then not.
If you need more time, ask me for it.

Reverting commit 1796f808 on top of v6.12.32 causes the bug to disappear.

When I connect external wireless mouse via USB, then the bug becomes harder to reproduce,
so I did testing without anything connected to laptop (except for power source).

--
Askar Safin
https://types.pl/@safinaskar

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Mario Limonciello]

On 6/26/25 6:32 PM, Askar Safin wrote:
> Hi. This commit:
> 
> #regzbot introduced: 1796f808e4bb2c074824dc32258ed1e719370cb3
> 
> caused a regression. Dell Precision 7780 often wakes up on its own from suspend.
> Sometimes wake up happens immediately (i. e. within 7 seconds), sometimes it happens after, say, 30 minutes.
> 
> (The laptop comes with Ubuntu preinstalled, but I didn't test this bug on preinstalled Ubuntu)
> 
> That commit already caused a lot of other regressions on other laptops:
> 
> #regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cb786180dfb5258ff3111181b5e4ecb1d4a297b
> #regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d63f11c02b8d3e54bdb65d8c309f73b7f474aec4
> #regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a69982c37cd0586e6832268155349301b87f2e35
> #regzbot link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=782eea0c89f7d071d6b56ecfa1b8b0c81164b9be
> 
> I will be available for testing in coming days, then I will switch to other things, and so will not be available for testing.
> If you want more time, then, please, ask for it, i. e. say me something like "Please, be available for testing in more 10 days".
> 
> Here is config I used for testing:
> 
> https://zerobin.net/?5c4e4b8f6e7a6a0d#W35/IXYAxzjFyp7yP71V0EZ6jcF83HOWB/52ldl5jig=
> 
> In other words, this is config I used for bisecting. In other words, the bug reproduces
> with this config on 1796f808, but doesn't reproduce on d86388c9.
> 
> This config was created using localmodconfig, so it is quite possible it will not boot on other computers.
> 
> Also, the bug reproduces on pretty standard Debian kernels, for example, on
> 
> http://deb.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-6.12.32-amd64_6.12.32-1_amd64.deb
> 
> with standard Debian config.
> 
> Here is "bad" dmesg:
> https://zerobin.net/?525f36df8d698fba#e3+DHsvv3Lsqmi91d1TqHx19mrilYNDR0bL8DbeNxw0=
> 
> I. e. this is dmesg generated during attempts to reproduce the bug on "bad" kernel, i. e. on 1796f808
> with minimized config provided above.
> 
> And here is "good" dmesg:
> https://zerobin.net/?09b26bfcfa523eff#zDMKsIGmfXBLgpml3qDjwW0NnclErstolYEjCMzmmsA=
> 
> I. e. it was generated the same way, but with d86388c9.
> 
> This is script I used for bisecting:
> 
> https://zerobin.net/?a2acfc92e5a33cc3#L7/Z0jY47FFFp7UJ1GPmbhmfrcMTr0zBZst82ubyDs8=
> 
> The script uses "rtcwake" to automatize bisecting. Note that the bug reproduces
> not only with "rtcwake", but also with normal suspend initiated from GUI without any timer.
> 
> This bug causes "rtcwake" to wake up BEFORE specified time.
> 
> Bug sometimes reproduces and sometimes not, so script above makes multiple attempts.
> 
> The script writes some info to /dev/kmsg , and you may see its output in dmesg above.
> 
> If you need more info, ask me. But again: I will be available within some days and then not.
> If you need more time, ask me for it.
> 
> Reverting commit 1796f808 on top of v6.12.32 causes the bug to disappear.
> 
> When I connect external wireless mouse via USB, then the bug becomes harder to reproduce,
> so I did testing without anything connected to laptop (except for power source).
> 
> --
> Askar Safin
> https://types.pl/@safinaskar
> 
> 

In order to debug this a few helpful things to add to your script:
1) Set /sys/power/pm_debug_messages before starting
2) Capture the value of /sys/power/suspend_stats/last_hw_sleep

BTW - When a wireless mouse is connected via USB I /suspect/ you aren't 
getting into hardware sleep state (or if your it's for not as long of a 
duration).  I'm not sure if that's a hint for this issue or not right 
now.  That's why I think capturing it might be helpful for this issue.

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Askar Safin]

Okay, so here are results of new expirements.

Now I write 1 to /sys/power/pm_debug_messages in the beginning.

I was unable to find "last_hw_sleep" in /sys/power/suspend_stats on these particular kernel configurations.
But I print all other files in /sys/power/suspend_stats .

I used same minimized config as in previous expirements.
I used modified script:

https://zerobin.net/?bccdd94f5f07bf85#8jop5IXDG32p0I7SBfEc29ng0/MdAFZgrqI9x+4A/Fo=

Here is dmesg for "good" commit "d86388c902b45fe2" without external mouse:
https://zerobin.net/?90d41139996f1cd8#Xuy0UjyxtXrOyLxq4YMP/IzUB559v7ESEIqsd/4Fqo0=

Here is dmesg for "bad" commit "1796f808e4bb2c07" without external mouse:
https://zerobin.net/?181b4d79c16fd9b3#nu0HyJX/r9cFtKitVxJB+3CZsGfwKHc6JLYX4OyZHR4=

Here is dmesg for "good" commit "d86388c902b45fe2" with external mouse:
https://zerobin.net/?a13c513b12549f62#LPLtc3MA1iSEPUjaizDk6xwBgEitH16hZE/WUWdgr6c=

Here is dmesg for "bad" commit "1796f808e4bb2c07" with external mouse:
https://zerobin.net/?cda0d7dd920ad66a#VHWKTp8motWKNJawyFC+v+qNP55an/ZR7HTlhmLJ7gA=

As we can see, external USB wireless mouse doesn't really change anything.
No wonder, I have CONFIG_USB_SUPPORT disabled in my minimized config. :)

--
Askar Safin
https://types.pl/@safinaskar

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Mario Limonciello]

On 6/26/25 10:51 PM, Askar Safin wrote:
> Okay, so here are results of new expirements.
> 
> Now I write 1 to /sys/power/pm_debug_messages in the beginning.
> 
> I was unable to find "last_hw_sleep" in /sys/power/suspend_stats on these particular kernel configurations.
> But I print all other files in /sys/power/suspend_stats .

That's odd.  It should be made when the PMC core driver binds.  Maybe 
others will know what's missing here.

> 
> I used same minimized config as in previous expirements.
> I used modified script:
> 
> https://zerobin.net/?bccdd94f5f07bf85#8jop5IXDG32p0I7SBfEc29ng0/MdAFZgrqI9x+4A/Fo=
> 
> Here is dmesg for "good" commit "d86388c902b45fe2" without external mouse:
> https://zerobin.net/?90d41139996f1cd8#Xuy0UjyxtXrOyLxq4YMP/IzUB559v7ESEIqsd/4Fqo0=
> 
> Here is dmesg for "bad" commit "1796f808e4bb2c07" without external mouse:
> https://zerobin.net/?181b4d79c16fd9b3#nu0HyJX/r9cFtKitVxJB+3CZsGfwKHc6JLYX4OyZHR4=
> 
> Here is dmesg for "good" commit "d86388c902b45fe2" with external mouse:
> https://zerobin.net/?a13c513b12549f62#LPLtc3MA1iSEPUjaizDk6xwBgEitH16hZE/WUWdgr6c=
> 
> Here is dmesg for "bad" commit "1796f808e4bb2c07" with external mouse:
> https://zerobin.net/?cda0d7dd920ad66a#VHWKTp8motWKNJawyFC+v+qNP55an/ZR7HTlhmLJ7gA=
> 
> As we can see, external USB wireless mouse doesn't really change anything.
> No wonder, I have CONFIG_USB_SUPPORT disabled in my minimized config. :)
> 
I see in your bad config interrupt 14 is waking the system.  In the good 
config interrupt 8 is waking it.

What is in /proc/interrupts?

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Askar Safin]

 ---- On Fri, 27 Jun 2025 07:58:15 +0400  Mario Limonciello <superm1@kernel.org> wrote ---
 > That's odd.  It should be made when the PMC core driver binds.  Maybe
 > others will know what's missing here.

Command "grep -r -E -I last_hw_sleep ." in culpit kernel (1796f808e4bb2c074824d)
shows nothing. (This is somewhere around 6.1).

So, culpit commit is too old.

If you want, I can retest this thing on current master and on current master with
revert 1796f808e4bb2c074824d.

 > I see in your bad config interrupt 14 is waking the system.  In the good
 > config interrupt 8 is waking it.
 >
 > What is in /proc/interrupts?

/proc/interrupts from culpit kernel: https://paste.debian.net/1382819/

--
Askar Safin
https://types.pl/@safinaskar

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Mario Limonciello]

On 6/30/2025 3:14 AM, Askar Safin wrote:
>   ---- On Fri, 27 Jun 2025 07:58:15 +0400  Mario Limonciello <superm1@kernel.org> wrote ---
>   > That's odd.  It should be made when the PMC core driver binds.  Maybe
>   > others will know what's missing here.
> 
> Command "grep -r -E -I last_hw_sleep ." in culpit kernel (1796f808e4bb2c074824d)
> shows nothing. (This is somewhere around 6.1).
> 
> So, culpit commit is too old.
> 
> If you want, I can retest this thing on current master and on current master with
> revert 1796f808e4bb2c074824d.
> 
>   > I see in your bad config interrupt 14 is waking the system.  In the good
>   > config interrupt 8 is waking it.
>   >
>   > What is in /proc/interrupts?
> 
> /proc/interrupts from culpit kernel: https://paste.debian.net/1382819/
> 
> --
> Askar Safin
> https://types.pl/@safinaskar
> 

Looks like your interrupt 14 is ACPI device INTC1085:00.

Some quick searches this seems to be an Intel GPIO controller.

Andy,

Any ideas how to debug next?

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Askar Safin]

 ---- On Mon, 30 Jun 2025 22:40:28 +0400  Mario Limonciello <superm1@kernel.org> wrote --- 
 > Looks like your interrupt 14 is ACPI device INTC1085:00.
 > 
 > Some quick searches this seems to be an Intel GPIO controller.
 > 
 > Andy,
 > 
 > Any ideas how to debug next?

So what?

I will repeat: similar bugs were already fixed here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=782eea0c89f7d071d6b56ecfa1b8b0c81164b9be
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a69982c37cd0586e6832268155349301b87f2e35
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cb786180dfb5258ff3111181b5e4ecb1d4a297b

So we just need to add similar patch. I. e. something similar to this:

+		.matches = {
+			DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
+		},
+		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+			.ignore_wake = "ELAN0415:00@9",
+		},

Remaining question: how should I get these strings on my system? "NL5xRU" and "ELAN0415:00@9"?
--
Askar Safin
https://types.pl/@safinaskar

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Werner Sembach]

Hi,

Am 18.07.25 um 01:29 schrieb Askar Safin:
>   ---- On Mon, 30 Jun 2025 22:40:28 +0400  Mario Limonciello<superm1@kernel.org> wrote ---
>   > Looks like your interrupt 14 is ACPI device INTC1085:00.
>   >
>   > Some quick searches this seems to be an Intel GPIO controller.
>   >
>   > Andy,
>   >
>   > Any ideas how to debug next?
>
> So what?
>
> I will repeat: similar bugs were already fixed here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=782eea0c89f7d071d6b56ecfa1b8b0c81164b9be
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a69982c37cd0586e6832268155349301b87f2e35
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4cb786180dfb5258ff3111181b5e4ecb1d4a297b
>
> So we just need to add similar patch. I. e. something similar to this:
>
> +		.matches = {
> +			DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
> +		},
> +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
> +			.ignore_wake = "ELAN0415:00@9",
> +		},
>
> Remaining question: how should I get these strings on my system? "NL5xRU" and "ELAN0415:00@9"?

DMI_MATCH(DMI_BOARD_NAME, *) will match to /sys/class/dmi/id/board_name 
(/sys/class/dmi/id/ also contains a lot of other strings to identify your device 
e.g. /sys/class/dmi/id/sys_vendor which can be matched with 
DMI_MATCH(DMI_SYS_VENDOR, *))

How to get "ELAN0415:00@9" is somewhere buried in here 
https://gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1725104

Best regards,

Werner

> --
> Askar Safin
> https://types.pl/@safinaskar
>

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Mario Limonciello]

On 7/18/2025 10:13 AM, Werner Sembach wrote:
> Hi,
> 
> Am 18.07.25 um 01:29 schrieb Askar Safin:
>>   ---- On Mon, 30 Jun 2025 22:40:28 +0400  Mario 
>> Limonciello<superm1@kernel.org> wrote ---
>>   > Looks like your interrupt 14 is ACPI device INTC1085:00.
>>   >
>>   > Some quick searches this seems to be an Intel GPIO controller.
>>   >
>>   > Andy,
>>   >
>>   > Any ideas how to debug next?
>>
>> So what?
>>
>> I will repeat: similar bugs were already fixed here:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ 
>> commit/?id=782eea0c89f7d071d6b56ecfa1b8b0c81164b9be
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ 
>> commit/?id=a69982c37cd0586e6832268155349301b87f2e35
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ 
>> commit/?id=4cb786180dfb5258ff3111181b5e4ecb1d4a297b
>>
>> So we just need to add similar patch. I. e. something similar to this:
>>
>> +        .matches = {
>> +            DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
>> +        },
>> +        .driver_data = &(struct acpi_gpiolib_dmi_quirk) {
>> +            .ignore_wake = "ELAN0415:00@9",
>> +        },
>>
>> Remaining question: how should I get these strings on my system? 
>> "NL5xRU" and "ELAN0415:00@9"?
> 
> DMI_MATCH(DMI_BOARD_NAME, *) will match to /sys/class/dmi/id/board_name 
> (/sys/class/dmi/id/ also contains a lot of other strings to identify 
> your device e.g. /sys/class/dmi/id/sys_vendor which can be matched with 
> DMI_MATCH(DMI_SYS_VENDOR, *))
> 
> How to get "ELAN0415:00@9" is somewhere buried in here https:// 
> gitlab.freedesktop.org/drm/amd/-/issues/1722#note_1725104
> 
> Best regards,
> 
> Werner
> 
>> -- 
>> Askar Safin
>> https://types.pl/@safinaskar
>>

Before jumping into quirk development I think we need to know exactly 
what GPIO is being tripped and that needs to be matched against the Dell 
design (or Intel specs if it's an "internal" GPIO).

That's why I was hoping Andy could help advise.

On the issue that was linked there we knew the GPIO was tied to the 
attention interrupt for touchpad/touchscreen causing the issue so it was 
easy to look at an acpidump and figure out what it's supposed to be.

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Andy Shevchenko]

On Mon, Jun 30, 2025 at 02:40:28PM -0400, Mario Limonciello wrote:
> On 6/30/2025 3:14 AM, Askar Safin wrote:
> >   ---- On Fri, 27 Jun 2025 07:58:15 +0400  Mario Limonciello <superm1@kernel.org> wrote ---
> >   > That's odd.  It should be made when the PMC core driver binds.  Maybe
> >   > others will know what's missing here.
> > 
> > Command "grep -r -E -I last_hw_sleep ." in culpit kernel (1796f808e4bb2c074824d)
> > shows nothing. (This is somewhere around 6.1).
> > 
> > So, culpit commit is too old.
> > 
> > If you want, I can retest this thing on current master and on current master with
> > revert 1796f808e4bb2c074824d.
> > 
> >   > I see in your bad config interrupt 14 is waking the system.  In the good
> >   > config interrupt 8 is waking it.
> >   >
> >   > What is in /proc/interrupts?
> > 
> > /proc/interrupts from culpit kernel: https://paste.debian.net/1382819/
> > 
> > --
> > Askar Safin
> > https://types.pl/@safinaskar
> > 
> 
> Looks like your interrupt 14 is ACPI device INTC1085:00.
> 
> Some quick searches this seems to be an Intel GPIO controller.
> 
> Andy,
> 
> Any ideas how to debug next?

I believe it's related to the touchpad (can you check that wake happens due to
actually IRQ on pin 355 of the GPIO controller?


-- 
With Best Regards,
Andy Shevchenko

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Andy Shevchenko]

On Mon, Aug 25, 2025 at 06:34:48PM +0300, Andy Shevchenko wrote:
> On Mon, Jun 30, 2025 at 02:40:28PM -0400, Mario Limonciello wrote:
> > On 6/30/2025 3:14 AM, Askar Safin wrote:
> > >   ---- On Fri, 27 Jun 2025 07:58:15 +0400  Mario Limonciello <superm1@kernel.org> wrote ---
> > >   > That's odd.  It should be made when the PMC core driver binds.  Maybe
> > >   > others will know what's missing here.
> > > 
> > > Command "grep -r -E -I last_hw_sleep ." in culpit kernel (1796f808e4bb2c074824d)
> > > shows nothing. (This is somewhere around 6.1).
> > > 
> > > So, culpit commit is too old.
> > > 
> > > If you want, I can retest this thing on current master and on current master with
> > > revert 1796f808e4bb2c074824d.
> > > 
> > >   > I see in your bad config interrupt 14 is waking the system.  In the good
> > >   > config interrupt 8 is waking it.
> > >   >
> > >   > What is in /proc/interrupts?
> > > 
> > > /proc/interrupts from culpit kernel: https://paste.debian.net/1382819/
> > > 
> > > --
> > > Askar Safin
> > > https://types.pl/@safinaskar
> > > 
> > 
> > Looks like your interrupt 14 is ACPI device INTC1085:00.
> > 
> > Some quick searches this seems to be an Intel GPIO controller.
> > 
> > Andy,
> > 
> > Any ideas how to debug next?
> 
> I believe it's related to the touchpad (can you check that wake happens due to
> actually IRQ on pin 355 of the GPIO controller?

In other words we need to enable debug of the pin control subsystem and see
what it will print in dmesg.

-- 
With Best Regards,
Andy Shevchenko

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Askar Safin]

Andy Shevchenko:
> In other words we need to enable debug of the pin control subsystem and see
> what it will print in dmesg.

You mean I should enable CONFIG_DEBUG_PINCTRL? Okay, I did this.

So, today I tested everything on fresh kernel, 6.17.0-rc6, without any
patches.

My config is: https://zerobin.net/?ebecc538f6caa22b#88c2k08G8+cZoMjgU9N/WYy28qQjyBW+/H78ygujZxY=
It was generated from Debian config using localmodconfig.
I added few tweaks, in particular I enabled CONFIG_DEBUG_PINCTRL.

# cat /proc/cmdline 
BOOT_IMAGE=/@rootfs/boot/vmlinuz-6.17.0-rc6 root=UUID=015793d4-ad51-4da7-844b-fcc3bcb13a0b ro rootflags=subvol=@rootfs log_buf_len=4M ignore_loglevel

I run this script:
https://zerobin.net/?327f3aa3ef7ce845#Ycu017J9YbRga8uGaCKRzsH7J/lB8D4RudpwTll5lbo=

This script runs "rtcwake -s 6 -m mem" multiple times. Sometimes my laptop wakes on timer (because of rtcwake),
and sometimes it wakes up too early on its own (and this is a bug).

My script did suspend 7 times:

# dmesg | grep s2idle
[  117.934504] PM: suspend entry (s2idle)
[  127.141741] PM: suspend entry (s2idle)
[  131.299554] PM: suspend entry (s2idle)
[  140.034802] PM: suspend entry (s2idle)
[  144.592260] PM: suspend entry (s2idle)
[  154.038621] PM: suspend entry (s2idle)
[  163.034299] PM: suspend entry (s2idle)

Out of them my laptop woke up on timer 4 times and on its own (i. e. due to bug) 3 times:

# dmesg | grep 'woke up'
[  126.087936] will-wake: attempt 0: woke up in time
[  130.248820] will-wake: attempt 1: woke up early
[  138.988770] will-wake: attempt 2: woke up in time
[  143.545973] will-wake: attempt 3: woke up early
[  152.993654] will-wake: attempt 4: woke up in time
[  161.988956] will-wake: attempt 5: woke up in time
[  166.329080] will-wake: attempt 6: woke up early

Here is full output of "dmesg --level=debug+":
https://zerobin.net/?f704a2d56603f4ec#SRrzc2mt2FNNqcltx/ULmtLZRdRH9frdgoODU03AXwE=

/proc/interrupts:
https://zerobin.net/?b7ba5047ca84ab29#TjMUjkAdhpIuKbnvPpuYyNWa/ilA/ciGKwwSbx6KRFc=

# head -n 1000 /sys/class/dmi/id/*
==> /sys/class/dmi/id/bios_date <==
07/15/2025

==> /sys/class/dmi/id/bios_release <==
1.23

==> /sys/class/dmi/id/bios_vendor <==
Dell Inc.

==> /sys/class/dmi/id/bios_version <==
1.23.6

==> /sys/class/dmi/id/board_asset_tag <==


==> /sys/class/dmi/id/board_name <==
0C6JVW

==> /sys/class/dmi/id/board_serial <==
/JNLHW44/VNCMV0046P029A/

==> /sys/class/dmi/id/board_vendor <==
Dell Inc.

==> /sys/class/dmi/id/board_version <==
A00

==> /sys/class/dmi/id/chassis_asset_tag <==


==> /sys/class/dmi/id/chassis_serial <==
JNLHW44

==> /sys/class/dmi/id/chassis_type <==
10

==> /sys/class/dmi/id/chassis_vendor <==
Dell Inc.

==> /sys/class/dmi/id/chassis_version <==


==> /sys/class/dmi/id/ec_firmware_release <==
1.18

==> /sys/class/dmi/id/modalias <==
dmi:bvnDellInc.:bvr1.23.6:bd07/15/2025:br1.23:efr1.18:svnDellInc.:pnPrecision7780:pvr:rvnDellInc.:rn0C6JVW:rvrA00:cvnDellInc.:ct10:cvr:sku0C42:

==> /sys/class/dmi/id/power <==
head: error reading '/sys/class/dmi/id/power': Is a directory

==> /sys/class/dmi/id/product_family <==
Precision

==> /sys/class/dmi/id/product_name <==
Precision 7780

==> /sys/class/dmi/id/product_serial <==
JNLHW44

==> /sys/class/dmi/id/product_sku <==
0C42

==> /sys/class/dmi/id/product_uuid <==
4c4c4544-004e-4c10-8048-cac04f573434

==> /sys/class/dmi/id/product_version <==


==> /sys/class/dmi/id/subsystem <==
head: error reading '/sys/class/dmi/id/subsystem': Is a directory

==> /sys/class/dmi/id/sys_vendor <==
Dell Inc.

==> /sys/class/dmi/id/uevent <==
MODALIAS=dmi:bvnDellInc.:bvr1.23.6:bd07/15/2025:br1.23:efr1.18:svnDellInc.:pnPrecision7780:pvr:rvnDellInc.:rn0C6JVW:rvrA00:cvnDellInc.:ct10:cvr:sku0C42:


Output of dmidecode:
https://zerobin.net/?e7783ba3bd93c895#EAVgKSZQrn0aGC6t9a/RKeZpp1/9TAYlDhHMh2lcpfQ=

-- 
Askar Safin

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Andy Shevchenko]

On Thu, Sep 18, 2025 at 09:33:36PM +0300, Askar Safin wrote:
> Andy Shevchenko:
> > In other words we need to enable debug of the pin control subsystem and see
> > what it will print in dmesg.
> 
> You mean I should enable CONFIG_DEBUG_PINCTRL? Okay, I did this.
> 
> So, today I tested everything on fresh kernel, 6.17.0-rc6, without any
> patches.
> 
> My config is: https://zerobin.net/?ebecc538f6caa22b#88c2k08G8+cZoMjgU9N/WYy28qQjyBW+/H78ygujZxY=
> It was generated from Debian config using localmodconfig.
> I added few tweaks, in particular I enabled CONFIG_DEBUG_PINCTRL.
> 
> # cat /proc/cmdline 
> BOOT_IMAGE=/@rootfs/boot/vmlinuz-6.17.0-rc6 root=UUID=015793d4-ad51-4da7-844b-fcc3bcb13a0b ro rootflags=subvol=@rootfs log_buf_len=4M ignore_loglevel
> 
> I run this script:
> https://zerobin.net/?327f3aa3ef7ce845#Ycu017J9YbRga8uGaCKRzsH7J/lB8D4RudpwTll5lbo=
> 
> This script runs "rtcwake -s 6 -m mem" multiple times. Sometimes my laptop wakes on timer (because of rtcwake),
> and sometimes it wakes up too early on its own (and this is a bug).
> 
> My script did suspend 7 times:
> 
> # dmesg | grep s2idle
> [  117.934504] PM: suspend entry (s2idle)
> [  127.141741] PM: suspend entry (s2idle)
> [  131.299554] PM: suspend entry (s2idle)
> [  140.034802] PM: suspend entry (s2idle)
> [  144.592260] PM: suspend entry (s2idle)
> [  154.038621] PM: suspend entry (s2idle)
> [  163.034299] PM: suspend entry (s2idle)
> 
> Out of them my laptop woke up on timer 4 times and on its own (i. e. due to bug) 3 times:
> 
> # dmesg | grep 'woke up'
> [  126.087936] will-wake: attempt 0: woke up in time
> [  130.248820] will-wake: attempt 1: woke up early
> [  138.988770] will-wake: attempt 2: woke up in time
> [  143.545973] will-wake: attempt 3: woke up early
> [  152.993654] will-wake: attempt 4: woke up in time
> [  161.988956] will-wake: attempt 5: woke up in time
> [  166.329080] will-wake: attempt 6: woke up early
> 
> Here is full output of "dmesg --level=debug+":
> https://zerobin.net/?f704a2d56603f4ec#SRrzc2mt2FNNqcltx/ULmtLZRdRH9frdgoODU03AXwE=
> 
> /proc/interrupts:
> https://zerobin.net/?b7ba5047ca84ab29#TjMUjkAdhpIuKbnvPpuYyNWa/ilA/ciGKwwSbx6KRFc=


  14:          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0       4202          0          0          0          0          0          0          0          0          0          0          0 IR-IO-APIC   14-fasteoi   INTC1085:00


 204:          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0       4199          0          0          0          0          0          0          0          0          0          0          0 intel-gpio  355  VEN_0488:00


Sounds like it comes via GPIO, but it's not handled as touchpad IRQ. You may
try to add a quirk to prevent touchpad IRQ from waking the system. That should
help I believe.
Something like "ignore_wake=INTC1085:00@355" in the kernel command line.
If it helps, update drivers/gpio/gpiolib-acpi-quirks.c accordingly.

-- 
With Best Regards,
Andy Shevchenko

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Andy Shevchenko]

On Sun, Nov 09, 2025 at 09:05:07PM +0200, Andy Shevchenko wrote:
> On Thu, Sep 18, 2025 at 09:33:36PM +0300, Askar Safin wrote:
> > Andy Shevchenko:
> > > In other words we need to enable debug of the pin control subsystem and see
> > > what it will print in dmesg.
> > 
> > You mean I should enable CONFIG_DEBUG_PINCTRL? Okay, I did this.
> > 
> > So, today I tested everything on fresh kernel, 6.17.0-rc6, without any
> > patches.
> > 
> > My config is: https://zerobin.net/?ebecc538f6caa22b#88c2k08G8+cZoMjgU9N/WYy28qQjyBW+/H78ygujZxY=
> > It was generated from Debian config using localmodconfig.
> > I added few tweaks, in particular I enabled CONFIG_DEBUG_PINCTRL.
> > 
> > # cat /proc/cmdline 
> > BOOT_IMAGE=/@rootfs/boot/vmlinuz-6.17.0-rc6 root=UUID=015793d4-ad51-4da7-844b-fcc3bcb13a0b ro rootflags=subvol=@rootfs log_buf_len=4M ignore_loglevel
> > 
> > I run this script:
> > https://zerobin.net/?327f3aa3ef7ce845#Ycu017J9YbRga8uGaCKRzsH7J/lB8D4RudpwTll5lbo=
> > 
> > This script runs "rtcwake -s 6 -m mem" multiple times. Sometimes my laptop wakes on timer (because of rtcwake),
> > and sometimes it wakes up too early on its own (and this is a bug).
> > 
> > My script did suspend 7 times:
> > 
> > # dmesg | grep s2idle
> > [  117.934504] PM: suspend entry (s2idle)
> > [  127.141741] PM: suspend entry (s2idle)
> > [  131.299554] PM: suspend entry (s2idle)
> > [  140.034802] PM: suspend entry (s2idle)
> > [  144.592260] PM: suspend entry (s2idle)
> > [  154.038621] PM: suspend entry (s2idle)
> > [  163.034299] PM: suspend entry (s2idle)
> > 
> > Out of them my laptop woke up on timer 4 times and on its own (i. e. due to bug) 3 times:
> > 
> > # dmesg | grep 'woke up'
> > [  126.087936] will-wake: attempt 0: woke up in time
> > [  130.248820] will-wake: attempt 1: woke up early
> > [  138.988770] will-wake: attempt 2: woke up in time
> > [  143.545973] will-wake: attempt 3: woke up early
> > [  152.993654] will-wake: attempt 4: woke up in time
> > [  161.988956] will-wake: attempt 5: woke up in time
> > [  166.329080] will-wake: attempt 6: woke up early
> > 
> > Here is full output of "dmesg --level=debug+":
> > https://zerobin.net/?f704a2d56603f4ec#SRrzc2mt2FNNqcltx/ULmtLZRdRH9frdgoODU03AXwE=
> > 
> > /proc/interrupts:
> > https://zerobin.net/?b7ba5047ca84ab29#TjMUjkAdhpIuKbnvPpuYyNWa/ilA/ciGKwwSbx6KRFc=
> 
> 
>   14:          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0       4202          0          0          0          0          0          0          0          0          0          0          0 IR-IO-APIC   14-fasteoi   INTC1085:00
> 
> 
>  204:          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0          0       4199          0          0          0          0          0          0          0          0          0          0          0 intel-gpio  355  VEN_0488:00
> 
> 
> Sounds like it comes via GPIO, but it's not handled as touchpad IRQ. You may
> try to add a quirk to prevent touchpad IRQ from waking the system. That should
> help I believe.
> Something like "ignore_wake=INTC1085:00@355" in the kernel command line.
> If it helps, update drivers/gpio/gpiolib-acpi-quirks.c accordingly.

It might be actually the touchpad controller name (as I see in the quirk table):

	ignore_wake=VEN_0488:00@355

-- 
With Best Regards,
Andy Shevchenko

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Askar Safin]

Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> > Sounds like it comes via GPIO, but it's not handled as touchpad IRQ. You may
> > try to add a quirk to prevent touchpad IRQ from waking the system. That should
> > help I believe.
> > Something like "ignore_wake=INTC1085:00@355" in the kernel command line.
> > If it helps, update drivers/gpio/gpiolib-acpi-quirks.c accordingly.
> 
> It might be actually the touchpad controller name (as I see in the quirk table):
> 
> 	ignore_wake=VEN_0488:00@355

It worked!

First, there is no option "ignore_wake". Correct option name is "gpiolib_acpi.ignore_wake".

I tried "gpiolib_acpi.ignore_wake=INTC1085:00@355", and it didn't help.

I tried "gpiolib_acpi.ignore_wake=VEN_0488:00@355", and it did help!

Please, somebody (maybe Mario?) author a patch.

Thank you in advance.

-- 
Askar Safin

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Mario Limonciello (AMD) (kernel.org)]

On 12/4/2025 8:16 PM, Askar Safin wrote:
> Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
>>> Sounds like it comes via GPIO, but it's not handled as touchpad IRQ. You may
>>> try to add a quirk to prevent touchpad IRQ from waking the system. That should
>>> help I believe.
>>> Something like "ignore_wake=INTC1085:00@355" in the kernel command line.
>>> If it helps, update drivers/gpio/gpiolib-acpi-quirks.c accordingly.
>>
>> It might be actually the touchpad controller name (as I see in the quirk table):
>>
>> 	ignore_wake=VEN_0488:00@355
> 
> It worked!
> 
> First, there is no option "ignore_wake". Correct option name is "gpiolib_acpi.ignore_wake".
> 
> I tried "gpiolib_acpi.ignore_wake=INTC1085:00@355", and it didn't help.
> 
> I tried "gpiolib_acpi.ignore_wake=VEN_0488:00@355", and it did help!
> 
> Please, somebody (maybe Mario?) author a patch.
> 
> Thank you in advance.
> 

Random thought - is this happening specifically when the lid is closed 
and you're applying "pressure" to cause the touchpad to click with the 
lid closed?

If so; it's quite possible that the touchpad attention pin is still 
serviced when the lid is closed.

If that's not it, I would check if you have the latest firmware for the 
touchpad.  Unfortunately this isn't something "commonly" flashable with 
Linux like is the case with BIOS and other components.

Maybe @DellClientKernel could provide some guidance.

But yes; failing all that it's viable to make a quirk.  You can follow 
any of the ones I've submitted for modeling how to do it.  Here's the 
most recent one I've done.

https://github.com/torvalds/linux/commit/23800ad1265f10c2bc6f42154ce4d20e59f2900e

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Askar Safin]

"Mario Limonciello (AMD) (kernel.org)" <superm1@kernel.org>:
> Random thought - is this happening specifically when the lid is closed 
> and you're applying "pressure" to cause the touchpad to click with the 
> lid closed?

No.

I already sent script, which calls rtcwake in a loop. This script reproduces
the bug. I don't touch anything when it is running.

> If that's not it, I would check if you have the latest firmware for the 
> touchpad.  Unfortunately this isn't something "commonly" flashable with 
> Linux like is the case with BIOS and other components.

I already downloaded "touchpad firmware update utility" and did run it
within Windows. So, yes, I have latest firmware.

> Maybe @DellClientKernel could provide some guidance.

Dell.Client.Kernel@dell.com was in CC all this time.

Also, I contacted support via web chat (and said my service tag, of course).
(My laptop comes with Ubuntu preinstalled.)
They said I have basic support only,
so they will not look into the issue too deeply. We had lengthy chat,
and in some moment they said that they will not debug OS-related issues.
I. e. if I want help with this bug, I should reproduce it without OS,
i. e. in BIOS setup utility. Of course, this is not possible, because
one cannot suspend BIOS setup utility.

I sent them link to this thread and said that the bug is probably in firmware.
But they seem to ignore this.

Also, they said I can send the laptop to them, they will try to fix it and
send it back. I don't want this.

> But yes; failing all that it's viable to make a quirk.  You can follow 
> any of the ones I've submitted for modeling how to do it.  Here's the 
> most recent one I've done.
> 
> https://github.com/torvalds/linux/commit/23800ad1265f10c2bc6f42154ce4d20e59f2900e

Thank you! I will write something like this:

+		.matches = {
+			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+			DMI_MATCH(DMI_PRODUCT_FAMILY, "Precision"),
+		},
+		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
+			.ignore_wake = "VEN_0488:00@355",
+		},

I will test it and then properly send (hopefully today or tomorrow).

-- 
Askar Safin

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Mario Limonciello (AMD) (kernel.org)]

On 12/4/2025 10:01 PM, Askar Safin wrote:
> "Mario Limonciello (AMD) (kernel.org)" <superm1@kernel.org>:
>> Random thought - is this happening specifically when the lid is closed
>> and you're applying "pressure" to cause the touchpad to click with the
>> lid closed?
> 
> No.
> 
> I already sent script, which calls rtcwake in a loop. This script reproduces
> the bug. I don't touch anything when it is running.

Right; sorry about that I forgot with this thread starting such a long 
time ago.

> 
>> If that's not it, I would check if you have the latest firmware for the
>> touchpad.  Unfortunately this isn't something "commonly" flashable with
>> Linux like is the case with BIOS and other components.
> 
> I already downloaded "touchpad firmware update utility" and did run it
> within Windows. So, yes, I have latest firmware.
> 
>> Maybe @DellClientKernel could provide some guidance.
> 
> Dell.Client.Kernel@dell.com was in CC all this time.
> 
> Also, I contacted support via web chat (and said my service tag, of course).
> (My laptop comes with Ubuntu preinstalled.)
> They said I have basic support only,
> so they will not look into the issue too deeply. We had lengthy chat,
> and in some moment they said that they will not debug OS-related issues.
> I. e. if I want help with this bug, I should reproduce it without OS,
> i. e. in BIOS setup utility. Of course, this is not possible, because
> one cannot suspend BIOS setup utility.
> 
> I sent them link to this thread and said that the bug is probably in firmware.
> But they seem to ignore this.
> 
> Also, they said I can send the laptop to them, they will try to fix it and
> send it back. I don't want this.

OK.  It sounds like you have exhausted relevant avenues, I'm aligned on 
a quirk.

> 
>> But yes; failing all that it's viable to make a quirk.  You can follow
>> any of the ones I've submitted for modeling how to do it.  Here's the
>> most recent one I've done.
>>
>> https://github.com/torvalds/linux/commit/23800ad1265f10c2bc6f42154ce4d20e59f2900e
> 
> Thank you! I will write something like this:
> 
> +		.matches = {
> +			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> +			DMI_MATCH(DMI_PRODUCT_FAMILY, "Precision"),
> +		},
> +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
> +			.ignore_wake = "VEN_0488:00@355",
> +		},
> 
> I will test it and then properly send (hopefully today or tomorrow).
> 

This match it too liberal.  We don't have any evidence it applies to 
anything more than your single system.  I'd pick some different strings. 
  For example Product SKU is probably a good string to use because 
that's very unique.

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Andy Shevchenko]

On Thu, Dec 04, 2025 at 11:21:32PM -0600, Mario Limonciello (AMD) (kernel.org) wrote:
> On 12/4/2025 10:01 PM, Askar Safin wrote:
> > "Mario Limonciello (AMD) (kernel.org)" <superm1@kernel.org>:

...

> > > But yes; failing all that it's viable to make a quirk.  You can follow
> > > any of the ones I've submitted for modeling how to do it.  Here's the
> > > most recent one I've done.
> > > 
> > > https://github.com/torvalds/linux/commit/23800ad1265f10c2bc6f42154ce4d20e59f2900e
> > 
> > Thank you! I will write something like this:
> > 
> > +		.matches = {
> > +			DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
> > +			DMI_MATCH(DMI_PRODUCT_FAMILY, "Precision"),
> > +		},
> > +		.driver_data = &(struct acpi_gpiolib_dmi_quirk) {
> > +			.ignore_wake = "VEN_0488:00@355",
> > +		},
> > 
> > I will test it and then properly send (hopefully today or tomorrow).
> 
> This match it too liberal.  We don't have any evidence it applies to
> anything more than your single system.  I'd pick some different strings.
> For example Product SKU is probably a good string to use because that's very
> unique.

+1. If we ever see another one, we can then think of a more generic quirk.

-- 
With Best Regards,
Andy Shevchenko

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Andy Shevchenko]

On Fri, Dec 05, 2025 at 05:16:16AM +0300, Askar Safin wrote:
> Andy Shevchenko <andriy.shevchenko@linux.intel.com>:
> > > Sounds like it comes via GPIO, but it's not handled as touchpad IRQ. You may
> > > try to add a quirk to prevent touchpad IRQ from waking the system. That should
> > > help I believe.
> > > Something like "ignore_wake=INTC1085:00@355" in the kernel command line.
> > > If it helps, update drivers/gpio/gpiolib-acpi-quirks.c accordingly.
> > 
> > It might be actually the touchpad controller name (as I see in the quirk table):
> > 
> > 	ignore_wake=VEN_0488:00@355
> 
> It worked!

Glad to hear this!

> First, there is no option "ignore_wake". Correct option name is "gpiolib_acpi.ignore_wake".

Sure, sorry for mistake on my part, I never remember the whole names of the
kernel command line parameters.

> I tried "gpiolib_acpi.ignore_wake=INTC1085:00@355", and it didn't help.
> 
> I tried "gpiolib_acpi.ignore_wake=VEN_0488:00@355", and it did help!
> 
> Please, somebody (maybe Mario?) author a patch.

You can do it yourself, we may help and I dare to say for Mario and myself
that we even will be glad to help you to produce and submit patch on your own.
The expertise in contribution to Linux kernel is valuable thing, and I truly
believe it will help you in the future.

-- 
With Best Regards,
Andy Shevchenko

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Askar Safin]

Andy, Mario and others.

During these months I found zillions of suspend and hibernation related bugs.

It seems hibernation is not well supported.

For example, it seems hibernation is not supported on Chromebooks [1].

And Fedora intentionally disables it by default. [2]

Other operating systems do similar thing. Hibernation is hard-to-enable
in Windows [3]. macOS on Apple Silicon hibernate in very limited scenarios [4].

But I still use hibernation.

So, I have an idea. Maybe we should remove as many as possible hibernation-related
code from kernel to make sure that remaining code is easy to support? I. e.
maybe we should remove some even-more-obscure-than-hibernation features,
such as hybrid sleep mode, to make normal hibernation easier to maintain?

If you like this idea, then I will happily write patches for removing
some hibernation-related features, such as hybrid sleep mode.

Other ideas:
- Remove uswsusp (i. e. kernel/power/user.c ) in favor of normal hibernation
(or vice versa, i. e. remove normal hibernation and keep uswsusp only)
- Remove hibernation to swap partition and keep hibernation to swapfile only
(or vice versa)
- Decouple hibernation from swap completely (i. e. hibernate not to swap
partition, but to special designated partition or file)

In short, just tell me what should be removed, and I will happily remove it.

[1] https://www.reddit.com/r/chromeos/comments/y5pol9/anyone_know_what_the_status_of_hiberman_hibernate/
[2] https://pagure.io/fedora-workstation/blob/master/f/notes/hibernationstatus.md
[3] https://www.groovypost.com/howto/enable-hibernate-mode-windows-10/
[4] https://www.reddit.com/r/chromeos/comments/y5pol9/comment/ism352k/

-- 
Askar Safin

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Andy Shevchenko]

On Sun, Dec 07, 2025 at 07:04:59AM +0300, Askar Safin wrote:
> Andy, Mario and others.
> 
> During these months I found zillions of suspend and hibernation related bugs.
> 
> It seems hibernation is not well supported.
> 
> For example, it seems hibernation is not supported on Chromebooks [1].
> 
> And Fedora intentionally disables it by default. [2]
> 
> Other operating systems do similar thing. Hibernation is hard-to-enable
> in Windows [3]. macOS on Apple Silicon hibernate in very limited scenarios [4].
> 
> But I still use hibernation.
> 
> So, I have an idea. Maybe we should remove as many as possible hibernation-related
> code from kernel to make sure that remaining code is easy to support?

Maybe not.

> I. e. maybe we should remove some even-more-obscure-than-hibernation features,
> such as hybrid sleep mode, to make normal hibernation easier to maintain?

Hibernation is not only for workstations. And I believe it works in Linux to
some extent. You need to discuss this in Linux PM mailing list.

> If you like this idea, then I will happily write patches for removing
> some hibernation-related features, such as hybrid sleep mode.
> 
> Other ideas:
> - Remove uswsusp (i. e. kernel/power/user.c ) in favor of normal hibernation
> (or vice versa, i. e. remove normal hibernation and keep uswsusp only)
> - Remove hibernation to swap partition and keep hibernation to swapfile only
> (or vice versa)
> - Decouple hibernation from swap completely (i. e. hibernate not to swap
> partition, but to special designated partition or file)
> 
> In short, just tell me what should be removed, and I will happily remove it.

I think nothing. It's better to try to actually fix the non-working scenarios
rather than remove the feature completely.

> [1] https://www.reddit.com/r/chromeos/comments/y5pol9/anyone_know_what_the_status_of_hiberman_hibernate/
> [2] https://pagure.io/fedora-workstation/blob/master/f/notes/hibernationstatus.md
> [3] https://www.groovypost.com/howto/enable-hibernate-mode-windows-10/
> [4] https://www.reddit.com/r/chromeos/comments/y5pol9/comment/ism352k/

P.S.
I'm sorry, but why are you so eager to remove something? While in many cases
removal of (potentially dead or unused) code is considered a good thing, it's
not always the case.

-- 
With Best Regards,
Andy Shevchenko

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Askar Safin]

On Sun, Dec 7, 2025 at 1:18 PM Andy Shevchenko
<andriy.shevchenko@linux.intel.com> wrote:
> I think nothing. It's better to try to actually fix the non-working scenarios
> rather than remove the feature completely.

OK.

> P.S.
> I'm sorry, but why are you so eager to remove something? While in many cases
> removal of (potentially dead or unused) code is considered a good thing, it's
> not always the case.

Removing code is easier than writing new code. :)

Speaking of initrd, I tried to understand Linux init code a long time
ago (out of curiosity),
and so I wanted to remove initrd (to help me understand the code).
Also I saw initrd
deprecation notice back in 2020, and I decided to send a patch for its
removal back then.
But I got time for this only now.

-- 
Askar Safin

Re: [REGRESSION][BISECTED] Dell Precision 7780 wakes up on its own from suspend

[Andy Shevchenko]

On Sun, Dec 07, 2025 at 07:45:28PM +0300, Askar Safin wrote:
> On Sun, Dec 7, 2025 at 1:18 PM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:

> > I think nothing. It's better to try to actually fix the non-working scenarios
> > rather than remove the feature completely.

> > P.S.
> > I'm sorry, but why are you so eager to remove something? While in many cases
> > removal of (potentially dead or unused) code is considered a good thing, it's
> > not always the case.
> 
> Removing code is easier than writing new code. :)
> 
> Speaking of initrd, I tried to understand Linux init code a long time
> ago (out of curiosity),
> and so I wanted to remove initrd (to help me understand the code).
> Also I saw initrd
> deprecation notice back in 2020, and I decided to send a patch for its
> removal back then.
> But I got time for this only now.

The initrd support is scheduled to be removed in Jan 2027 IIRC.

-- 
With Best Regards,
Andy Shevchenko