Re: Pressing the power button causes the device to freeze completely

Re: Pressing the power button causes the device to freeze completely

[Thorsten Leemhuis]

[removing the stable list, this is not something for them]

On 4/13/26 18:46, Evgeny Sagatov wrote:
> I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0) <https://
> www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10> and processor Intel
> Core 2 Quad Q9550.
> Previously, I had Debian 12 with kernel 6.1 installed, and pressing the
> power button would shut down the PC as usual.
> I updated to Debian 13 with kernel 6.12.74, and now pressing the power
> button causes the PC to freeze completely.
>  
> I see that systemd doesn't even begin to shut down. It freezes
> immediately after pressing the button. There's no error message in
> console. There's no error message in the logs either. Netconsole doesn't
> report any errors, and the kernel doesn't panic. It just freezes completely.
>  
> I checked that Live CD with Debian 12 continue to shut down normally,
> but Live CD with Debian 13 freeze.
> I tried updating and resetting the BIOS. I tried various kernel
> parameters related to ACPI settings. I also tried kernels 6.18 and 6.19.
> Nothing fixed the problem.

Could you please try 7.0 as well? It contains a fix for the commit you
mentioned below.

>  
> If I unload the "button" module, the system doesn't freeze, but it also
> doesn't shut down.
> I built "button" module by rolling back its version to commit 1a20d40
> <https://github.com/torvalds/linux/
> commit/1a20d409c874255086e2f42a729826d490294c91>, which corresponds to
> kernel version 6.1. This module does not freeze, but does not turn off
> the PC either.
>  
> I've found that the freezes have been occurring since commit 0d51157
> <https://github.com/torvalds/linux/
> commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.

That is 0d51157dfaac05 ("ACPI: button: Eliminate the driver notify
callback") [v6.5-rc1] from Rafael. But that is a very old commit; and
you seem to be switching distro versions and kernel at the same time,
which could interfere.

How did you find that this causes the problem? Did you do a proper
bisection and thus checked if the parent of that commit really works?

> Unfortunately, my skills are not enough to understand the reason for the
> freeze.
>  
> I'm attaching dmesg and lspci logs.
Ciao, Thorsten

Re: Pressing the power button causes the device to freeze completely

[Thorsten Leemhuis]

On 4/16/26 19:22, Evgeny Sagatov wrote:
>> Could you please try 7.0 as well?
> I compiled 7.0.0 kernel from sources.
> Unfortunately, this kernel also freezes when the power button is pressed.

Thx for testing.
  
>> How did you find that this causes the problem? Did you do a proper
> bisection and thus checked if the parent of that commit really works?
>  
> I don't think I did it correctly.
> Because the previous commits didn't shut down the PC or cause it to
> freeze. I think they just weren't working.
>  
> I also tried a very simple module tity-power-button. Pressing the power
> button when using this module also causes a full freeze.
> I think the problem lies with the ACPI functionality, but none of kernel
> options helped fix it.
>  
> I'm confused.

Then you likely want to properly bisect the bug. Might be best to do
that on a Debian 12 install (where everything used to be working) by
following this guide:

https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html

But be warned: the regression is old. Even if the culprit is identified
the usual rules wrt to "no regression" might not apply, as fixing the
regression could cause regressions for other users.

Ciao, Thorsten

> ----------------
> Кому: Evgeny Sagatov (sagatov@ya.ru), Rafael J. Wysocki
> (rafael.j.wysocki@intel.com);
> Копия: regressions@lists.linux.dev, LKML (linux-kernel@vger.kernel.org),
> Michal Wilczynski (michal.wilczynski@intel.com);
> Тема: Pressing the power button causes the device to freeze completely;
> 16.04.2026, 11:23, "Thorsten Leemhuis" <regressions@leemhuis.info>:
> 
>     [removing the stable list, this is not something for them]
> 
>     On 4/13/26 18:46, Evgeny Sagatov wrote:
> 
>          I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0) <https://
>          www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10 <https://
>         www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10>> and
>         processor Intel
>          Core 2 Quad Q9550.
>          Previously, I had Debian 12 with kernel 6.1 installed, and
>         pressing the
>          power button would shut down the PC as usual.
>          I updated to Debian 13 with kernel 6.12.74, and now pressing
>         the power
>          button causes the PC to freeze completely.
>           
>          I see that systemd doesn't even begin to shut down. It freezes
>          immediately after pressing the button. There's no error message in
>          console. There's no error message in the logs either.
>         Netconsole doesn't
>          report any errors, and the kernel doesn't panic. It just
>         freezes completely.
>           
>          I checked that Live CD with Debian 12 continue to shut down
>         normally,
>          but Live CD with Debian 13 freeze.
>          I tried updating and resetting the BIOS. I tried various kernel
>          parameters related to ACPI settings. I also tried kernels 6.18
>         and 6.19.
>          Nothing fixed the problem.
> 
> 
>     Could you please try 7.0 as well? It contains a fix for the commit you
>     mentioned below.
>      
> 
>           
>          If I unload the "button" module, the system doesn't freeze, but
>         it also
>          doesn't shut down.
>          I built "button" module by rolling back its version to commit
>         1a20d40
>          <https://github.com/torvalds/linux/ <https://github.com/
>         torvalds/linux/>
>          commit/1a20d409c874255086e2f42a729826d490294c91>, which
>         corresponds to
>          kernel version 6.1. This module does not freeze, but does not
>         turn off
>          the PC either.
>           
>          I've found that the freezes have been occurring since commit
>         0d51157
>          <https://github.com/torvalds/linux/ <https://github.com/
>         torvalds/linux/>
>          commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
> 
> 
>     That is 0d51157dfaac05 ("ACPI: button: Eliminate the driver notify
>     callback") [v6.5-rc1] from Rafael. But that is a very old commit; and
>     you seem to be switching distro versions and kernel at the same time,
>     which could interfere.
> 
>     How did you find that this causes the problem? Did you do a proper
>     bisection and thus checked if the parent of that commit really works?
>      
> 
>          Unfortunately, my skills are not enough to understand the
>         reason for the
>          freeze.
>           
>          I'm attaching dmesg and lspci logs.
> 
>     Ciao, Thorsten
> 

RE: Pressing the power button causes the device to freeze completely

[Sagatov, Evgeniy]

Hello Thorsten,

Thanks for the detailed manual!

I determined that the problem started between versions 6.7.12 and 6.8-rc1. Then I ran a 'git bisect' according to the manual.

Result:
b0d326da462e20285236e11e4cbc32085de9f363 is the first bad commit
commit b0d326da462e20285236e11e4cbc32085de9f363
Merge: 8c94ccc7cd69 e37617c8e53a
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Thu Jan 18 11:57:33 2024 -0800

    Merge tag 'sched-urgent-2024-01-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

    Pull scheduler fix from Ingo Molnar:
     "Fix a cpufreq related performance regression on certain systems, where
      the CPU would remain at the lowest frequency, degrading performance
      substantially"

    * tag 'sched-urgent-2024-01-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
      sched/fair: Fix frequency selection for non-invariant case

 kernel/sched/cpufreq_schedutil.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

----
Sincerely, Evgeny Sagatov

 ----------------
16.04.2026, 20:35, Thorsten Leemhuis (mailto:regressions@leemhuis.info):
To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki (mailto:rafael.j.wysocki@intel.com);
Copy: mailto:regressions@lists.linux.dev, LKML (mailto:linux-kernel@vger.kernel.org), Michal Wilczynski (mailto:michal.wilczynski@intel.com);
Topic: Pressing the power button causes the device to freeze completely;
 
On 4/16/26 19:22, Evgeny Sagatov wrote:
 Could you please try 7.0 as well?
 I compiled 7.0.0 kernel from sources.
 Unfortunately, this kernel also freezes when the power button is pressed.

Thx for testing.
  
 How did you find that this causes the problem? Did you do a proper
 bisection and thus checked if the parent of that commit really works?
  
 I don't think I did it correctly.
 Because the previous commits didn't shut down the PC or cause it to
 freeze. I think they just weren't working.
  
 I also tried a very simple module tity-power-button. Pressing the power
 button when using this module also causes a full freeze.
 I think the problem lies with the ACPI functionality, but none of kernel
 options helped fix it.
  
 I'm confused.

Then you likely want to properly bisect the bug. Might be best to do
that on a Debian 12 install (where everything used to be working) by
following this guide:

https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html

But be warned: the regression is old. Even if the culprit is identified
the usual rules wrt to "no regression" might not apply, as fixing the
regression could cause regressions for other users.

Ciao, Thorsten
 
 ----------------
 To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki
 (mailto:rafael.j.wysocki@intel.com);
 Copy: mailto:regressions@lists.linux.dev, LKML (mailto:linux-kernel@vger.kernel.org),
 Michal Wilczynski (mailto:michal.wilczynski@intel.com);
 Topic: Pressing the power button causes the device to freeze completely;
 16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:regressions@leemhuis.info>:
 
     [removing the stable list, this is not something for them]
 
     On 4/13/26 18:46, Evgeny Sagatov wrote:
 
          I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0) <https://
          https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10 <https://
         https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10>> and
         processor Intel
          Core 2 Quad Q9550.
          Previously, I had Debian 12 with kernel 6.1 installed, and
         pressing the
          power button would shut down the PC as usual.
          I updated to Debian 13 with kernel 6.12.74, and now pressing
         the power
          button causes the PC to freeze completely.
           
          I see that systemd doesn't even begin to shut down. It freezes
          immediately after pressing the button. There's no error message in
          console. There's no error message in the logs either.
         Netconsole doesn't
          report any errors, and the kernel doesn't panic. It just
         freezes completely.
           
          I checked that Live CD with Debian 12 continue to shut down
         normally,
          but Live CD with Debian 13 freeze.
          I tried updating and resetting the BIOS. I tried various kernel
          parameters related to ACPI settings. I also tried kernels 6.18
         and 6.19.
          Nothing fixed the problem.
 
 
     Could you please try 7.0 as well? It contains a fix for the commit you
     mentioned below.
      
 
           
          If I unload the "button" module, the system doesn't freeze, but
         it also
          doesn't shut down.
          I built "button" module by rolling back its version to commit
         1a20d40
          <https://github.com/torvalds/linux/ <https://github.com/
         torvalds/linux/>
          commit/1a20d409c874255086e2f42a729826d490294c91>, which
         corresponds to
          kernel version 6.1. This module does not freeze, but does not
         turn off
          the PC either.
           
          I've found that the freezes have been occurring since commit
         0d51157
          <https://github.com/torvalds/linux/ <https://github.com/
         torvalds/linux/>
          commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
 
 
     That is 0d51157dfaac05 ("ACPI: button: Eliminate the driver notify
     callback") [v6.5-rc1] from Rafael. But that is a very old commit; and
     you seem to be switching distro versions and kernel at the same time,
     which could interfere.
 
     How did you find that this causes the problem? Did you do a proper
     bisection and thus checked if the parent of that commit really works?
      
 
          Unfortunately, my skills are not enough to understand the
         reason for the
          freeze.
           
          I'm attaching dmesg and lspci logs.
 
     Ciao, Thorsten

Re: Pressing the power button causes the device to freeze completely

[Thorsten Leemhuis]

On 4/20/26 08:41, Sagatov, Evgeniy wrote:
> Hello Thorsten,
> 
> Thanks for the detailed manual!
> 
> I determined that the problem started between versions 6.7.12 and 6.8-rc1. Then I ran a 'git bisect' according to the manual.
> 
> Result:
> b0d326da462e20285236e11e4cbc32085de9f363 is the first bad commit
> commit b0d326da462e20285236e11e4cbc32085de9f363
> Merge: 8c94ccc7cd69 e37617c8e53a
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Thu Jan 18 11:57:33 2024 -0800
> 
>     Merge tag 'sched-urgent-2024-01-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

This is a merge commit. This might be right, but often it is not. Can
you please retest commits 8c94ccc7cd691472461448f98e2372c75849406c,
e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27 and
b0d326da462e20285236e11e4cbc32085de9f363 just to be sure and then share
your results? tia!

Ciao Thorsten

>     Pull scheduler fix from Ingo Molnar:
>      "Fix a cpufreq related performance regression on certain systems, where
>       the CPU would remain at the lowest frequency, degrading performance
>       substantially"
> 
>     * tag 'sched-urgent-2024-01-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
>       sched/fair: Fix frequency selection for non-invariant case
> 
>  kernel/sched/cpufreq_schedutil.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> ----
> Sincerely, Evgeny Sagatov
> 
>  ----------------
> 16.04.2026, 20:35, Thorsten Leemhuis (mailto:regressions@leemhuis.info):
> To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki (mailto:rafael.j.wysocki@intel.com);
> Copy: mailto:regressions@lists.linux.dev, LKML (mailto:linux-kernel@vger.kernel.org), Michal Wilczynski (mailto:michal.wilczynski@intel.com);
> Topic: Pressing the power button causes the device to freeze completely;
>  
> On 4/16/26 19:22, Evgeny Sagatov wrote:
>  Could you please try 7.0 as well?
>  I compiled 7.0.0 kernel from sources.
>  Unfortunately, this kernel also freezes when the power button is pressed.
> 
> Thx for testing.
>   
>  How did you find that this causes the problem? Did you do a proper
>  bisection and thus checked if the parent of that commit really works?
>   
>  I don't think I did it correctly.
>  Because the previous commits didn't shut down the PC or cause it to
>  freeze. I think they just weren't working.
>   
>  I also tried a very simple module tity-power-button. Pressing the power
>  button when using this module also causes a full freeze.
>  I think the problem lies with the ACPI functionality, but none of kernel
>  options helped fix it.
>   
>  I'm confused.
> 
> Then you likely want to properly bisect the bug. Might be best to do
> that on a Debian 12 install (where everything used to be working) by
> following this guide:
> 
> https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html
> 
> But be warned: the regression is old. Even if the culprit is identified
> the usual rules wrt to "no regression" might not apply, as fixing the
> regression could cause regressions for other users.
> 
> Ciao, Thorsten
>  
>  ----------------
>  To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki
>  (mailto:rafael.j.wysocki@intel.com);
>  Copy: mailto:regressions@lists.linux.dev, LKML (mailto:linux-kernel@vger.kernel.org),
>  Michal Wilczynski (mailto:michal.wilczynski@intel.com);
>  Topic: Pressing the power button causes the device to freeze completely;
>  16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:regressions@leemhuis.info>:
>  
>      [removing the stable list, this is not something for them]
>  
>      On 4/13/26 18:46, Evgeny Sagatov wrote:
>  
>           I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0) <https://
>           https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10 <https://
>          https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10>> and
>          processor Intel
>           Core 2 Quad Q9550.
>           Previously, I had Debian 12 with kernel 6.1 installed, and
>          pressing the
>           power button would shut down the PC as usual.
>           I updated to Debian 13 with kernel 6.12.74, and now pressing
>          the power
>           button causes the PC to freeze completely.
>            
>           I see that systemd doesn't even begin to shut down. It freezes
>           immediately after pressing the button. There's no error message in
>           console. There's no error message in the logs either.
>          Netconsole doesn't
>           report any errors, and the kernel doesn't panic. It just
>          freezes completely.
>            
>           I checked that Live CD with Debian 12 continue to shut down
>          normally,
>           but Live CD with Debian 13 freeze.
>           I tried updating and resetting the BIOS. I tried various kernel
>           parameters related to ACPI settings. I also tried kernels 6.18
>          and 6.19.
>           Nothing fixed the problem.
>  
>  
>      Could you please try 7.0 as well? It contains a fix for the commit you
>      mentioned below.
>       
>  
>            
>           If I unload the "button" module, the system doesn't freeze, but
>          it also
>           doesn't shut down.
>           I built "button" module by rolling back its version to commit
>          1a20d40
>           <https://github.com/torvalds/linux/ <https://github.com/
>          torvalds/linux/>
>           commit/1a20d409c874255086e2f42a729826d490294c91>, which
>          corresponds to
>           kernel version 6.1. This module does not freeze, but does not
>          turn off
>           the PC either.
>            
>           I've found that the freezes have been occurring since commit
>          0d51157
>           <https://github.com/torvalds/linux/ <https://github.com/
>          torvalds/linux/>
>           commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
>  
>  
>      That is 0d51157dfaac05 ("ACPI: button: Eliminate the driver notify
>      callback") [v6.5-rc1] from Rafael. But that is a very old commit; and
>      you seem to be switching distro versions and kernel at the same time,
>      which could interfere.
>  
>      How did you find that this causes the problem? Did you do a proper
>      bisection and thus checked if the parent of that commit really works?
>       
>  
>           Unfortunately, my skills are not enough to understand the
>          reason for the
>           freeze.
>            
>           I'm attaching dmesg and lspci logs.
>  
>      Ciao, Thorsten
> 

RE: Pressing the power button causes the device to freeze completely

[Sagatov, Evgeniy]

8c94ccc7cd691472461448f98e2372c75849406c    good
e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27    good
b0d326da462e20285236e11e4cbc32085de9f363    bad

I also built the stock Debian 13 kernel, version 6.12.74, and reverted commit b0d326da462e20285236e11e4cbc32085de9f363.
The PC shuts down without any issues with this kernel when pressing the power button.

----
Sincerely, Evgeny Sagatov

-----Original Message-----
From: Thorsten Leemhuis <regressions@leemhuis.info> 
Sent: Monday, April 20, 2026 9:55 AM
To: Sagatov, Evgeniy <esagatov@amt.ru>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; regressions@lists.linux.dev; LKML <linux-kernel@vger.kernel.org>; Michal Wilczynski <michal.wilczynski@intel.com>
Subject: Re: Pressing the power button causes the device to freeze completely

On 4/20/26 08:41, Sagatov, Evgeniy wrote:
> Hello Thorsten,
> 
> Thanks for the detailed manual!
> 
> I determined that the problem started between versions 6.7.12 and 6.8-rc1. Then I ran a 'git bisect' according to the manual.
> 
> Result:
> b0d326da462e20285236e11e4cbc32085de9f363 is the first bad commit 
> commit b0d326da462e20285236e11e4cbc32085de9f363
> Merge: 8c94ccc7cd69 e37617c8e53a
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Thu Jan 18 11:57:33 2024 -0800
> 
>     Merge tag 'sched-urgent-2024-01-18' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

This is a merge commit. This might be right, but often it is not. Can you please retest commits 8c94ccc7cd691472461448f98e2372c75849406c,
e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27 and
b0d326da462e20285236e11e4cbc32085de9f363 just to be sure and then share your results? tia!

Ciao Thorsten

>     Pull scheduler fix from Ingo Molnar:
>      "Fix a cpufreq related performance regression on certain systems, where
>       the CPU would remain at the lowest frequency, degrading performance
>       substantially"
> 
>     * tag 'sched-urgent-2024-01-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
>       sched/fair: Fix frequency selection for non-invariant case
> 
>  kernel/sched/cpufreq_schedutil.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> ----
> Sincerely, Evgeny Sagatov
> 
>  ----------------
> 16.04.2026, 20:35, Thorsten Leemhuis (mailto:regressions@leemhuis.info):
> To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki 
> (mailto:rafael.j.wysocki@intel.com);
> Copy: mailto:regressions@lists.linux.dev, LKML 
> (mailto:linux-kernel@vger.kernel.org), Michal Wilczynski 
> (mailto:michal.wilczynski@intel.com);
> Topic: Pressing the power button causes the device to freeze 
> completely;
>  
> On 4/16/26 19:22, Evgeny Sagatov wrote:
>  Could you please try 7.0 as well?
>  I compiled 7.0.0 kernel from sources.
>  Unfortunately, this kernel also freezes when the power button is pressed.
> 
> Thx for testing.
>   
>  How did you find that this causes the problem? Did you do a proper
>  bisection and thus checked if the parent of that commit really works?
>   
>  I don't think I did it correctly.
>  Because the previous commits didn't shut down the PC or cause it to
>  freeze. I think they just weren't working.
>   
>  I also tried a very simple module tity-power-button. Pressing the 
> power
>  button when using this module also causes a full freeze.
>  I think the problem lies with the ACPI functionality, but none of 
> kernel
>  options helped fix it.
>   
>  I'm confused.
> 
> Then you likely want to properly bisect the bug. Might be best to do 
> that on a Debian 12 install (where everything used to be working) by 
> following this guide:
> 
> https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions
> .html
> 
> But be warned: the regression is old. Even if the culprit is 
> identified the usual rules wrt to "no regression" might not apply, as 
> fixing the regression could cause regressions for other users.
> 
> Ciao, Thorsten
>  
>  ----------------
>  To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki
>  (mailto:rafael.j.wysocki@intel.com);
>  Copy: mailto:regressions@lists.linux.dev, LKML 
> (mailto:linux-kernel@vger.kernel.org),
>  Michal Wilczynski (mailto:michal.wilczynski@intel.com);
>  Topic: Pressing the power button causes the device to freeze 
> completely;
>  16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:regressions@leemhuis.info>:
>  
>      [removing the stable list, this is not something for them]
>  
>      On 4/13/26 18:46, Evgeny Sagatov wrote:
>  
>           I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0) 
> <https://
>           https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10 
> <https://
>          https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10>> 
> and
>          processor Intel
>           Core 2 Quad Q9550.
>           Previously, I had Debian 12 with kernel 6.1 installed, and
>          pressing the
>           power button would shut down the PC as usual.
>           I updated to Debian 13 with kernel 6.12.74, and now pressing
>          the power
>           button causes the PC to freeze completely.
>            
>           I see that systemd doesn't even begin to shut down. It 
> freezes
>           immediately after pressing the button. There's no error 
> message in
>           console. There's no error message in the logs either.
>          Netconsole doesn't
>           report any errors, and the kernel doesn't panic. It just
>          freezes completely.
>            
>           I checked that Live CD with Debian 12 continue to shut down
>          normally,
>           but Live CD with Debian 13 freeze.
>           I tried updating and resetting the BIOS. I tried various 
> kernel
>           parameters related to ACPI settings. I also tried kernels 
> 6.18
>          and 6.19.
>           Nothing fixed the problem.
>  
>  
>      Could you please try 7.0 as well? It contains a fix for the 
> commit you
>      mentioned below.
>       
>  
>            
>           If I unload the "button" module, the system doesn't freeze, 
> but
>          it also
>           doesn't shut down.
>           I built "button" module by rolling back its version to 
> commit
>          1a20d40
>           <https://github.com/torvalds/linux/ <https://github.com/
>          torvalds/linux/>
>           commit/1a20d409c874255086e2f42a729826d490294c91>, which
>          corresponds to
>           kernel version 6.1. This module does not freeze, but does 
> not
>          turn off
>           the PC either.
>            
>           I've found that the freezes have been occurring since commit
>          0d51157
>           <https://github.com/torvalds/linux/ <https://github.com/
>          torvalds/linux/>
>           commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
>  
>  
>      That is 0d51157dfaac05 ("ACPI: button: Eliminate the driver 
> notify
>      callback") [v6.5-rc1] from Rafael. But that is a very old commit; 
> and
>      you seem to be switching distro versions and kernel at the same 
> time,
>      which could interfere.
>  
>      How did you find that this causes the problem? Did you do a 
> proper
>      bisection and thus checked if the parent of that commit really works?
>       
>  
>           Unfortunately, my skills are not enough to understand the
>          reason for the
>           freeze.
>            
>           I'm attaching dmesg and lspci logs.
>  
>      Ciao, Thorsten
> 

RE: Pressing the power button causes the device to freeze completely

[Sagatov, Evgeniy]

I'd also like to point out that without this patch, single-core CPU performance does drop.
In my case, it dropped by 30%. I tested it using 7z, stress-ng and sysbench.

-----Original Message-----
From: Sagatov, Evgeniy 
Sent: Monday, April 20, 2026 10:35 PM
To: 'Thorsten Leemhuis' <regressions@leemhuis.info>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; regressions@lists.linux.dev; LKML <linux-kernel@vger.kernel.org>; Michal Wilczynski <michal.wilczynski@intel.com>
Subject: RE: Pressing the power button causes the device to freeze completely

8c94ccc7cd691472461448f98e2372c75849406c    good
e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27    good
b0d326da462e20285236e11e4cbc32085de9f363    bad

I also built the stock Debian 13 kernel, version 6.12.74, and reverted commit b0d326da462e20285236e11e4cbc32085de9f363.
The PC shuts down without any issues with this kernel when pressing the power button.

----
Sincerely, Evgeny Sagatov

-----Original Message-----
From: Thorsten Leemhuis <regressions@leemhuis.info>
Sent: Monday, April 20, 2026 9:55 AM
To: Sagatov, Evgeniy <esagatov@amt.ru>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; regressions@lists.linux.dev; LKML <linux-kernel@vger.kernel.org>; Michal Wilczynski <michal.wilczynski@intel.com>
Subject: Re: Pressing the power button causes the device to freeze completely

On 4/20/26 08:41, Sagatov, Evgeniy wrote:
> Hello Thorsten,
> 
> Thanks for the detailed manual!
> 
> I determined that the problem started between versions 6.7.12 and 6.8-rc1. Then I ran a 'git bisect' according to the manual.
> 
> Result:
> b0d326da462e20285236e11e4cbc32085de9f363 is the first bad commit 
> commit b0d326da462e20285236e11e4cbc32085de9f363
> Merge: 8c94ccc7cd69 e37617c8e53a
> Author: Linus Torvalds <torvalds@linux-foundation.org>
> Date:   Thu Jan 18 11:57:33 2024 -0800
> 
>     Merge tag 'sched-urgent-2024-01-18' of 
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

This is a merge commit. This might be right, but often it is not. Can you please retest commits 8c94ccc7cd691472461448f98e2372c75849406c,
e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27 and
b0d326da462e20285236e11e4cbc32085de9f363 just to be sure and then share your results? tia!

Ciao Thorsten

>     Pull scheduler fix from Ingo Molnar:
>      "Fix a cpufreq related performance regression on certain systems, where
>       the CPU would remain at the lowest frequency, degrading performance
>       substantially"
> 
>     * tag 'sched-urgent-2024-01-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
>       sched/fair: Fix frequency selection for non-invariant case
> 
>  kernel/sched/cpufreq_schedutil.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> ----
> Sincerely, Evgeny Sagatov
> 
>  ----------------
> 16.04.2026, 20:35, Thorsten Leemhuis (mailto:regressions@leemhuis.info):
> To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki 
> (mailto:rafael.j.wysocki@intel.com);
> Copy: mailto:regressions@lists.linux.dev, LKML 
> (mailto:linux-kernel@vger.kernel.org), Michal Wilczynski 
> (mailto:michal.wilczynski@intel.com);
> Topic: Pressing the power button causes the device to freeze 
> completely;
>  
> On 4/16/26 19:22, Evgeny Sagatov wrote:
>  Could you please try 7.0 as well?
>  I compiled 7.0.0 kernel from sources.
>  Unfortunately, this kernel also freezes when the power button is pressed.
> 
> Thx for testing.
>   
>  How did you find that this causes the problem? Did you do a proper
>  bisection and thus checked if the parent of that commit really works?
>   
>  I don't think I did it correctly.
>  Because the previous commits didn't shut down the PC or cause it to
>  freeze. I think they just weren't working.
>   
>  I also tried a very simple module tity-power-button. Pressing the 
> power
>  button when using this module also causes a full freeze.
>  I think the problem lies with the ACPI functionality, but none of 
> kernel
>  options helped fix it.
>   
>  I'm confused.
> 
> Then you likely want to properly bisect the bug. Might be best to do 
> that on a Debian 12 install (where everything used to be working) by 
> following this guide:
> 
> https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions
> .html
> 
> But be warned: the regression is old. Even if the culprit is 
> identified the usual rules wrt to "no regression" might not apply, as 
> fixing the regression could cause regressions for other users.
> 
> Ciao, Thorsten
>  
>  ----------------
>  To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki
>  (mailto:rafael.j.wysocki@intel.com);
>  Copy: mailto:regressions@lists.linux.dev, LKML 
> (mailto:linux-kernel@vger.kernel.org),
>  Michal Wilczynski (mailto:michal.wilczynski@intel.com);
>  Topic: Pressing the power button causes the device to freeze 
> completely;
>  16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:regressions@leemhuis.info>:
>  
>      [removing the stable list, this is not something for them]
>  
>      On 4/13/26 18:46, Evgeny Sagatov wrote:
>  
>           I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0) 
> <https://
>           https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10
> <https://
>          https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10>>
> and
>          processor Intel
>           Core 2 Quad Q9550.
>           Previously, I had Debian 12 with kernel 6.1 installed, and
>          pressing the
>           power button would shut down the PC as usual.
>           I updated to Debian 13 with kernel 6.12.74, and now pressing
>          the power
>           button causes the PC to freeze completely.
>            
>           I see that systemd doesn't even begin to shut down. It 
> freezes
>           immediately after pressing the button. There's no error 
> message in
>           console. There's no error message in the logs either.
>          Netconsole doesn't
>           report any errors, and the kernel doesn't panic. It just
>          freezes completely.
>            
>           I checked that Live CD with Debian 12 continue to shut down
>          normally,
>           but Live CD with Debian 13 freeze.
>           I tried updating and resetting the BIOS. I tried various 
> kernel
>           parameters related to ACPI settings. I also tried kernels
> 6.18
>          and 6.19.
>           Nothing fixed the problem.
>  
>  
>      Could you please try 7.0 as well? It contains a fix for the 
> commit you
>      mentioned below.
>       
>  
>            
>           If I unload the "button" module, the system doesn't freeze, 
> but
>          it also
>           doesn't shut down.
>           I built "button" module by rolling back its version to 
> commit
>          1a20d40
>           <https://github.com/torvalds/linux/ <https://github.com/
>          torvalds/linux/>
>           commit/1a20d409c874255086e2f42a729826d490294c91>, which
>          corresponds to
>           kernel version 6.1. This module does not freeze, but does 
> not
>          turn off
>           the PC either.
>            
>           I've found that the freezes have been occurring since commit
>          0d51157
>           <https://github.com/torvalds/linux/ <https://github.com/
>          torvalds/linux/>
>           commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
>  
>  
>      That is 0d51157dfaac05 ("ACPI: button: Eliminate the driver 
> notify
>      callback") [v6.5-rc1] from Rafael. But that is a very old commit; 
> and
>      you seem to be switching distro versions and kernel at the same 
> time,
>      which could interfere.
>  
>      How did you find that this causes the problem? Did you do a 
> proper
>      bisection and thus checked if the parent of that commit really works?
>       
>  
>           Unfortunately, my skills are not enough to understand the
>          reason for the
>           freeze.
>            
>           I'm attaching dmesg and lspci logs.
>  
>      Ciao, Thorsten
> 

Re: Pressing the power button causes the device to freeze completely

[Thorsten Leemhuis]

On 4/21/26 00:20, Sagatov, Evgeniy wrote:
> I'd also like to point out that without this patch, single-core CPU performance does drop.
> In my case, it dropped by 30%. I tested it using 7z, stress-ng and sysbench.
> 
> -----Original Message-----
> From: Sagatov, Evgeniy 
> Sent: Monday, April 20, 2026 10:35 PM
> To: 'Thorsten Leemhuis' <regressions@leemhuis.info>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; regressions@lists.linux.dev; LKML <linux-kernel@vger.kernel.org>; Michal Wilczynski <michal.wilczynski@intel.com>
> Subject: RE: Pressing the power button causes the device to freeze completely
> 
> 8c94ccc7cd691472461448f98e2372c75849406c    good
> e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27    good
> b0d326da462e20285236e11e4cbc32085de9f363    bad
> 
> I also built the stock Debian 13 kernel, version 6.12.74, and reverted commit b0d326da462e20285236e11e4cbc32085de9f363.
> The PC shuts down without any issues with this kernel when pressing the power button.

Maybe there is nothing wrong with the code in those areas here, as it
might be a timing issue influenced by the performance change. But this
is not my domain, so consider that a wild guess -- Rafael might be
better judge here.

Overall I fear there might be not much we can do, unless someone comes
up with ideas how to debug the real issue.

Ciao, Thorsten

> -----Original Message-----
> From: Thorsten Leemhuis <regressions@leemhuis.info>
> Sent: Monday, April 20, 2026 9:55 AM
> To: Sagatov, Evgeniy <esagatov@amt.ru>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; regressions@lists.linux.dev; LKML <linux-kernel@vger.kernel.org>; Michal Wilczynski <michal.wilczynski@intel.com>
> Subject: Re: Pressing the power button causes the device to freeze completely
> 
> On 4/20/26 08:41, Sagatov, Evgeniy wrote:
>> Hello Thorsten,
>>
>> Thanks for the detailed manual!
>>
>> I determined that the problem started between versions 6.7.12 and 6.8-rc1. Then I ran a 'git bisect' according to the manual.
>>
>> Result:
>> b0d326da462e20285236e11e4cbc32085de9f363 is the first bad commit 
>> commit b0d326da462e20285236e11e4cbc32085de9f363
>> Merge: 8c94ccc7cd69 e37617c8e53a
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date:   Thu Jan 18 11:57:33 2024 -0800
>>
>>     Merge tag 'sched-urgent-2024-01-18' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> 
> This is a merge commit. This might be right, but often it is not. Can you please retest commits 8c94ccc7cd691472461448f98e2372c75849406c,
> e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27 and
> b0d326da462e20285236e11e4cbc32085de9f363 just to be sure and then share your results? tia!
> 
> Ciao Thorsten
> 
>>     Pull scheduler fix from Ingo Molnar:
>>      "Fix a cpufreq related performance regression on certain systems, where
>>       the CPU would remain at the lowest frequency, degrading performance
>>       substantially"
>>
>>     * tag 'sched-urgent-2024-01-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
>>       sched/fair: Fix frequency selection for non-invariant case
>>
>>  kernel/sched/cpufreq_schedutil.c | 6 +++++-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> ----
>> Sincerely, Evgeny Sagatov
>>
>>  ----------------
>> 16.04.2026, 20:35, Thorsten Leemhuis (mailto:regressions@leemhuis.info):
>> To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki 
>> (mailto:rafael.j.wysocki@intel.com);
>> Copy: mailto:regressions@lists.linux.dev, LKML 
>> (mailto:linux-kernel@vger.kernel.org), Michal Wilczynski 
>> (mailto:michal.wilczynski@intel.com);
>> Topic: Pressing the power button causes the device to freeze 
>> completely;
>>  
>> On 4/16/26 19:22, Evgeny Sagatov wrote:
>>  Could you please try 7.0 as well?
>>  I compiled 7.0.0 kernel from sources.
>>  Unfortunately, this kernel also freezes when the power button is pressed.
>>
>> Thx for testing.
>>   
>>  How did you find that this causes the problem? Did you do a proper
>>  bisection and thus checked if the parent of that commit really works?
>>   
>>  I don't think I did it correctly.
>>  Because the previous commits didn't shut down the PC or cause it to
>>  freeze. I think they just weren't working.
>>   
>>  I also tried a very simple module tity-power-button. Pressing the 
>> power
>>  button when using this module also causes a full freeze.
>>  I think the problem lies with the ACPI functionality, but none of 
>> kernel
>>  options helped fix it.
>>   
>>  I'm confused.
>>
>> Then you likely want to properly bisect the bug. Might be best to do 
>> that on a Debian 12 install (where everything used to be working) by 
>> following this guide:
>>
>> https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions
>> .html
>>
>> But be warned: the regression is old. Even if the culprit is 
>> identified the usual rules wrt to "no regression" might not apply, as 
>> fixing the regression could cause regressions for other users.
>>
>> Ciao, Thorsten
>>  
>>  ----------------
>>  To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki
>>  (mailto:rafael.j.wysocki@intel.com);
>>  Copy: mailto:regressions@lists.linux.dev, LKML 
>> (mailto:linux-kernel@vger.kernel.org),
>>  Michal Wilczynski (mailto:michal.wilczynski@intel.com);
>>  Topic: Pressing the power button causes the device to freeze 
>> completely;
>>  16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:regressions@leemhuis.info>:
>>  
>>      [removing the stable list, this is not something for them]
>>  
>>      On 4/13/26 18:46, Evgeny Sagatov wrote:
>>  
>>           I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0) 
>> <https://
>>           https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10
>> <https://
>>          https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10>>
>> and
>>          processor Intel
>>           Core 2 Quad Q9550.
>>           Previously, I had Debian 12 with kernel 6.1 installed, and
>>          pressing the
>>           power button would shut down the PC as usual.
>>           I updated to Debian 13 with kernel 6.12.74, and now pressing
>>          the power
>>           button causes the PC to freeze completely.
>>            
>>           I see that systemd doesn't even begin to shut down. It 
>> freezes
>>           immediately after pressing the button. There's no error 
>> message in
>>           console. There's no error message in the logs either.
>>          Netconsole doesn't
>>           report any errors, and the kernel doesn't panic. It just
>>          freezes completely.
>>            
>>           I checked that Live CD with Debian 12 continue to shut down
>>          normally,
>>           but Live CD with Debian 13 freeze.
>>           I tried updating and resetting the BIOS. I tried various 
>> kernel
>>           parameters related to ACPI settings. I also tried kernels
>> 6.18
>>          and 6.19.
>>           Nothing fixed the problem.
>>  
>>  
>>      Could you please try 7.0 as well? It contains a fix for the 
>> commit you
>>      mentioned below.
>>       
>>  
>>            
>>           If I unload the "button" module, the system doesn't freeze, 
>> but
>>          it also
>>           doesn't shut down.
>>           I built "button" module by rolling back its version to 
>> commit
>>          1a20d40
>>           <https://github.com/torvalds/linux/ <https://github.com/
>>          torvalds/linux/>
>>           commit/1a20d409c874255086e2f42a729826d490294c91>, which
>>          corresponds to
>>           kernel version 6.1. This module does not freeze, but does 
>> not
>>          turn off
>>           the PC either.
>>            
>>           I've found that the freezes have been occurring since commit
>>          0d51157
>>           <https://github.com/torvalds/linux/ <https://github.com/
>>          torvalds/linux/>
>>           commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
>>  
>>  
>>      That is 0d51157dfaac05 ("ACPI: button: Eliminate the driver 
>> notify
>>      callback") [v6.5-rc1] from Rafael. But that is a very old commit; 
>> and
>>      you seem to be switching distro versions and kernel at the same 
>> time,
>>      which could interfere.
>>  
>>      How did you find that this causes the problem? Did you do a 
>> proper
>>      bisection and thus checked if the parent of that commit really works?
>>       
>>  
>>           Unfortunately, my skills are not enough to understand the
>>          reason for the
>>           freeze.
>>            
>>           I'm attaching dmesg and lspci logs.
>>  
>>      Ciao, Thorsten
>>
> 
> 

RE: Pressing the power button causes the device to freeze completely

[Sagatov, Evgeniy]

I've added the committers to the conversation. Sorry if this is inconvenient.

----
Sincerely, Evgeny Sagatov

On 4/21/26 00:20, Sagatov, Evgeniy wrote:
> I'd also like to point out that without this patch, single-core CPU performance does drop.
> In my case, it dropped by 30%. I tested it using 7z, stress-ng and sysbench.
> 
> -----Original Message-----
> From: Sagatov, Evgeniy
> Sent: Monday, April 20, 2026 10:35 PM
> To: 'Thorsten Leemhuis' <regressions@leemhuis.info>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; 
> regressions@lists.linux.dev; LKML <linux-kernel@vger.kernel.org>; 
> Michal Wilczynski <michal.wilczynski@intel.com>
> Subject: RE: Pressing the power button causes the device to freeze 
> completely
> 
> 8c94ccc7cd691472461448f98e2372c75849406c    good
> e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27    good
> b0d326da462e20285236e11e4cbc32085de9f363    bad
> 
> I also built the stock Debian 13 kernel, version 6.12.74, and reverted commit b0d326da462e20285236e11e4cbc32085de9f363.
> The PC shuts down without any issues with this kernel when pressing the power button.

Maybe there is nothing wrong with the code in those areas here, as it might be a timing issue influenced by the performance change. But this is not my domain, so consider that a wild guess -- Rafael might be better judge here.

Overall I fear there might be not much we can do, unless someone comes up with ideas how to debug the real issue.

Ciao, Thorsten

> -----Original Message-----
> From: Thorsten Leemhuis <regressions@leemhuis.info>
> Sent: Monday, April 20, 2026 9:55 AM
> To: Sagatov, Evgeniy <esagatov@amt.ru>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>; 
> regressions@lists.linux.dev; LKML <linux-kernel@vger.kernel.org>; 
> Michal Wilczynski <michal.wilczynski@intel.com>
> Subject: Re: Pressing the power button causes the device to freeze 
> completely
> 
> On 4/20/26 08:41, Sagatov, Evgeniy wrote:
>> Hello Thorsten,
>>
>> Thanks for the detailed manual!
>>
>> I determined that the problem started between versions 6.7.12 and 6.8-rc1. Then I ran a 'git bisect' according to the manual.
>>
>> Result:
>> b0d326da462e20285236e11e4cbc32085de9f363 is the first bad commit 
>> commit b0d326da462e20285236e11e4cbc32085de9f363
>> Merge: 8c94ccc7cd69 e37617c8e53a
>> Author: Linus Torvalds <torvalds@linux-foundation.org>
>> Date:   Thu Jan 18 11:57:33 2024 -0800
>>
>>     Merge tag 'sched-urgent-2024-01-18' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> 
> This is a merge commit. This might be right, but often it is not. Can 
> you please retest commits 8c94ccc7cd691472461448f98e2372c75849406c,
> e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27 and
> b0d326da462e20285236e11e4cbc32085de9f363 just to be sure and then share your results? tia!
> 
> Ciao Thorsten
> 
>>     Pull scheduler fix from Ingo Molnar:
>>      "Fix a cpufreq related performance regression on certain systems, where
>>       the CPU would remain at the lowest frequency, degrading performance
>>       substantially"
>>
>>     * tag 'sched-urgent-2024-01-18' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
>>       sched/fair: Fix frequency selection for non-invariant case
>>
>>  kernel/sched/cpufreq_schedutil.c | 6 +++++-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> ----
>> Sincerely, Evgeny Sagatov
>>
>>  ----------------
>> 16.04.2026, 20:35, Thorsten Leemhuis (mailto:regressions@leemhuis.info):
>> To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki 
>> (mailto:rafael.j.wysocki@intel.com);
>> Copy: mailto:regressions@lists.linux.dev, LKML 
>> (mailto:linux-kernel@vger.kernel.org), Michal Wilczynski 
>> (mailto:michal.wilczynski@intel.com);
>> Topic: Pressing the power button causes the device to freeze 
>> completely;
>>  
>> On 4/16/26 19:22, Evgeny Sagatov wrote:
>>  Could you please try 7.0 as well?
>>  I compiled 7.0.0 kernel from sources.
>>  Unfortunately, this kernel also freezes when the power button is pressed.
>>
>> Thx for testing.
>>   
>>  How did you find that this causes the problem? Did you do a proper
>>  bisection and thus checked if the parent of that commit really works?
>>   
>>  I don't think I did it correctly.
>>  Because the previous commits didn't shut down the PC or cause it to
>>  freeze. I think they just weren't working.
>>   
>>  I also tried a very simple module tity-power-button. Pressing the 
>> power
>>  button when using this module also causes a full freeze.
>>  I think the problem lies with the ACPI functionality, but none of 
>> kernel
>>  options helped fix it.
>>   
>>  I'm confused.
>>
>> Then you likely want to properly bisect the bug. Might be best to do 
>> that on a Debian 12 install (where everything used to be working) by 
>> following this guide:
>>
>> https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regression
>> s
>> .html
>>
>> But be warned: the regression is old. Even if the culprit is 
>> identified the usual rules wrt to "no regression" might not apply, as 
>> fixing the regression could cause regressions for other users.
>>
>> Ciao, Thorsten
>>  
>>  ----------------
>>  To: Evgeny Sagatov (mailto:sagatov@ya.ru), Rafael J. Wysocki
>>  (mailto:rafael.j.wysocki@intel.com);
>>  Copy: mailto:regressions@lists.linux.dev, LKML 
>> (mailto:linux-kernel@vger.kernel.org),
>>  Michal Wilczynski (mailto:michal.wilczynski@intel.com);
>>  Topic: Pressing the power button causes the device to freeze 
>> completely;
>>  16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:regressions@leemhuis.info>:
>>  
>>      [removing the stable list, this is not something for them]
>>  
>>      On 4/13/26 18:46, Evgeny Sagatov wrote:
>>  
>>           I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0) 
>> <https://
>>           https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10
>> <https://
>>          https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10>>
>> and
>>          processor Intel
>>           Core 2 Quad Q9550.
>>           Previously, I had Debian 12 with kernel 6.1 installed, and
>>          pressing the
>>           power button would shut down the PC as usual.
>>           I updated to Debian 13 with kernel 6.12.74, and now 
>> pressing
>>          the power
>>           button causes the PC to freeze completely.
>>            
>>           I see that systemd doesn't even begin to shut down. It 
>> freezes
>>           immediately after pressing the button. There's no error 
>> message in
>>           console. There's no error message in the logs either.
>>          Netconsole doesn't
>>           report any errors, and the kernel doesn't panic. It just
>>          freezes completely.
>>            
>>           I checked that Live CD with Debian 12 continue to shut down
>>          normally,
>>           but Live CD with Debian 13 freeze.
>>           I tried updating and resetting the BIOS. I tried various 
>> kernel
>>           parameters related to ACPI settings. I also tried kernels
>> 6.18
>>          and 6.19.
>>           Nothing fixed the problem.
>>  
>>  
>>      Could you please try 7.0 as well? It contains a fix for the 
>> commit you
>>      mentioned below.
>>       
>>  
>>            
>>           If I unload the "button" module, the system doesn't freeze, 
>> but
>>          it also
>>           doesn't shut down.
>>           I built "button" module by rolling back its version to 
>> commit
>>          1a20d40
>>           <https://github.com/torvalds/linux/ <https://github.com/
>>          torvalds/linux/>
>>           commit/1a20d409c874255086e2f42a729826d490294c91>, which
>>          corresponds to
>>           kernel version 6.1. This module does not freeze, but does 
>> not
>>          turn off
>>           the PC either.
>>            
>>           I've found that the freezes have been occurring since 
>> commit
>>          0d51157
>>           <https://github.com/torvalds/linux/ <https://github.com/
>>          torvalds/linux/>
>>           commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
>>  
>>  
>>      That is 0d51157dfaac05 ("ACPI: button: Eliminate the driver 
>> notify
>>      callback") [v6.5-rc1] from Rafael. But that is a very old 
>> commit; and
>>      you seem to be switching distro versions and kernel at the same 
>> time,
>>      which could interfere.
>>  
>>      How did you find that this causes the problem? Did you do a 
>> proper
>>      bisection and thus checked if the parent of that commit really works?
>>       
>>  
>>           Unfortunately, my skills are not enough to understand the
>>          reason for the
>>           freeze.
>>            
>>           I'm attaching dmesg and lspci logs.
>>  
>>      Ciao, Thorsten
>>
> 
> 

Re: Pressing the power button causes the device to freeze completely

[Wysocki, Rafael J]

Hi,

On 4/13/2026 6:46 PM, Evgeny Sagatov wrote:
> Hello,
> I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0) 
> <https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10> and 
> processor Intel Core 2 Quad Q9550.
> Previously, I had Debian 12 with kernel 6.1 installed, and pressing 
> the power button would shut down the PC as usual.
> I updated to Debian 13 with kernel 6.12.74, and now pressing the power 
> button causes the PC to freeze completely.
> I see that systemd doesn't even begin to shut down. It freezes 
> immediately after pressing the button. There's no error message in 
> console. There's no error message in the logs either. Netconsole 
> doesn't report any errors, and the kernel doesn't panic. It just 
> freezes completely.

It looks like the ACPI button notify handler crashes on your system for 
some obscure reason.

It should be possible to get to the bottom of it, but it will require 
some investigation if you have the motivation and time to run debug patches.


> I checked that Live CD with Debian 12 continue to shut down normally, 
> but Live CD with Debian 13 freeze.
> I tried updating and resetting the BIOS. I tried various kernel 
> parameters related to ACPI settings. I also tried kernels 6.18 and 
> 6.19. Nothing fixed the problem.
> If I unload the "button" module, the system doesn't freeze, but it 
> also doesn't shut down.

This is a useful data point, thanks!


> I built "button" module by rolling back its version to commit 1a20d40 
> <https://github.com/torvalds/linux/commit/1a20d409c874255086e2f42a729826d490294c91>, 
> which corresponds to kernel version 6.1. This module does not freeze, 
> but does not turn off the PC either.
> I've found that the freezes have been occurring since commit 0d51157 
> <https://github.com/torvalds/linux/commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.

The main difference made by it is the fixed events handling and if there 
is a problem with that, a few debug patches should suffice to find out 
what's going on.  I'll send you one to try shortly.

Thanks, Rafael

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Tuesday, April 21, 2026 5:11:36 PM CEST Wysocki, Rafael J wrote:
> Hi,
> 
> On 4/13/2026 6:46 PM, Evgeny Sagatov wrote:
> > Hello,
> > I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0) 
> > <https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10> and 
> > processor Intel Core 2 Quad Q9550.
> > Previously, I had Debian 12 with kernel 6.1 installed, and pressing 
> > the power button would shut down the PC as usual.
> > I updated to Debian 13 with kernel 6.12.74, and now pressing the power 
> > button causes the PC to freeze completely.
> > I see that systemd doesn't even begin to shut down. It freezes 
> > immediately after pressing the button. There's no error message in 
> > console. There's no error message in the logs either. Netconsole 
> > doesn't report any errors, and the kernel doesn't panic. It just 
> > freezes completely.
> 
> It looks like the ACPI button notify handler crashes on your system for 
> some obscure reason.
> 
> It should be possible to get to the bottom of it, but it will require 
> some investigation if you have the motivation and time to run debug patches.
> 
> 
> > I checked that Live CD with Debian 12 continue to shut down normally, 
> > but Live CD with Debian 13 freeze.
> > I tried updating and resetting the BIOS. I tried various kernel 
> > parameters related to ACPI settings. I also tried kernels 6.18 and 
> > 6.19. Nothing fixed the problem.
> > If I unload the "button" module, the system doesn't freeze, but it 
> > also doesn't shut down.
> 
> This is a useful data point, thanks!
> 
> 
> > I built "button" module by rolling back its version to commit 1a20d40 
> > <https://github.com/torvalds/linux/commit/1a20d409c874255086e2f42a729826d490294c91>, 
> > which corresponds to kernel version 6.1. This module does not freeze, 
> > but does not turn off the PC either.
> > I've found that the freezes have been occurring since commit 0d51157 
> > <https://github.com/torvalds/linux/commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
> 
> The main difference made by it is the fixed events handling and if there 
> is a problem with that, a few debug patches should suffice to find out 
> what's going on.  I'll send you one to try shortly.

First off, on top of 7.0.0 (since the issue is present in this one, I think
it's better to focus the debugging on it), let's first check what happens if
the ACPI fixed event handler is not installed for the power button at all.

This should be similar to using a 6.1 version of the button driver (that is,
no crash, but pressing the power button will have no effect).

Please test the patch below and let me know what happens.

---
 drivers/acpi/button.c |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -628,9 +628,7 @@ static int acpi_button_probe(struct plat
 
 	switch (device->device_type) {
 	case ACPI_BUS_TYPE_POWER_BUTTON:
-		status = acpi_install_fixed_event_handler(ACPI_EVENT_POWER_BUTTON,
-							  acpi_button_event,
-							  button);
+		status = AE_OK;
 		break;
 	case ACPI_BUS_TYPE_SLEEP_BUTTON:
 		status = acpi_install_fixed_event_handler(ACPI_EVENT_SLEEP_BUTTON,

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

Hello Rafael,

I applied the patch that you sent.
The PC isn't responding to the power button press. It doesn't freeze.

I just want to clarify, did you receive messages where we found the
first broken commit using git bisect?

> 8c94ccc7cd691472461448f98e2372c75849406c    good
> e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27    good
> b0d326da462e20285236e11e4cbc32085de9f363    bad

I'm getting messages that my emails couldn't be delivered, so I'm
using another email address.

----
Sincerely, Evgeny Sagatov

> On Tuesday, April 21, 2026 5:11:36 PM CEST Wysocki, Rafael J wrote:
>
>  Hi,
>
>  On 4/13/2026 6:46 PM, Evgeny Sagatov wrote:
>  > Hello,
>  > I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0)
>  > <https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10> and
>  > processor Intel Core 2 Quad Q9550.
>  > Previously, I had Debian 12 with kernel 6.1 installed, and pressing
>  > the power button would shut down the PC as usual.
>  > I updated to Debian 13 with kernel 6.12.74, and now pressing the power
>  > button causes the PC to freeze completely.
>  > I see that systemd doesn't even begin to shut down. It freezes
>  > immediately after pressing the button. There's no error message in
>  > console. There's no error message in the logs either. Netconsole
>  > doesn't report any errors, and the kernel doesn't panic. It just
>  > freezes completely.
>
>  It looks like the ACPI button notify handler crashes on your system for
>  some obscure reason.
>
>  It should be possible to get to the bottom of it, but it will require
>  some investigation if you have the motivation and time to run debug patches.
>
>
>  > I checked that Live CD with Debian 12 continue to shut down normally,
>  > but Live CD with Debian 13 freeze.
>  > I tried updating and resetting the BIOS. I tried various kernel
>  > parameters related to ACPI settings. I also tried kernels 6.18 and
>  > 6.19. Nothing fixed the problem.
>  > If I unload the "button" module, the system doesn't freeze, but it
>  > also doesn't shut down.
>
>  This is a useful data point, thanks!
>
>
>  > I built "button" module by rolling back its version to commit 1a20d40
>  > <https://github.com/torvalds/linux/commit/1a20d409c874255086e2f42a729826d490294c91>,
>  > which corresponds to kernel version 6.1. This module does not freeze,
>  > but does not turn off the PC either.
>  > I've found that the freezes have been occurring since commit 0d51157
>  > <https://github.com/torvalds/linux/commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
>
>  The main difference made by it is the fixed events handling and if there
>  is a problem with that, a few debug patches should suffice to find out
>  what's going on. I'll send you one to try shortly.
>
>
> First off, on top of 7.0.0 (since the issue is present in this one, I think
> it's better to focus the debugging on it), let's first check what happens if
> the ACPI fixed event handler is not installed for the power button at all.
>
> This should be similar to using a 6.1 version of the button driver (that is,
> no crash, but pressing the power button will have no effect).
>
> Please test the patch below and let me know what happens.
>
> ---
>  drivers/acpi/button.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -628,9 +628,7 @@ static int acpi_button_probe(struct plat
>
>          switch (device->device_type) {
>          case ACPI_BUS_TYPE_POWER_BUTTON:
> - status = acpi_install_fixed_event_handler(ACPI_EVENT_POWER_BUTTON,
> - acpi_button_event,
> - button);
> + status = AE_OK;
>                  break;
>          case ACPI_BUS_TYPE_SLEEP_BUTTON:
>                  status = acpi_install_fixed_event_handler(ACPI_EVENT_SLEEP_BUTTON,
>
>
>
>
>
> -------- Конец пересылаемого сообщения --------

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

Hi,

On Wed, Apr 22, 2026 at 2:36 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
>
> Hello Rafael,
>
> I applied the patch that you sent.
> The PC isn't responding to the power button press. It doesn't freeze.

As expected, thanks!  I'll send you another patch to test (instead of
the one you have tested) in the next message.

> I just want to clarify, did you receive messages where we found the
> first broken commit using git bisect?
>
> > 8c94ccc7cd691472461448f98e2372c75849406c    good
> > e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27    good
> > b0d326da462e20285236e11e4cbc32085de9f363    bad

Yes, I did, but I think that reverting the schedutil change hides the problem.

BTW, since reverting the schedutil change makes a difference for you,
I'm wondering about the cpufreq configuration on your system.  Can you
please send me the

$ grep -r . /sys/devices/system/cpu/cpufreq/

output from your system?


> > On Tuesday, April 21, 2026 5:11:36 PM CEST Wysocki, Rafael J wrote:
> >
> >  Hi,
> >
> >  On 4/13/2026 6:46 PM, Evgeny Sagatov wrote:
> >  > Hello,
> >  > I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0)
> >  > <https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10> and
> >  > processor Intel Core 2 Quad Q9550.
> >  > Previously, I had Debian 12 with kernel 6.1 installed, and pressing
> >  > the power button would shut down the PC as usual.
> >  > I updated to Debian 13 with kernel 6.12.74, and now pressing the power
> >  > button causes the PC to freeze completely.
> >  > I see that systemd doesn't even begin to shut down. It freezes
> >  > immediately after pressing the button. There's no error message in
> >  > console. There's no error message in the logs either. Netconsole
> >  > doesn't report any errors, and the kernel doesn't panic. It just
> >  > freezes completely.
> >
> >  It looks like the ACPI button notify handler crashes on your system for
> >  some obscure reason.
> >
> >  It should be possible to get to the bottom of it, but it will require
> >  some investigation if you have the motivation and time to run debug patches.
> >
> >
> >  > I checked that Live CD with Debian 12 continue to shut down normally,
> >  > but Live CD with Debian 13 freeze.
> >  > I tried updating and resetting the BIOS. I tried various kernel
> >  > parameters related to ACPI settings. I also tried kernels 6.18 and
> >  > 6.19. Nothing fixed the problem.
> >  > If I unload the "button" module, the system doesn't freeze, but it
> >  > also doesn't shut down.
> >
> >  This is a useful data point, thanks!
> >
> >
> >  > I built "button" module by rolling back its version to commit 1a20d40
> >  > <https://github.com/torvalds/linux/commit/1a20d409c874255086e2f42a729826d490294c91>,
> >  > which corresponds to kernel version 6.1. This module does not freeze,
> >  > but does not turn off the PC either.
> >  > I've found that the freezes have been occurring since commit 0d51157
> >  > <https://github.com/torvalds/linux/commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
> >
> >  The main difference made by it is the fixed events handling and if there
> >  is a problem with that, a few debug patches should suffice to find out
> >  what's going on. I'll send you one to try shortly.
> >
> >
> > First off, on top of 7.0.0 (since the issue is present in this one, I think
> > it's better to focus the debugging on it), let's first check what happens if
> > the ACPI fixed event handler is not installed for the power button at all.
> >
> > This should be similar to using a 6.1 version of the button driver (that is,
> > no crash, but pressing the power button will have no effect).
> >
> > Please test the patch below and let me know what happens.
> >
> > ---
> >  drivers/acpi/button.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > --- a/drivers/acpi/button.c
> > +++ b/drivers/acpi/button.c
> > @@ -628,9 +628,7 @@ static int acpi_button_probe(struct plat
> >
> >          switch (device->device_type) {
> >          case ACPI_BUS_TYPE_POWER_BUTTON:
> > - status = acpi_install_fixed_event_handler(ACPI_EVENT_POWER_BUTTON,
> > - acpi_button_event,
> > - button);
> > + status = AE_OK;
> >                  break;
> >          case ACPI_BUS_TYPE_SLEEP_BUTTON:
> >                  status = acpi_install_fixed_event_handler(ACPI_EVENT_SLEEP_BUTTON,
> >
> >
> >
> >
> >
> > -------- Конец пересылаемого сообщения --------

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

# grep -r . /sys/devices/system/cpu/cpufreq/
/sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
/sys/devices/system/cpu/cpufreq/policy2/scaling_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy2/scaling_available_governors:performance
schedutil
/sys/devices/system/cpu/cpufreq/policy2/freqdomain_cpus:2
/sys/devices/system/cpu/cpufreq/policy2/scaling_governor:schedutil
/sys/devices/system/cpu/cpufreq/policy2/cpuinfo_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy2/scaling_available_frequencies:2834000
2000000
/sys/devices/system/cpu/cpufreq/policy2/related_cpus:2
/sys/devices/system/cpu/cpufreq/policy2/scaling_cur_freq:2000088
/sys/devices/system/cpu/cpufreq/policy2/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpufreq/policy2/stats/reset: Access denied
/sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:   From  :    To
/sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:         :
2834000   2000000
/sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2834000:
      0       762
/sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2000000:
    761         0
/sys/devices/system/cpu/cpufreq/policy2/stats/total_trans:1523
/sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2834000 6606
/sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2000000 248733
/sys/devices/system/cpu/cpufreq/policy2/affected_cpus:2
/sys/devices/system/cpu/cpufreq/policy2/scaling_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy2/cpuinfo_transition_latency:160000
/sys/devices/system/cpu/cpufreq/policy2/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy2/cpuinfo_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy2/bios_limit:2834000
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:performance
schedutil
/sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:schedutil
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:2834000
2000000
/sys/devices/system/cpu/cpufreq/policy0/related_cpus:0
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Access denied
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:   From  :    To
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:         :
2834000   2000000
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2834000:
      0       850
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
    849         0
/sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:1699
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 6684
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 248654
/sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:160000
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000
/sys/devices/system/cpu/cpufreq/policy3/scaling_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy3/scaling_available_governors:performance
schedutil
/sys/devices/system/cpu/cpufreq/policy3/freqdomain_cpus:3
/sys/devices/system/cpu/cpufreq/policy3/scaling_governor:schedutil
/sys/devices/system/cpu/cpufreq/policy3/cpuinfo_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy3/scaling_available_frequencies:2834000
2000000
/sys/devices/system/cpu/cpufreq/policy3/related_cpus:3
/sys/devices/system/cpu/cpufreq/policy3/scaling_cur_freq:1999770
/sys/devices/system/cpu/cpufreq/policy3/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpufreq/policy3/stats/reset: Access denied
/sys/devices/system/cpu/cpufreq/policy3/stats/trans_table:   From  :    To
/sys/devices/system/cpu/cpufreq/policy3/stats/trans_table:         :
2834000   2000000
/sys/devices/system/cpu/cpufreq/policy3/stats/trans_table:  2834000:
      0       623
/sys/devices/system/cpu/cpufreq/policy3/stats/trans_table:  2000000:
    622         0
/sys/devices/system/cpu/cpufreq/policy3/stats/total_trans:1245
/sys/devices/system/cpu/cpufreq/policy3/stats/time_in_state:2834000 6697
/sys/devices/system/cpu/cpufreq/policy3/stats/time_in_state:2000000 248642
/sys/devices/system/cpu/cpufreq/policy3/affected_cpus:3
/sys/devices/system/cpu/cpufreq/policy3/scaling_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy3/cpuinfo_transition_latency:160000
/sys/devices/system/cpu/cpufreq/policy3/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy3/cpuinfo_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy3/bios_limit:2834000
/sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy1/scaling_available_governors:performance
schedutil
/sys/devices/system/cpu/cpufreq/policy1/freqdomain_cpus:1
/sys/devices/system/cpu/cpufreq/policy1/scaling_governor:schedutil
/sys/devices/system/cpu/cpufreq/policy1/cpuinfo_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy1/scaling_available_frequencies:2834000
2000000
/sys/devices/system/cpu/cpufreq/policy1/related_cpus:1
/sys/devices/system/cpu/cpufreq/policy1/scaling_cur_freq:1999773
/sys/devices/system/cpu/cpufreq/policy1/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpufreq/policy1/stats/reset: Access denied
/sys/devices/system/cpu/cpufreq/policy1/stats/trans_table:   From  :    To
/sys/devices/system/cpu/cpufreq/policy1/stats/trans_table:         :
2834000   2000000
/sys/devices/system/cpu/cpufreq/policy1/stats/trans_table:  2834000:
      0       882
/sys/devices/system/cpu/cpufreq/policy1/stats/trans_table:  2000000:
    881         0
/sys/devices/system/cpu/cpufreq/policy1/stats/total_trans:1763
/sys/devices/system/cpu/cpufreq/policy1/stats/time_in_state:2834000 5501
/sys/devices/system/cpu/cpufreq/policy1/stats/time_in_state:2000000 249838
/sys/devices/system/cpu/cpufreq/policy1/affected_cpus:1
/sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy1/cpuinfo_transition_latency:160000
/sys/devices/system/cpu/cpufreq/policy1/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy1/cpuinfo_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy1/bios_limit:2834000

ср, 22 апр. 2026 г. в 16:27, Rafael J. Wysocki <rafael@kernel.org>:
>
> Hi,
>
> On Wed, Apr 22, 2026 at 2:36 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
> >
> > Hello Rafael,
> >
> > I applied the patch that you sent.
> > The PC isn't responding to the power button press. It doesn't freeze.
>
> As expected, thanks!  I'll send you another patch to test (instead of
> the one you have tested) in the next message.
>
> > I just want to clarify, did you receive messages where we found the
> > first broken commit using git bisect?
> >
> > > 8c94ccc7cd691472461448f98e2372c75849406c    good
> > > e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27    good
> > > b0d326da462e20285236e11e4cbc32085de9f363    bad
>
> Yes, I did, but I think that reverting the schedutil change hides the problem.
>
> BTW, since reverting the schedutil change makes a difference for you,
> I'm wondering about the cpufreq configuration on your system.  Can you
> please send me the
>
> $ grep -r . /sys/devices/system/cpu/cpufreq/
>
> output from your system?
>
>
> > > On Tuesday, April 21, 2026 5:11:36 PM CEST Wysocki, Rafael J wrote:
> > >
> > >  Hi,
> > >
> > >  On 4/13/2026 6:46 PM, Evgeny Sagatov wrote:
> > >  > Hello,
> > >  > I have a PC with a motherboard GA-EP45T-UD3LR (Rev. 1.0)
> > >  > <https://www.gigabyte.com/Motherboard/GA-EP45T-UD3LR-rev-10> and
> > >  > processor Intel Core 2 Quad Q9550.
> > >  > Previously, I had Debian 12 with kernel 6.1 installed, and pressing
> > >  > the power button would shut down the PC as usual.
> > >  > I updated to Debian 13 with kernel 6.12.74, and now pressing the power
> > >  > button causes the PC to freeze completely.
> > >  > I see that systemd doesn't even begin to shut down. It freezes
> > >  > immediately after pressing the button. There's no error message in
> > >  > console. There's no error message in the logs either. Netconsole
> > >  > doesn't report any errors, and the kernel doesn't panic. It just
> > >  > freezes completely.
> > >
> > >  It looks like the ACPI button notify handler crashes on your system for
> > >  some obscure reason.
> > >
> > >  It should be possible to get to the bottom of it, but it will require
> > >  some investigation if you have the motivation and time to run debug patches.
> > >
> > >
> > >  > I checked that Live CD with Debian 12 continue to shut down normally,
> > >  > but Live CD with Debian 13 freeze.
> > >  > I tried updating and resetting the BIOS. I tried various kernel
> > >  > parameters related to ACPI settings. I also tried kernels 6.18 and
> > >  > 6.19. Nothing fixed the problem.
> > >  > If I unload the "button" module, the system doesn't freeze, but it
> > >  > also doesn't shut down.
> > >
> > >  This is a useful data point, thanks!
> > >
> > >
> > >  > I built "button" module by rolling back its version to commit 1a20d40
> > >  > <https://github.com/torvalds/linux/commit/1a20d409c874255086e2f42a729826d490294c91>,
> > >  > which corresponds to kernel version 6.1. This module does not freeze,
> > >  > but does not turn off the PC either.
> > >  > I've found that the freezes have been occurring since commit 0d51157
> > >  > <https://github.com/torvalds/linux/commit/0d51157dfaac05ea66616d8a250dce04bef49a4f>.
> > >
> > >  The main difference made by it is the fixed events handling and if there
> > >  is a problem with that, a few debug patches should suffice to find out
> > >  what's going on. I'll send you one to try shortly.
> > >
> > >
> > > First off, on top of 7.0.0 (since the issue is present in this one, I think
> > > it's better to focus the debugging on it), let's first check what happens if
> > > the ACPI fixed event handler is not installed for the power button at all.
> > >
> > > This should be similar to using a 6.1 version of the button driver (that is,
> > > no crash, but pressing the power button will have no effect).
> > >
> > > Please test the patch below and let me know what happens.
> > >
> > > ---
> > >  drivers/acpi/button.c | 4 +---
> > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > --- a/drivers/acpi/button.c
> > > +++ b/drivers/acpi/button.c
> > > @@ -628,9 +628,7 @@ static int acpi_button_probe(struct plat
> > >
> > >          switch (device->device_type) {
> > >          case ACPI_BUS_TYPE_POWER_BUTTON:
> > > - status = acpi_install_fixed_event_handler(ACPI_EVENT_POWER_BUTTON,
> > > - acpi_button_event,
> > > - button);
> > > + status = AE_OK;
> > >                  break;
> > >          case ACPI_BUS_TYPE_SLEEP_BUTTON:
> > >                  status = acpi_install_fixed_event_handler(ACPI_EVENT_SLEEP_BUTTON,

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Wed, Apr 22, 2026 at 3:34 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
>
> # grep -r . /sys/devices/system/cpu/cpufreq/
> /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
> /sys/devices/system/cpu/cpufreq/policy2/scaling_min_freq:2000000
> /sys/devices/system/cpu/cpufreq/policy2/scaling_available_governors:performance
> schedutil

There are two cpufreq governors to choose from.  Have you decided to
compile out the other ones on purpose?

It might be useful to compile the powersave governor in and try to
switch over to it (on all CPUs) before pressing the power button
(without any patches applied).

> /sys/devices/system/cpu/cpufreq/policy2/freqdomain_cpus:2
> /sys/devices/system/cpu/cpufreq/policy2/scaling_governor:schedutil
> /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_max_freq:2834000
> /sys/devices/system/cpu/cpufreq/policy2/scaling_available_frequencies:2834000
> 2000000

The frequency scaling on this CPU is quite limited (only 2 states to
choose from).

> /sys/devices/system/cpu/cpufreq/policy2/related_cpus:2
> /sys/devices/system/cpu/cpufreq/policy2/scaling_cur_freq:2000088

Interestingly, this number doesn't match the available choices (maybe
due to a rounding error or similar).

> /sys/devices/system/cpu/cpufreq/policy2/scaling_setspeed:<unsupported>
> grep: /sys/devices/system/cpu/cpufreq/policy2/stats/reset: Access denied
> /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:   From  :    To
> /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:         :
> 2834000   2000000
> /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2834000:
>       0       762
> /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2000000:
>     761         0
> /sys/devices/system/cpu/cpufreq/policy2/stats/total_trans:1523
> /sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2834000 6606
> /sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2000000 248733
> /sys/devices/system/cpu/cpufreq/policy2/affected_cpus:2
> /sys/devices/system/cpu/cpufreq/policy2/scaling_max_freq:2834000
> /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_transition_latency:160000
> /sys/devices/system/cpu/cpufreq/policy2/scaling_driver:acpi-cpufreq
> /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_min_freq:2000000
> /sys/devices/system/cpu/cpufreq/policy2/bios_limit:2834000

The fact that acpi-cpufreq is the scaling driver may be related to the
power button issue in principle.

I'm still going to send you another debug patch for the button driver though.

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

> There are two cpufreq governors to choose from.  Have you decided to compile out the other ones on purpose?

Powersave is compiled into the stock Debian kernel as a module, so it
does not appear in this list.

I changed governor to powersave and pressed the power button. The PC
shut down normally.

ср, 22 апр. 2026 г. в 17:04, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Wed, Apr 22, 2026 at 3:34 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
> >
> > # grep -r . /sys/devices/system/cpu/cpufreq/
> > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
> > /sys/devices/system/cpu/cpufreq/policy2/scaling_min_freq:2000000
> > /sys/devices/system/cpu/cpufreq/policy2/scaling_available_governors:performance
> > schedutil
>
> There are two cpufreq governors to choose from.  Have you decided to
> compile out the other ones on purpose?
>
> It might be useful to compile the powersave governor in and try to
> switch over to it (on all CPUs) before pressing the power button
> (without any patches applied).
>
> > /sys/devices/system/cpu/cpufreq/policy2/freqdomain_cpus:2
> > /sys/devices/system/cpu/cpufreq/policy2/scaling_governor:schedutil
> > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_max_freq:2834000
> > /sys/devices/system/cpu/cpufreq/policy2/scaling_available_frequencies:2834000
> > 2000000
>
> The frequency scaling on this CPU is quite limited (only 2 states to
> choose from).
>
> > /sys/devices/system/cpu/cpufreq/policy2/related_cpus:2
> > /sys/devices/system/cpu/cpufreq/policy2/scaling_cur_freq:2000088
>
> Interestingly, this number doesn't match the available choices (maybe
> due to a rounding error or similar).
>
> > /sys/devices/system/cpu/cpufreq/policy2/scaling_setspeed:<unsupported>
> > grep: /sys/devices/system/cpu/cpufreq/policy2/stats/reset: Access denied
> > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:   From  :    To
> > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:         :
> > 2834000   2000000
> > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2834000:
> >       0       762
> > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2000000:
> >     761         0
> > /sys/devices/system/cpu/cpufreq/policy2/stats/total_trans:1523
> > /sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2834000 6606
> > /sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2000000 248733
> > /sys/devices/system/cpu/cpufreq/policy2/affected_cpus:2
> > /sys/devices/system/cpu/cpufreq/policy2/scaling_max_freq:2834000
> > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_transition_latency:160000
> > /sys/devices/system/cpu/cpufreq/policy2/scaling_driver:acpi-cpufreq
> > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_min_freq:2000000
> > /sys/devices/system/cpu/cpufreq/policy2/bios_limit:2834000
>
> The fact that acpi-cpufreq is the scaling driver may be related to the
> power button issue in principle.
>
> I'm still going to send you another debug patch for the button driver though.

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Wednesday, April 22, 2026 4:48:41 PM CEST Evgeny Sagatov wrote:
> > There are two cpufreq governors to choose from.  Have you decided to compile out the other ones on purpose?
> 
> Powersave is compiled into the stock Debian kernel as a module, so it
> does not appear in this list.
> 
> I changed governor to powersave and pressed the power button. The PC
> shut down normally.

Interesting.

Can you please also check what happens if you change the cpufreq governor
to "performance" (on all CPUs) before pressing the power button?

The difference is that with the "performance" governor the CPUs will be
running at the highest frequency.

> ср, 22 апр. 2026 г. в 17:04, Rafael J. Wysocki <rafael@kernel.org>:
> >
> > On Wed, Apr 22, 2026 at 3:34 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
> > >
> > > # grep -r . /sys/devices/system/cpu/cpufreq/
> > > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
> > > /sys/devices/system/cpu/cpufreq/policy2/scaling_min_freq:2000000
> > > /sys/devices/system/cpu/cpufreq/policy2/scaling_available_governors:performance
> > > schedutil
> >
> > There are two cpufreq governors to choose from.  Have you decided to
> > compile out the other ones on purpose?
> >
> > It might be useful to compile the powersave governor in and try to
> > switch over to it (on all CPUs) before pressing the power button
> > (without any patches applied).
> >
> > > /sys/devices/system/cpu/cpufreq/policy2/freqdomain_cpus:2
> > > /sys/devices/system/cpu/cpufreq/policy2/scaling_governor:schedutil
> > > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_max_freq:2834000
> > > /sys/devices/system/cpu/cpufreq/policy2/scaling_available_frequencies:2834000
> > > 2000000
> >
> > The frequency scaling on this CPU is quite limited (only 2 states to
> > choose from).
> >
> > > /sys/devices/system/cpu/cpufreq/policy2/related_cpus:2
> > > /sys/devices/system/cpu/cpufreq/policy2/scaling_cur_freq:2000088
> >
> > Interestingly, this number doesn't match the available choices (maybe
> > due to a rounding error or similar).
> >
> > > /sys/devices/system/cpu/cpufreq/policy2/scaling_setspeed:<unsupported>
> > > grep: /sys/devices/system/cpu/cpufreq/policy2/stats/reset: Access denied
> > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:   From  :    To
> > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:         :
> > > 2834000   2000000
> > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2834000:
> > >       0       762
> > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2000000:
> > >     761         0
> > > /sys/devices/system/cpu/cpufreq/policy2/stats/total_trans:1523
> > > /sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2834000 6606
> > > /sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2000000 248733
> > > /sys/devices/system/cpu/cpufreq/policy2/affected_cpus:2
> > > /sys/devices/system/cpu/cpufreq/policy2/scaling_max_freq:2834000
> > > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_transition_latency:160000
> > > /sys/devices/system/cpu/cpufreq/policy2/scaling_driver:acpi-cpufreq
> > > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_min_freq:2000000
> > > /sys/devices/system/cpu/cpufreq/policy2/bios_limit:2834000
> >
> > The fact that acpi-cpufreq is the scaling driver may be related to the
> > power button issue in principle.
> >
> > I'm still going to send you another debug patch for the button driver though.

So the patch is appended.  It causes a message to be printed into the kernel
log every time the power button is pressed if all goes well, but the system
will not shut down (it is also not expected to hang).

Please see if that happens with the patch applied (it is a replacement for the
previous debug patch).  In principle it should work without changing the
cpufreq governor.

---
 drivers/acpi/button.c |   10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -473,14 +473,12 @@ static void acpi_button_notify(acpi_hand
 					event, ++button->pushed);
 }
 
-static void acpi_button_notify_run(void *data)
-{
-	acpi_button_notify(NULL, ACPI_BUTTON_NOTIFY_STATUS, data);
-}
-
 static u32 acpi_button_event(void *data)
 {
-	acpi_os_execute(OSL_NOTIFY_HANDLER, acpi_button_notify_run, data);
+	struct acpi_button *button = data;
+
+	dev_info(button->dev, "ACPI button event\n");
+
 	return ACPI_INTERRUPT_HANDLED;
 }
 

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

I removed the previous patch and installed the new one in kernel 7.0.0.
schedutil - complete freeze, no messages in the log
performance - log message when pressing power button, doesn't reboot
ondemand - log message when pressing power button, doesn't reboot

Log: apr 23 17:40:04 srv kernel: acpi-button LNXPWRBN:00: ACPI button event

чт, 23 апр. 2026 г. в 16:17, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Wednesday, April 22, 2026 4:48:41 PM CEST Evgeny Sagatov wrote:
> > > There are two cpufreq governors to choose from.  Have you decided to compile out the other ones on purpose?
> >
> > Powersave is compiled into the stock Debian kernel as a module, so it
> > does not appear in this list.
> >
> > I changed governor to powersave and pressed the power button. The PC
> > shut down normally.
>
> Interesting.
>
> Can you please also check what happens if you change the cpufreq governor
> to "performance" (on all CPUs) before pressing the power button?
>
> The difference is that with the "performance" governor the CPUs will be
> running at the highest frequency.
>
> > ср, 22 апр. 2026 г. в 17:04, Rafael J. Wysocki <rafael@kernel.org>:
> > >
> > > On Wed, Apr 22, 2026 at 3:34 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
> > > >
> > > > # grep -r . /sys/devices/system/cpu/cpufreq/
> > > > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_min_freq:2000000
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_available_governors:performance
> > > > schedutil
> > >
> > > There are two cpufreq governors to choose from.  Have you decided to
> > > compile out the other ones on purpose?
> > >
> > > It might be useful to compile the powersave governor in and try to
> > > switch over to it (on all CPUs) before pressing the power button
> > > (without any patches applied).
> > >
> > > > /sys/devices/system/cpu/cpufreq/policy2/freqdomain_cpus:2
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_governor:schedutil
> > > > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_max_freq:2834000
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_available_frequencies:2834000
> > > > 2000000
> > >
> > > The frequency scaling on this CPU is quite limited (only 2 states to
> > > choose from).
> > >
> > > > /sys/devices/system/cpu/cpufreq/policy2/related_cpus:2
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_cur_freq:2000088
> > >
> > > Interestingly, this number doesn't match the available choices (maybe
> > > due to a rounding error or similar).
> > >
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_setspeed:<unsupported>
> > > > grep: /sys/devices/system/cpu/cpufreq/policy2/stats/reset: Access denied
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:   From  :    To
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:         :
> > > > 2834000   2000000
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2834000:
> > > >       0       762
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/trans_table:  2000000:
> > > >     761         0
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/total_trans:1523
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2834000 6606
> > > > /sys/devices/system/cpu/cpufreq/policy2/stats/time_in_state:2000000 248733
> > > > /sys/devices/system/cpu/cpufreq/policy2/affected_cpus:2
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_max_freq:2834000
> > > > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_transition_latency:160000
> > > > /sys/devices/system/cpu/cpufreq/policy2/scaling_driver:acpi-cpufreq
> > > > /sys/devices/system/cpu/cpufreq/policy2/cpuinfo_min_freq:2000000
> > > > /sys/devices/system/cpu/cpufreq/policy2/bios_limit:2834000
> > >
> > > The fact that acpi-cpufreq is the scaling driver may be related to the
> > > power button issue in principle.
> > >
> > > I'm still going to send you another debug patch for the button driver though.
>
> So the patch is appended.  It causes a message to be printed into the kernel
> log every time the power button is pressed if all goes well, but the system
> will not shut down (it is also not expected to hang).
>
> Please see if that happens with the patch applied (it is a replacement for the
> previous debug patch).  In principle it should work without changing the
> cpufreq governor.
>
> ---
>  drivers/acpi/button.c |   10 ++++------
>  1 file changed, 4 insertions(+), 6 deletions(-)
>
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -473,14 +473,12 @@ static void acpi_button_notify(acpi_hand
>                                         event, ++button->pushed);
>  }
>
> -static void acpi_button_notify_run(void *data)
> -{
> -       acpi_button_notify(NULL, ACPI_BUTTON_NOTIFY_STATUS, data);
> -}
> -
>  static u32 acpi_button_event(void *data)
>  {
> -       acpi_os_execute(OSL_NOTIFY_HANDLER, acpi_button_notify_run, data);
> +       struct acpi_button *button = data;
> +
> +       dev_info(button->dev, "ACPI button event\n");
> +
>         return ACPI_INTERRUPT_HANDLED;
>  }
>
>
>
>

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Thursday, April 23, 2026 4:51:36 PM CEST Evgeny Sagatov wrote:
> I removed the previous patch and installed the new one in kernel 7.0.0.
> schedutil - complete freeze, no messages in the log
> performance - log message when pressing power button, doesn't reboot
> ondemand - log message when pressing power button, doesn't reboot
> 
> Log: apr 23 17:40:04 srv kernel: acpi-button LNXPWRBN:00: ACPI button event

There clearly is some unexpected interaction between the schedutil governor
(or generally what happens in cpufreq when it is used) and the ACPI power
button handling.  It looks like some memory gets corrupted when schedutil
runs and it is then tripped over by the power button handling code.

Kind of on a hunch, please see if the appended schedutil patch (either with
or without the previous patch applied) makes any difference.

---
 kernel/sched/cpufreq_schedutil.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -158,7 +158,7 @@ unsigned long get_capacity_ref_freq(stru
 	if (freq)
 		return freq;
 
-	if (arch_scale_freq_invariant())
+	if (arch_scale_freq_invariant() || policy->cur >= policy->cpuinfo.max_freq)
 		return policy->cpuinfo.max_freq;
 
 	/*

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

This patch doesn't change anything. The PC remains frozen when
pressing the power button.

чт, 23 апр. 2026 г. в 21:21, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Thursday, April 23, 2026 4:51:36 PM CEST Evgeny Sagatov wrote:
> > I removed the previous patch and installed the new one in kernel 7.0.0.
> > schedutil - complete freeze, no messages in the log
> > performance - log message when pressing power button, doesn't reboot
> > ondemand - log message when pressing power button, doesn't reboot
> >
> > Log: apr 23 17:40:04 srv kernel: acpi-button LNXPWRBN:00: ACPI button event
>
> There clearly is some unexpected interaction between the schedutil governor
> (or generally what happens in cpufreq when it is used) and the ACPI power
> button handling.  It looks like some memory gets corrupted when schedutil
> runs and it is then tripped over by the power button handling code.
>
> Kind of on a hunch, please see if the appended schedutil patch (either with
> or without the previous patch applied) makes any difference.
>
> ---
>  kernel/sched/cpufreq_schedutil.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/kernel/sched/cpufreq_schedutil.c
> +++ b/kernel/sched/cpufreq_schedutil.c
> @@ -158,7 +158,7 @@ unsigned long get_capacity_ref_freq(stru
>         if (freq)
>                 return freq;
>
> -       if (arch_scale_freq_invariant())
> +       if (arch_scale_freq_invariant() || policy->cur >= policy->cpuinfo.max_freq)
>                 return policy->cpuinfo.max_freq;
>
>         /*
>
>
>

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Thursday, April 23, 2026 10:07:39 PM CEST Evgeny Sagatov wrote:
> This patch doesn't change anything. The PC remains frozen when
> pressing the power button.

Well, thanks for giving it a go.

This at least means that the issue is related to certain activity in schedutil,
and the specific values used by it are most likely irrelevant.

This time, I'd like to check two things in one go.  First, whether or not
fast frequency switching is enabled on your system (if it is, it will exercise
a different code path in schedutil) and second, whether or not the power button
press processing gets beyond the clearing the associated event status bit.

For this purpose, please apply the patch below and (1) after booting the
system with the new kernel, run

$ dmesg | grep "Fast frequency"

and let me know if it produces any output (and what the output is if so).

Then (2) press the power button and see if that still locks up the system
if schedutil is the cpufreq governor (if it doesn't lock up, a message
will be printed to the kernel log every time the button is pressed).

---
 drivers/acpi/acpica/evevent.c |    5 +++++
 drivers/cpufreq/cpufreq.c     |    1 +
 2 files changed, 6 insertions(+)

--- a/drivers/acpi/acpica/evevent.c
+++ b/drivers/acpi/acpica/evevent.c
@@ -243,6 +243,11 @@ static u32 acpi_ev_fixed_event_dispatch(
 	(void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
 				      status_register_id, ACPI_CLEAR_STATUS);
 
+	if (event == ACPI_EVENT_POWER_BUTTON) {
+		pr_info("ACPI power button event\n");
+		return (ACPI_INTERRUPT_HANDLED);
+	}
+
 	/*
 	 * Make sure that a handler exists. If not, report an error
 	 * and disable the event to prevent further interrupts.
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
 	if (cpufreq_fast_switch_count >= 0) {
 		cpufreq_fast_switch_count++;
 		policy->fast_switch_enabled = true;
+		pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
 	} else {
 		pr_warn("CPU%u: Fast frequency switching not enabled\n",
 			policy->cpu);

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

dmesg | grep "Fast frequency"
[    8.903099] cpufreq: CPU0: Fast frequency switching enabled
[    8.903181] cpufreq: CPU1: Fast frequency switching enabled
[    8.903247] cpufreq: CPU2: Fast frequency switching enabled
[    8.903316] cpufreq: CPU3: Fast frequency switching enabled

When I pressed the power button, the PC froze. Nothing in the log.

пт, 24 апр. 2026 г. в 17:40, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Thursday, April 23, 2026 10:07:39 PM CEST Evgeny Sagatov wrote:
> > This patch doesn't change anything. The PC remains frozen when
> > pressing the power button.
>
> Well, thanks for giving it a go.
>
> This at least means that the issue is related to certain activity in schedutil,
> and the specific values used by it are most likely irrelevant.
>
> This time, I'd like to check two things in one go.  First, whether or not
> fast frequency switching is enabled on your system (if it is, it will exercise
> a different code path in schedutil) and second, whether or not the power button
> press processing gets beyond the clearing the associated event status bit.
>
> For this purpose, please apply the patch below and (1) after booting the
> system with the new kernel, run
>
> $ dmesg | grep "Fast frequency"
>
> and let me know if it produces any output (and what the output is if so).
>
> Then (2) press the power button and see if that still locks up the system
> if schedutil is the cpufreq governor (if it doesn't lock up, a message
> will be printed to the kernel log every time the button is pressed).
>
> ---
>  drivers/acpi/acpica/evevent.c |    5 +++++
>  drivers/cpufreq/cpufreq.c     |    1 +
>  2 files changed, 6 insertions(+)
>
> --- a/drivers/acpi/acpica/evevent.c
> +++ b/drivers/acpi/acpica/evevent.c
> @@ -243,6 +243,11 @@ static u32 acpi_ev_fixed_event_dispatch(
>         (void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
>                                       status_register_id, ACPI_CLEAR_STATUS);
>
> +       if (event == ACPI_EVENT_POWER_BUTTON) {
> +               pr_info("ACPI power button event\n");
> +               return (ACPI_INTERRUPT_HANDLED);
> +       }
> +
>         /*
>          * Make sure that a handler exists. If not, report an error
>          * and disable the event to prevent further interrupts.
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
>         if (cpufreq_fast_switch_count >= 0) {
>                 cpufreq_fast_switch_count++;
>                 policy->fast_switch_enabled = true;
> +               pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
>         } else {
>                 pr_warn("CPU%u: Fast frequency switching not enabled\n",
>                         policy->cpu);
>
>
>

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Friday, April 24, 2026 7:06:50 PM CEST Evgeny Sagatov wrote:
> dmesg | grep "Fast frequency"
> [    8.903099] cpufreq: CPU0: Fast frequency switching enabled
> [    8.903181] cpufreq: CPU1: Fast frequency switching enabled
> [    8.903247] cpufreq: CPU2: Fast frequency switching enabled
> [    8.903316] cpufreq: CPU3: Fast frequency switching enabled

If it is enabled, let's try to disable it and see what happens.

> When I pressed the power button, the PC froze. Nothing in the log.

Below is an updated version of the previous patch which additionally
disables fast frequency switching in the ACPI cpufreq driver that is
in use on your system.

The "Fast frequency switching enabled" messages should not be there
any more in the log with this patch applied (please verify) and
please check if pressing the power button will still lock up the
system.

---
 drivers/acpi/acpica/evevent.c  |    5 +++++
 drivers/cpufreq/acpi-cpufreq.c |    3 +--
 drivers/cpufreq/cpufreq.c      |    1 +
 3 files changed, 7 insertions(+), 2 deletions(-)

--- a/drivers/acpi/acpica/evevent.c
+++ b/drivers/acpi/acpica/evevent.c
@@ -243,6 +243,11 @@ static u32 acpi_ev_fixed_event_dispatch(
 	(void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
 				      status_register_id, ACPI_CLEAR_STATUS);
 
+	if (event == ACPI_EVENT_POWER_BUTTON) {
+		pr_info("ACPI power button event\n");
+		return (ACPI_INTERRUPT_HANDLED);
+	}
+
 	/*
 	 * Make sure that a handler exists. If not, report an error
 	 * and disable the event to prevent further interrupts.
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -912,8 +912,7 @@ static int acpi_cpufreq_cpu_init(struct
 	 */
 	data->resume = 1;
 
-	policy->fast_switch_possible = !acpi_pstate_strict &&
-		!(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
+	policy->fast_switch_possible = false;
 
 	if (perf->states[0].core_frequency * 1000 != freq_table[0].frequency)
 		pr_warn(FW_WARN "P-state 0 is not max freq\n");
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
 	if (cpufreq_fast_switch_count >= 0) {
 		cpufreq_fast_switch_count++;
 		policy->fast_switch_enabled = true;
+		pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
 	} else {
 		pr_warn("CPU%u: Fast frequency switching not enabled\n",
 			policy->cpu);

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

dmesg | grep "Fast frequency"
Nothing was displayed.

The PC froze when I pressed the power button. Nothing in the log.

I applied this patch after deleting all the previous ones. Is this correct?

I received this message when applying a patch. Perhaps we have
different versions of the source code? I'm using 7.0.0.
patching file drivers/acpi/acpica/evevent.c
patching file drivers/cpufreq/acpi-cpufreq.c
Hunk #1 succeeded at 895 (offset -17 lines).
patching file drivers/cpufreq/cpufreq.c

пт, 24 апр. 2026 г. в 22:45, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Friday, April 24, 2026 7:06:50 PM CEST Evgeny Sagatov wrote:
> > dmesg | grep "Fast frequency"
> > [    8.903099] cpufreq: CPU0: Fast frequency switching enabled
> > [    8.903181] cpufreq: CPU1: Fast frequency switching enabled
> > [    8.903247] cpufreq: CPU2: Fast frequency switching enabled
> > [    8.903316] cpufreq: CPU3: Fast frequency switching enabled
>
> If it is enabled, let's try to disable it and see what happens.
>
> > When I pressed the power button, the PC froze. Nothing in the log.
>
> Below is an updated version of the previous patch which additionally
> disables fast frequency switching in the ACPI cpufreq driver that is
> in use on your system.
>
> The "Fast frequency switching enabled" messages should not be there
> any more in the log with this patch applied (please verify) and
> please check if pressing the power button will still lock up the
> system.
>
> ---
>  drivers/acpi/acpica/evevent.c  |    5 +++++
>  drivers/cpufreq/acpi-cpufreq.c |    3 +--
>  drivers/cpufreq/cpufreq.c      |    1 +
>  3 files changed, 7 insertions(+), 2 deletions(-)
>
> --- a/drivers/acpi/acpica/evevent.c
> +++ b/drivers/acpi/acpica/evevent.c
> @@ -243,6 +243,11 @@ static u32 acpi_ev_fixed_event_dispatch(
>         (void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
>                                       status_register_id, ACPI_CLEAR_STATUS);
>
> +       if (event == ACPI_EVENT_POWER_BUTTON) {
> +               pr_info("ACPI power button event\n");
> +               return (ACPI_INTERRUPT_HANDLED);
> +       }
> +
>         /*
>          * Make sure that a handler exists. If not, report an error
>          * and disable the event to prevent further interrupts.
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -912,8 +912,7 @@ static int acpi_cpufreq_cpu_init(struct
>          */
>         data->resume = 1;
>
> -       policy->fast_switch_possible = !acpi_pstate_strict &&
> -               !(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
> +       policy->fast_switch_possible = false;
>
>         if (perf->states[0].core_frequency * 1000 != freq_table[0].frequency)
>                 pr_warn(FW_WARN "P-state 0 is not max freq\n");
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
>         if (cpufreq_fast_switch_count >= 0) {
>                 cpufreq_fast_switch_count++;
>                 policy->fast_switch_enabled = true;
> +               pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
>         } else {
>                 pr_warn("CPU%u: Fast frequency switching not enabled\n",
>                         policy->cpu);
>
>
>

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Friday, April 24, 2026 11:18:02 PM CEST Evgeny Sagatov wrote:
> dmesg | grep "Fast frequency"
> Nothing was displayed.
> 
> The PC froze when I pressed the power button. Nothing in the log.
> 
> I applied this patch after deleting all the previous ones. Is this correct?

Yes, it is.

> I received this message when applying a patch. Perhaps we have
> different versions of the source code? I'm using 7.0.0.
> patching file drivers/acpi/acpica/evevent.c
> patching file drivers/cpufreq/acpi-cpufreq.c
> Hunk #1 succeeded at 895 (offset -17 lines).
> patching file drivers/cpufreq/cpufreq.c

That should be fine.

We've switched over schedutil to a different code path and the problem is
still there, so it appears to be related to hardware accesses.

To test this, please apply the patch below (which is a replacement for the
previous patch) and collect the output of

$ dmesg | grep ""

after a fresh boot.  Please let me know what's there.

Also, the "Fast frequency switching enabled" messages should be back.

Then, check what happens when the power button is pressed (if the system
doesn't lock up, a message should be printed to the kernel log every time
the power button is pressed).

With this patch applied, schedutil will not access hardware in the fast
frequency switching path, so the frequency scaling will not actually work
(this is roughly equivalent to running the "performance" or "powersave"
governor all the time).

---
 drivers/acpi/acpica/evevent.c  |    5 +++++
 drivers/cpufreq/acpi-cpufreq.c |    6 ++++--
 drivers/cpufreq/cpufreq.c      |    1 +
 3 files changed, 10 insertions(+), 2 deletions(-)

--- a/drivers/acpi/acpica/evevent.c
+++ b/drivers/acpi/acpica/evevent.c
@@ -243,6 +243,11 @@ static u32 acpi_ev_fixed_event_dispatch(
 	(void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
 				      status_register_id, ACPI_CLEAR_STATUS);
 
+	if (event == ACPI_EVENT_POWER_BUTTON) {
+		pr_info("ACPI power button event\n");
+		return (ACPI_INTERRUPT_HANDLED);
+	}
+
 	/*
 	 * Make sure that a handler exists. If not, report an error
 	 * and disable the event to prevent further interrupts.
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -479,8 +479,8 @@ static unsigned int acpi_cpufreq_fast_sw
 			return next_freq;
 	}
 
-	data->cpu_freq_write(&perf->control_register,
-			     perf->states[next_perf_state].control);
+	/*data->cpu_freq_write(&perf->control_register,
+			     perf->states[next_perf_state].control);*/
 	perf->state = next_perf_state;
 	return next_freq;
 }
@@ -887,9 +887,11 @@ static int acpi_cpufreq_cpu_init(struct
 		 * unknown and not detectable via IO ports.
 		 */
 		policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
+		pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
 		break;
 	case ACPI_ADR_SPACE_FIXED_HARDWARE:
 		acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
+		pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
 		break;
 	default:
 		break;
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
 	if (cpufreq_fast_switch_count >= 0) {
 		cpufreq_fast_switch_count++;
 		policy->fast_switch_enabled = true;
+		pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
 	} else {
 		pr_warn("CPU%u: Fast frequency switching not enabled\n",
 			policy->cpu);

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Sun, Apr 26, 2026 at 4:50 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Friday, April 24, 2026 11:18:02 PM CEST Evgeny Sagatov wrote:
> > dmesg | grep "Fast frequency"
> > Nothing was displayed.
> >
> > The PC froze when I pressed the power button. Nothing in the log.
> >
> > I applied this patch after deleting all the previous ones. Is this correct?
>
> Yes, it is.
>
> > I received this message when applying a patch. Perhaps we have
> > different versions of the source code? I'm using 7.0.0.
> > patching file drivers/acpi/acpica/evevent.c
> > patching file drivers/cpufreq/acpi-cpufreq.c
> > Hunk #1 succeeded at 895 (offset -17 lines).
> > patching file drivers/cpufreq/cpufreq.c
>
> That should be fine.
>
> We've switched over schedutil to a different code path and the problem is
> still there, so it appears to be related to hardware accesses.
>
> To test this, please apply the patch below (which is a replacement for the
> previous patch) and collect the output of
>
> $ dmesg | grep ""

This should have been

$ dmesg | grep "frequency scaling"

(pressed "send" too early, sorry about that) but sending a complete
dmesg log (which would be produced by grepping for an empty string)
would work either.

> after a fresh boot.  Please let me know what's there.
>
> Also, the "Fast frequency switching enabled" messages should be back.
>
> Then, check what happens when the power button is pressed (if the system
> doesn't lock up, a message should be printed to the kernel log every time
> the power button is pressed).
>
> With this patch applied, schedutil will not access hardware in the fast
> frequency switching path, so the frequency scaling will not actually work
> (this is roughly equivalent to running the "performance" or "powersave"
> governor all the time).
>
> ---
>  drivers/acpi/acpica/evevent.c  |    5 +++++
>  drivers/cpufreq/acpi-cpufreq.c |    6 ++++--
>  drivers/cpufreq/cpufreq.c      |    1 +
>  3 files changed, 10 insertions(+), 2 deletions(-)
>
> --- a/drivers/acpi/acpica/evevent.c
> +++ b/drivers/acpi/acpica/evevent.c
> @@ -243,6 +243,11 @@ static u32 acpi_ev_fixed_event_dispatch(
>         (void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
>                                       status_register_id, ACPI_CLEAR_STATUS);
>
> +       if (event == ACPI_EVENT_POWER_BUTTON) {
> +               pr_info("ACPI power button event\n");
> +               return (ACPI_INTERRUPT_HANDLED);
> +       }
> +
>         /*
>          * Make sure that a handler exists. If not, report an error
>          * and disable the event to prevent further interrupts.
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -479,8 +479,8 @@ static unsigned int acpi_cpufreq_fast_sw
>                         return next_freq;
>         }
>
> -       data->cpu_freq_write(&perf->control_register,
> -                            perf->states[next_perf_state].control);
> +       /*data->cpu_freq_write(&perf->control_register,
> +                            perf->states[next_perf_state].control);*/
>         perf->state = next_perf_state;
>         return next_freq;
>  }
> @@ -887,9 +887,11 @@ static int acpi_cpufreq_cpu_init(struct
>                  * unknown and not detectable via IO ports.
>                  */
>                 policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
> +               pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
>                 break;
>         case ACPI_ADR_SPACE_FIXED_HARDWARE:
>                 acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> +               pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
>                 break;
>         default:
>                 break;
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
>         if (cpufreq_fast_switch_count >= 0) {
>                 cpufreq_fast_switch_count++;
>                 policy->fast_switch_enabled = true;
> +               pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
>         } else {
>                 pr_warn("CPU%u: Fast frequency switching not enabled\n",
>                         policy->cpu);
>
>
>
>

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

dmesg | grep "frequency s"
[    8.622778] acpi_cpufreq: CPU0: Using I/O space for frequency scaling
[    8.622806] cpufreq: CPU0: Fast frequency switching enabled
[    8.622869] acpi_cpufreq: CPU1: Using I/O space for frequency scaling
[    8.622888] cpufreq: CPU1: Fast frequency switching enabled
[    8.622938] acpi_cpufreq: CPU2: Using I/O space for frequency scaling
[    8.622955] cpufreq: CPU2: Fast frequency switching enabled
[    8.623006] acpi_cpufreq: CPU3: Using I/O space for frequency scaling
[    8.623026] cpufreq: CPU3: Fast frequency switching enabled

When I press the power button, a message is displayed:
apr 26 23:40:36 srv kernel: ACPI power button event

The PC does not freeze.
The single core performance benchmark shows good values.

вс, 26 апр. 2026 г. в 17:54, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Sun, Apr 26, 2026 at 4:50 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Friday, April 24, 2026 11:18:02 PM CEST Evgeny Sagatov wrote:
> > > dmesg | grep "Fast frequency"
> > > Nothing was displayed.
> > >
> > > The PC froze when I pressed the power button. Nothing in the log.
> > >
> > > I applied this patch after deleting all the previous ones. Is this correct?
> >
> > Yes, it is.
> >
> > > I received this message when applying a patch. Perhaps we have
> > > different versions of the source code? I'm using 7.0.0.
> > > patching file drivers/acpi/acpica/evevent.c
> > > patching file drivers/cpufreq/acpi-cpufreq.c
> > > Hunk #1 succeeded at 895 (offset -17 lines).
> > > patching file drivers/cpufreq/cpufreq.c
> >
> > That should be fine.
> >
> > We've switched over schedutil to a different code path and the problem is
> > still there, so it appears to be related to hardware accesses.
> >
> > To test this, please apply the patch below (which is a replacement for the
> > previous patch) and collect the output of
> >
> > $ dmesg | grep ""
>
> This should have been
>
> $ dmesg | grep "frequency scaling"
>
> (pressed "send" too early, sorry about that) but sending a complete
> dmesg log (which would be produced by grepping for an empty string)
> would work either.
>
> > after a fresh boot.  Please let me know what's there.
> >
> > Also, the "Fast frequency switching enabled" messages should be back.
> >
> > Then, check what happens when the power button is pressed (if the system
> > doesn't lock up, a message should be printed to the kernel log every time
> > the power button is pressed).
> >
> > With this patch applied, schedutil will not access hardware in the fast
> > frequency switching path, so the frequency scaling will not actually work
> > (this is roughly equivalent to running the "performance" or "powersave"
> > governor all the time).
> >
> > ---
> >  drivers/acpi/acpica/evevent.c  |    5 +++++
> >  drivers/cpufreq/acpi-cpufreq.c |    6 ++++--
> >  drivers/cpufreq/cpufreq.c      |    1 +
> >  3 files changed, 10 insertions(+), 2 deletions(-)
> >
> > --- a/drivers/acpi/acpica/evevent.c
> > +++ b/drivers/acpi/acpica/evevent.c
> > @@ -243,6 +243,11 @@ static u32 acpi_ev_fixed_event_dispatch(
> >         (void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
> >                                       status_register_id, ACPI_CLEAR_STATUS);
> >
> > +       if (event == ACPI_EVENT_POWER_BUTTON) {
> > +               pr_info("ACPI power button event\n");
> > +               return (ACPI_INTERRUPT_HANDLED);
> > +       }
> > +
> >         /*
> >          * Make sure that a handler exists. If not, report an error
> >          * and disable the event to prevent further interrupts.
> > --- a/drivers/cpufreq/acpi-cpufreq.c
> > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > @@ -479,8 +479,8 @@ static unsigned int acpi_cpufreq_fast_sw
> >                         return next_freq;
> >         }
> >
> > -       data->cpu_freq_write(&perf->control_register,
> > -                            perf->states[next_perf_state].control);
> > +       /*data->cpu_freq_write(&perf->control_register,
> > +                            perf->states[next_perf_state].control);*/
> >         perf->state = next_perf_state;
> >         return next_freq;
> >  }
> > @@ -887,9 +887,11 @@ static int acpi_cpufreq_cpu_init(struct
> >                  * unknown and not detectable via IO ports.
> >                  */
> >                 policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
> > +               pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
> >                 break;
> >         case ACPI_ADR_SPACE_FIXED_HARDWARE:
> >                 acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> > +               pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
> >                 break;
> >         default:
> >                 break;
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
> >         if (cpufreq_fast_switch_count >= 0) {
> >                 cpufreq_fast_switch_count++;
> >                 policy->fast_switch_enabled = true;
> > +               pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
> >         } else {
> >                 pr_warn("CPU%u: Fast frequency switching not enabled\n",
> >                         policy->cpu);
> >
> >
> >
> >

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Sunday, April 26, 2026 10:45:03 PM CEST Evgeny Sagatov wrote:
> dmesg | grep "frequency s"
> [    8.622778] acpi_cpufreq: CPU0: Using I/O space for frequency scaling
> [    8.622806] cpufreq: CPU0: Fast frequency switching enabled
> [    8.622869] acpi_cpufreq: CPU1: Using I/O space for frequency scaling
> [    8.622888] cpufreq: CPU1: Fast frequency switching enabled
> [    8.622938] acpi_cpufreq: CPU2: Using I/O space for frequency scaling
> [    8.622955] cpufreq: CPU2: Fast frequency switching enabled
> [    8.623006] acpi_cpufreq: CPU3: Using I/O space for frequency scaling
> [    8.623026] cpufreq: CPU3: Fast frequency switching enabled
> 
> When I press the power button, a message is displayed:
> apr 26 23:40:36 srv kernel: ACPI power button event
> 
> The PC does not freeze.

Good.

> The single core performance benchmark shows good values.

That most likely is a coincidence.

The above means that the issue is related to HW accesses in the I/O space.

I don't actually think that the writes to the I/O space outright clash with
each other, but the timing between them may be somewhat overly aggressive.

Let's first check what I/O ports come into play though.

Please apply the patch below (which is a replacement for the previous one),
run

$ dmesg | grep "frequency scaling"

after a fresh boot of the new kernel and let me know the output of it.

Then, press the power button and send the messages printed after that.

---
 drivers/acpi/acpica/evevent.c  |   12 ++++++++++++
 drivers/cpufreq/acpi-cpufreq.c |    8 ++++++--
 drivers/cpufreq/cpufreq.c      |    1 +
 3 files changed, 19 insertions(+), 2 deletions(-)

--- a/drivers/acpi/acpica/evevent.c
+++ b/drivers/acpi/acpica/evevent.c
@@ -243,6 +243,18 @@ static u32 acpi_ev_fixed_event_dispatch(
 	(void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
 				      status_register_id, ACPI_CLEAR_STATUS);
 
+	if (event == ACPI_EVENT_POWER_BUTTON) {
+		pr_info("ACPI power button event\n");
+		if (acpi_gbl_fixed_event_info[event].status_register_id == 0)
+			pr_info("ACPI event status I/O port number: %llu\n",
+				acpi_gbl_xpm1a_status.address);
+		else
+			pr_info("ACPI event status register ID: %u\n",
+				acpi_gbl_fixed_event_info[event].status_register_id);
+
+		return (ACPI_INTERRUPT_HANDLED);
+	}
+
 	/*
 	 * Make sure that a handler exists. If not, report an error
 	 * and disable the event to prevent further interrupts.
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -479,8 +479,8 @@ static unsigned int acpi_cpufreq_fast_sw
 			return next_freq;
 	}
 
-	data->cpu_freq_write(&perf->control_register,
-			     perf->states[next_perf_state].control);
+	/*data->cpu_freq_write(&perf->control_register,
+			     perf->states[next_perf_state].control);*/
 	perf->state = next_perf_state;
 	return next_freq;
 }
@@ -887,9 +887,13 @@ static int acpi_cpufreq_cpu_init(struct
 		 * unknown and not detectable via IO ports.
 		 */
 		policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
+		pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
+		pr_info("CPU%u: frequency scaling I/O port number: %llu\n", cpu,
+			perf->control_register.address);
 		break;
 	case ACPI_ADR_SPACE_FIXED_HARDWARE:
 		acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
+		pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
 		break;
 	default:
 		break;
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
 	if (cpufreq_fast_switch_count >= 0) {
 		cpufreq_fast_switch_count++;
 		policy->fast_switch_enabled = true;
+		pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
 	} else {
 		pr_warn("CPU%u: Fast frequency switching not enabled\n",
 			policy->cpu);

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

dmesg | grep "frequency scaling"
[    8.552380] acpi_cpufreq: CPU0: Using I/O space for frequency scaling
[    8.552386] acpi_cpufreq: CPU0: frequency scaling I/O port number: 2176
[    8.552478] acpi_cpufreq: CPU1: Using I/O space for frequency scaling
[    8.552480] acpi_cpufreq: CPU1: frequency scaling I/O port number: 2176
[    8.552584] acpi_cpufreq: CPU2: Using I/O space for frequency scaling
[    8.552586] acpi_cpufreq: CPU2: frequency scaling I/O port number: 2176
[    8.552668] acpi_cpufreq: CPU3: Using I/O space for frequency scaling
[    8.552670] acpi_cpufreq: CPU3: frequency scaling I/O port number: 2176

Messages that appear when I press the power button:
apr 27 23:07:33 srv kernel: ACPI power button event
apr 27 23:07:33 srv kernel: ACPI event status register ID: 3

пн, 27 апр. 2026 г. в 21:48, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Sunday, April 26, 2026 10:45:03 PM CEST Evgeny Sagatov wrote:
> > dmesg | grep "frequency s"
> > [    8.622778] acpi_cpufreq: CPU0: Using I/O space for frequency scaling
> > [    8.622806] cpufreq: CPU0: Fast frequency switching enabled
> > [    8.622869] acpi_cpufreq: CPU1: Using I/O space for frequency scaling
> > [    8.622888] cpufreq: CPU1: Fast frequency switching enabled
> > [    8.622938] acpi_cpufreq: CPU2: Using I/O space for frequency scaling
> > [    8.622955] cpufreq: CPU2: Fast frequency switching enabled
> > [    8.623006] acpi_cpufreq: CPU3: Using I/O space for frequency scaling
> > [    8.623026] cpufreq: CPU3: Fast frequency switching enabled
> >
> > When I press the power button, a message is displayed:
> > apr 26 23:40:36 srv kernel: ACPI power button event
> >
> > The PC does not freeze.
>
> Good.
>
> > The single core performance benchmark shows good values.
>
> That most likely is a coincidence.
>
> The above means that the issue is related to HW accesses in the I/O space.
>
> I don't actually think that the writes to the I/O space outright clash with
> each other, but the timing between them may be somewhat overly aggressive.
>
> Let's first check what I/O ports come into play though.
>
> Please apply the patch below (which is a replacement for the previous one),
> run
>
> $ dmesg | grep "frequency scaling"
>
> after a fresh boot of the new kernel and let me know the output of it.
>
> Then, press the power button and send the messages printed after that.
>
> ---
>  drivers/acpi/acpica/evevent.c  |   12 ++++++++++++
>  drivers/cpufreq/acpi-cpufreq.c |    8 ++++++--
>  drivers/cpufreq/cpufreq.c      |    1 +
>  3 files changed, 19 insertions(+), 2 deletions(-)
>
> --- a/drivers/acpi/acpica/evevent.c
> +++ b/drivers/acpi/acpica/evevent.c
> @@ -243,6 +243,18 @@ static u32 acpi_ev_fixed_event_dispatch(
>         (void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
>                                       status_register_id, ACPI_CLEAR_STATUS);
>
> +       if (event == ACPI_EVENT_POWER_BUTTON) {
> +               pr_info("ACPI power button event\n");
> +               if (acpi_gbl_fixed_event_info[event].status_register_id == 0)
> +                       pr_info("ACPI event status I/O port number: %llu\n",
> +                               acpi_gbl_xpm1a_status.address);
> +               else
> +                       pr_info("ACPI event status register ID: %u\n",
> +                               acpi_gbl_fixed_event_info[event].status_register_id);
> +
> +               return (ACPI_INTERRUPT_HANDLED);
> +       }
> +
>         /*
>          * Make sure that a handler exists. If not, report an error
>          * and disable the event to prevent further interrupts.
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -479,8 +479,8 @@ static unsigned int acpi_cpufreq_fast_sw
>                         return next_freq;
>         }
>
> -       data->cpu_freq_write(&perf->control_register,
> -                            perf->states[next_perf_state].control);
> +       /*data->cpu_freq_write(&perf->control_register,
> +                            perf->states[next_perf_state].control);*/
>         perf->state = next_perf_state;
>         return next_freq;
>  }
> @@ -887,9 +887,13 @@ static int acpi_cpufreq_cpu_init(struct
>                  * unknown and not detectable via IO ports.
>                  */
>                 policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
> +               pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
> +               pr_info("CPU%u: frequency scaling I/O port number: %llu\n", cpu,
> +                       perf->control_register.address);
>                 break;
>         case ACPI_ADR_SPACE_FIXED_HARDWARE:
>                 acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> +               pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
>                 break;
>         default:
>                 break;
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
>         if (cpufreq_fast_switch_count >= 0) {
>                 cpufreq_fast_switch_count++;
>                 policy->fast_switch_enabled = true;
> +               pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
>         } else {
>                 pr_warn("CPU%u: Fast frequency switching not enabled\n",
>                         policy->cpu);
>
>
>

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Monday, April 27, 2026 10:12:33 PM CEST Evgeny Sagatov wrote:
> dmesg | grep "frequency scaling"
> [    8.552380] acpi_cpufreq: CPU0: Using I/O space for frequency scaling
> [    8.552386] acpi_cpufreq: CPU0: frequency scaling I/O port number: 2176
> [    8.552478] acpi_cpufreq: CPU1: Using I/O space for frequency scaling
> [    8.552480] acpi_cpufreq: CPU1: frequency scaling I/O port number: 2176
> [    8.552584] acpi_cpufreq: CPU2: Using I/O space for frequency scaling
> [    8.552586] acpi_cpufreq: CPU2: frequency scaling I/O port number: 2176
> [    8.552668] acpi_cpufreq: CPU3: Using I/O space for frequency scaling
> [    8.552670] acpi_cpufreq: CPU3: frequency scaling I/O port number: 2176
> 
> Messages that appear when I press the power button:
> apr 27 23:07:33 srv kernel: ACPI power button event
> apr 27 23:07:33 srv kernel: ACPI event status register ID: 3

Of course it's a power button, so the register ID is 3 and the register
is PM1.  Sorry for missing that previously.

Please apply the slightly update patch below (which replaces the previous
one) and send the messages printed to the log after booting the new
kernel and pressing the power button.

---
 drivers/acpi/acpica/evevent.c  |    8 ++++++++
 drivers/cpufreq/acpi-cpufreq.c |    8 ++++++--
 drivers/cpufreq/cpufreq.c      |    1 +
 3 files changed, 15 insertions(+), 2 deletions(-)

--- a/drivers/acpi/acpica/evevent.c
+++ b/drivers/acpi/acpica/evevent.c
@@ -243,6 +243,14 @@ static u32 acpi_ev_fixed_event_dispatch(
 	(void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
 				      status_register_id, ACPI_CLEAR_STATUS);
 
+	if (event == ACPI_EVENT_POWER_BUTTON) {
+		pr_info("ACPI power button event\n");
+		pr_info("ACPI event status I/O port number: %llu\n",
+			acpi_gbl_xpm1a_status.address);
+
+		return (ACPI_INTERRUPT_HANDLED);
+	}
+
 	/*
 	 * Make sure that a handler exists. If not, report an error
 	 * and disable the event to prevent further interrupts.
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -479,8 +479,8 @@ static unsigned int acpi_cpufreq_fast_sw
 			return next_freq;
 	}
 
-	data->cpu_freq_write(&perf->control_register,
-			     perf->states[next_perf_state].control);
+	/*data->cpu_freq_write(&perf->control_register,
+			     perf->states[next_perf_state].control);*/
 	perf->state = next_perf_state;
 	return next_freq;
 }
@@ -887,9 +887,13 @@ static int acpi_cpufreq_cpu_init(struct
 		 * unknown and not detectable via IO ports.
 		 */
 		policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
+		pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
+		pr_info("CPU%u: frequency scaling I/O port number: %llu\n", cpu,
+			perf->control_register.address);
 		break;
 	case ACPI_ADR_SPACE_FIXED_HARDWARE:
 		acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
+		pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
 		break;
 	default:
 		break;
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
 	if (cpufreq_fast_switch_count >= 0) {
 		cpufreq_fast_switch_count++;
 		policy->fast_switch_enabled = true;
+		pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
 	} else {
 		pr_warn("CPU%u: Fast frequency switching not enabled\n",
 			policy->cpu);

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

apr 28 00:48:34 srv kernel: ACPI power button event
apr 28 00:48:34 srv kernel: ACPI event status I/O port number: 1024

пн, 27 апр. 2026 г. в 23:31, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Monday, April 27, 2026 10:12:33 PM CEST Evgeny Sagatov wrote:
> > dmesg | grep "frequency scaling"
> > [    8.552380] acpi_cpufreq: CPU0: Using I/O space for frequency scaling
> > [    8.552386] acpi_cpufreq: CPU0: frequency scaling I/O port number: 2176
> > [    8.552478] acpi_cpufreq: CPU1: Using I/O space for frequency scaling
> > [    8.552480] acpi_cpufreq: CPU1: frequency scaling I/O port number: 2176
> > [    8.552584] acpi_cpufreq: CPU2: Using I/O space for frequency scaling
> > [    8.552586] acpi_cpufreq: CPU2: frequency scaling I/O port number: 2176
> > [    8.552668] acpi_cpufreq: CPU3: Using I/O space for frequency scaling
> > [    8.552670] acpi_cpufreq: CPU3: frequency scaling I/O port number: 2176
> >
> > Messages that appear when I press the power button:
> > apr 27 23:07:33 srv kernel: ACPI power button event
> > apr 27 23:07:33 srv kernel: ACPI event status register ID: 3
>
> Of course it's a power button, so the register ID is 3 and the register
> is PM1.  Sorry for missing that previously.
>
> Please apply the slightly update patch below (which replaces the previous
> one) and send the messages printed to the log after booting the new
> kernel and pressing the power button.
>
> ---
>  drivers/acpi/acpica/evevent.c  |    8 ++++++++
>  drivers/cpufreq/acpi-cpufreq.c |    8 ++++++--
>  drivers/cpufreq/cpufreq.c      |    1 +
>  3 files changed, 15 insertions(+), 2 deletions(-)
>
> --- a/drivers/acpi/acpica/evevent.c
> +++ b/drivers/acpi/acpica/evevent.c
> @@ -243,6 +243,14 @@ static u32 acpi_ev_fixed_event_dispatch(
>         (void)acpi_write_bit_register(acpi_gbl_fixed_event_info[event].
>                                       status_register_id, ACPI_CLEAR_STATUS);
>
> +       if (event == ACPI_EVENT_POWER_BUTTON) {
> +               pr_info("ACPI power button event\n");
> +               pr_info("ACPI event status I/O port number: %llu\n",
> +                       acpi_gbl_xpm1a_status.address);
> +
> +               return (ACPI_INTERRUPT_HANDLED);
> +       }
> +
>         /*
>          * Make sure that a handler exists. If not, report an error
>          * and disable the event to prevent further interrupts.
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -479,8 +479,8 @@ static unsigned int acpi_cpufreq_fast_sw
>                         return next_freq;
>         }
>
> -       data->cpu_freq_write(&perf->control_register,
> -                            perf->states[next_perf_state].control);
> +       /*data->cpu_freq_write(&perf->control_register,
> +                            perf->states[next_perf_state].control);*/
>         perf->state = next_perf_state;
>         return next_freq;
>  }
> @@ -887,9 +887,13 @@ static int acpi_cpufreq_cpu_init(struct
>                  * unknown and not detectable via IO ports.
>                  */
>                 policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
> +               pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
> +               pr_info("CPU%u: frequency scaling I/O port number: %llu\n", cpu,
> +                       perf->control_register.address);
>                 break;
>         case ACPI_ADR_SPACE_FIXED_HARDWARE:
>                 acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> +               pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
>                 break;
>         default:
>                 break;
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
>         if (cpufreq_fast_switch_count >= 0) {
>                 cpufreq_fast_switch_count++;
>                 policy->fast_switch_enabled = true;
> +               pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
>         } else {
>                 pr_warn("CPU%u: Fast frequency switching not enabled\n",
>                         policy->cpu);
>
>
>

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Monday, April 27, 2026 11:49:51 PM CEST Evgeny Sagatov wrote:
> apr 28 00:48:34 srv kernel: ACPI power button event
> apr 28 00:48:34 srv kernel: ACPI event status I/O port number: 1024
> 
> пн, 27 апр. 2026 г. в 23:31, Rafael J. Wysocki <rafael@kernel.org>:
> >
> > On Monday, April 27, 2026 10:12:33 PM CEST Evgeny Sagatov wrote:
> > > dmesg | grep "frequency scaling"
> > > [    8.552380] acpi_cpufreq: CPU0: Using I/O space for frequency scaling
> > > [    8.552386] acpi_cpufreq: CPU0: frequency scaling I/O port number: 2176
> > > [    8.552478] acpi_cpufreq: CPU1: Using I/O space for frequency scaling
> > > [    8.552480] acpi_cpufreq: CPU1: frequency scaling I/O port number: 2176
> > > [    8.552584] acpi_cpufreq: CPU2: Using I/O space for frequency scaling
> > > [    8.552586] acpi_cpufreq: CPU2: frequency scaling I/O port number: 2176
> > > [    8.552668] acpi_cpufreq: CPU3: Using I/O space for frequency scaling
> > > [    8.552670] acpi_cpufreq: CPU3: frequency scaling I/O port number: 2176

The I/O ports that play the role in this issue are separate from each other in
the address space, but that need not mean that they are physically independent.

My current theory is that accessing one of them while an access to the other
one is still in progress may cause the platform to lock up, or there is an
access pattern that causes that to happen.

Let's first test the simplest variant of that theory and see what happens if
all I/O port accesses in acpi_os_write_port() are serialized, which is done
in the patch below (it is a replacement for all of the patches sent so far).

In addition, that patch causes schedutil to use the slow path for updating the
frequency because the I/O space is generally somewhat too slow to be used
from the scheduler context relatively often, but that should not affect the
behavior related to I/O space accesses.

Please check if the system still locks up after pressing the power button
with this patch applied.

---
 drivers/acpi/osl.c             |    9 +++++++--
 drivers/cpufreq/acpi-cpufreq.c |    9 ++++++---
 2 files changed, 13 insertions(+), 5 deletions(-)

--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -700,8 +700,10 @@ EXPORT_SYMBOL(acpi_os_read_port);
 
 acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
 {
-	if (!IS_ENABLED(CONFIG_HAS_IOPORT))
-		return AE_NOT_IMPLEMENTED;
+#ifdef CONFIG_HAS_IOPORT
+	static DEFINE_RAW_SPINLOCK(acpi_os_write_port_lock);
+
+	guard(raw_spinlock_irqsave)(&acpi_os_write_port_lock);
 
 	if (width <= 8) {
 		outb(value, port);
@@ -715,6 +717,9 @@ acpi_status acpi_os_write_port(acpi_io_a
 	}
 
 	return AE_OK;
+#else
+	return AE_NOT_IMPLEMENTED;
+#endif
 }
 
 EXPORT_SYMBOL(acpi_os_write_port);
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -878,6 +878,10 @@ static int acpi_cpufreq_cpu_init(struct
 	policy->freq_table = freq_table;
 	perf->state = 0;
 
+	policy->fast_switch_possible = !acpi_pstate_strict &&
+		!(policy_is_shared(policy) &&
+		  policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
+
 	switch (perf->control_register.space_id) {
 	case ACPI_ADR_SPACE_SYSTEM_IO:
 		/*
@@ -887,6 +891,8 @@ static int acpi_cpufreq_cpu_init(struct
 		 * unknown and not detectable via IO ports.
 		 */
 		policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
+		/* I/O spcase is too slow for fast switching. */
+		policy->fast_switch_possible = false;
 		break;
 	case ACPI_ADR_SPACE_FIXED_HARDWARE:
 		acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
@@ -912,9 +918,6 @@ static int acpi_cpufreq_cpu_init(struct
 	 */
 	data->resume = 1;
 
-	policy->fast_switch_possible = !acpi_pstate_strict &&
-		!(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
-
 	if (perf->states[0].core_frequency * 1000 != freq_table[0].frequency)
 		pr_warn(FW_WARN "P-state 0 is not max freq\n");
 

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

Yes, the PC froze when I pressed the power button.

вт, 28 апр. 2026 г. в 20:40, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Monday, April 27, 2026 11:49:51 PM CEST Evgeny Sagatov wrote:
> > apr 28 00:48:34 srv kernel: ACPI power button event
> > apr 28 00:48:34 srv kernel: ACPI event status I/O port number: 1024
> >
> > пн, 27 апр. 2026 г. в 23:31, Rafael J. Wysocki <rafael@kernel.org>:
> > >
> > > On Monday, April 27, 2026 10:12:33 PM CEST Evgeny Sagatov wrote:
> > > > dmesg | grep "frequency scaling"
> > > > [    8.552380] acpi_cpufreq: CPU0: Using I/O space for frequency scaling
> > > > [    8.552386] acpi_cpufreq: CPU0: frequency scaling I/O port number: 2176
> > > > [    8.552478] acpi_cpufreq: CPU1: Using I/O space for frequency scaling
> > > > [    8.552480] acpi_cpufreq: CPU1: frequency scaling I/O port number: 2176
> > > > [    8.552584] acpi_cpufreq: CPU2: Using I/O space for frequency scaling
> > > > [    8.552586] acpi_cpufreq: CPU2: frequency scaling I/O port number: 2176
> > > > [    8.552668] acpi_cpufreq: CPU3: Using I/O space for frequency scaling
> > > > [    8.552670] acpi_cpufreq: CPU3: frequency scaling I/O port number: 2176
>
> The I/O ports that play the role in this issue are separate from each other in
> the address space, but that need not mean that they are physically independent.
>
> My current theory is that accessing one of them while an access to the other
> one is still in progress may cause the platform to lock up, or there is an
> access pattern that causes that to happen.
>
> Let's first test the simplest variant of that theory and see what happens if
> all I/O port accesses in acpi_os_write_port() are serialized, which is done
> in the patch below (it is a replacement for all of the patches sent so far).
>
> In addition, that patch causes schedutil to use the slow path for updating the
> frequency because the I/O space is generally somewhat too slow to be used
> from the scheduler context relatively often, but that should not affect the
> behavior related to I/O space accesses.
>
> Please check if the system still locks up after pressing the power button
> with this patch applied.
>
> ---
>  drivers/acpi/osl.c             |    9 +++++++--
>  drivers/cpufreq/acpi-cpufreq.c |    9 ++++++---
>  2 files changed, 13 insertions(+), 5 deletions(-)
>
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -700,8 +700,10 @@ EXPORT_SYMBOL(acpi_os_read_port);
>
>  acpi_status acpi_os_write_port(acpi_io_address port, u32 value, u32 width)
>  {
> -       if (!IS_ENABLED(CONFIG_HAS_IOPORT))
> -               return AE_NOT_IMPLEMENTED;
> +#ifdef CONFIG_HAS_IOPORT
> +       static DEFINE_RAW_SPINLOCK(acpi_os_write_port_lock);
> +
> +       guard(raw_spinlock_irqsave)(&acpi_os_write_port_lock);
>
>         if (width <= 8) {
>                 outb(value, port);
> @@ -715,6 +717,9 @@ acpi_status acpi_os_write_port(acpi_io_a
>         }
>
>         return AE_OK;
> +#else
> +       return AE_NOT_IMPLEMENTED;
> +#endif
>  }
>
>  EXPORT_SYMBOL(acpi_os_write_port);
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -878,6 +878,10 @@ static int acpi_cpufreq_cpu_init(struct
>         policy->freq_table = freq_table;
>         perf->state = 0;
>
> +       policy->fast_switch_possible = !acpi_pstate_strict &&
> +               !(policy_is_shared(policy) &&
> +                 policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
> +
>         switch (perf->control_register.space_id) {
>         case ACPI_ADR_SPACE_SYSTEM_IO:
>                 /*
> @@ -887,6 +891,8 @@ static int acpi_cpufreq_cpu_init(struct
>                  * unknown and not detectable via IO ports.
>                  */
>                 policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
> +               /* I/O spcase is too slow for fast switching. */
> +               policy->fast_switch_possible = false;
>                 break;
>         case ACPI_ADR_SPACE_FIXED_HARDWARE:
>                 acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> @@ -912,9 +918,6 @@ static int acpi_cpufreq_cpu_init(struct
>          */
>         data->resume = 1;
>
> -       policy->fast_switch_possible = !acpi_pstate_strict &&
> -               !(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
> -
>         if (perf->states[0].core_frequency * 1000 != freq_table[0].frequency)
>                 pr_warn(FW_WARN "P-state 0 is not max freq\n");
>
>
>
>

Re: Pressing the power button causes the device to freeze completely

[Rafael J. Wysocki]

On Tuesday, April 28, 2026 9:11:34 PM CEST Evgeny Sagatov wrote:
> Yes, the PC froze when I pressed the power button.

Well, in that case, let's try to serialize all accesses to I/O ports
used in the ACPI code.

The patch below replaces the previous one, please give it a go.

---
 drivers/acpi/osl.c             |    6 ++++++
 drivers/cpufreq/acpi-cpufreq.c |    4 +++-
 2 files changed, 9 insertions(+), 1 deletion(-)

--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -664,6 +664,8 @@ u64 acpi_os_get_timer(void)
 		(ACPI_100NSEC_PER_SEC / HZ);
 }
 
+static DEFINE_RAW_SPINLOCK(acpi_os_port_lock);
+
 acpi_status acpi_os_read_port(acpi_io_address port, u32 *value, u32 width)
 {
 	u32 dummy;
@@ -682,6 +684,8 @@ acpi_status acpi_os_read_port(acpi_io_ad
 	else
 		value = &dummy;
 
+	guard(raw_spinlock_irqsave)(&acpi_os_port_lock);
+
 	if (width <= 8) {
 		*value = inb(port);
 	} else if (width <= 16) {
@@ -703,6 +707,8 @@ acpi_status acpi_os_write_port(acpi_io_a
 	if (!IS_ENABLED(CONFIG_HAS_IOPORT))
 		return AE_NOT_IMPLEMENTED;
 
+	guard(raw_spinlock_irqsave)(&acpi_os_port_lock);
+
 	if (width <= 8) {
 		outb(value, port);
 	} else if (width <= 16) {
--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -913,7 +913,9 @@ static int acpi_cpufreq_cpu_init(struct
 	data->resume = 1;
 
 	policy->fast_switch_possible = !acpi_pstate_strict &&
-		!(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
+		(!policy_is_shared(policy) ||
+		 policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) &&
+		perf->control_register.space_id != ACPI_ADR_SPACE_SYSTEM_IO;
 
 	if (perf->states[0].core_frequency * 1000 != freq_table[0].frequency)
 		pr_warn(FW_WARN "P-state 0 is not max freq\n");

Re: Pressing the power button causes the device to freeze completely

[Evgeny Sagatov]

The PC also froze with this patch when I pressed the power button.

вт, 28 апр. 2026 г. в 22:58, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Tuesday, April 28, 2026 9:11:34 PM CEST Evgeny Sagatov wrote:
> > Yes, the PC froze when I pressed the power button.
>
> Well, in that case, let's try to serialize all accesses to I/O ports
> used in the ACPI code.
>
> The patch below replaces the previous one, please give it a go.
>
> ---
>  drivers/acpi/osl.c             |    6 ++++++
>  drivers/cpufreq/acpi-cpufreq.c |    4 +++-
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -664,6 +664,8 @@ u64 acpi_os_get_timer(void)
>                 (ACPI_100NSEC_PER_SEC / HZ);
>  }
>
> +static DEFINE_RAW_SPINLOCK(acpi_os_port_lock);
> +
>  acpi_status acpi_os_read_port(acpi_io_address port, u32 *value, u32 width)
>  {
>         u32 dummy;
> @@ -682,6 +684,8 @@ acpi_status acpi_os_read_port(acpi_io_ad
>         else
>                 value = &dummy;
>
> +       guard(raw_spinlock_irqsave)(&acpi_os_port_lock);
> +
>         if (width <= 8) {
>                 *value = inb(port);
>         } else if (width <= 16) {
> @@ -703,6 +707,8 @@ acpi_status acpi_os_write_port(acpi_io_a
>         if (!IS_ENABLED(CONFIG_HAS_IOPORT))
>                 return AE_NOT_IMPLEMENTED;
>
> +       guard(raw_spinlock_irqsave)(&acpi_os_port_lock);
> +
>         if (width <= 8) {
>                 outb(value, port);
>         } else if (width <= 16) {
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -913,7 +913,9 @@ static int acpi_cpufreq_cpu_init(struct
>         data->resume = 1;
>
>         policy->fast_switch_possible = !acpi_pstate_strict &&
> -               !(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
> +               (!policy_is_shared(policy) ||
> +                policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) &&
> +               perf->control_register.space_id != ACPI_ADR_SPACE_SYSTEM_IO;
>
>         if (perf->states[0].core_frequency * 1000 != freq_table[0].frequency)
>                 pr_warn(FW_WARN "P-state 0 is not max freq\n");
>
>
>

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Rafael J. Wysocki]

On Tue, Apr 28, 2026 at 11:05 PM Evgeny Sagatov
<evgeny.sagatov@gmail.com> wrote:
>
> The PC also froze with this patch when I pressed the power button.

Which means that the issue is not simply a matter of the lack of
synchronization between different I/O space accesses, so most likely
the problem lies deeper.

Let me summarize what we've learned so far (and expand the CC list somewhat).

For those who have not seen the previous discussion, it is at:

https://lore.kernel.org/lkml/CAGAxtY2SEkx7OgMgM5ypA8qsBN0h6pcs111VjnhD-5ZGq7Je6Q@mail.gmail.com/#r

1. The issue is basically that the platform locks up completely when
the power button is pressed

This is reproducible 100% of the time.

The power button processing flow is that, if the power button event is
enabled in the ACPI PM1_ENABLE register, pressing the button causes
the corresponding status bit in the ACPI PM1_STATUS register to be
set, which in turn causes an ACPI interrupt (SCI) to trigger (both
PM1_STATUS and PM1_ENABLE registers are accessible through the I/O
address space).

The SCI processing involves reading both the power button status and
enable bits and clearing the former if set (this needs to be done or
an interrupt storm would start if the status bit was not cleared).

We don't actually know which of the steps above specifically causes
the platform to lock up, but that doesn't matter too much because all
of them are necessary.

Clearing the power button enable bit in PM1_ENABLE prevents the issue
from occurring (but then the power button obviously doesn't work).

2. The issue only occurs if the schedutil cpufreq governor is used

If either the "powersave" or "ondemand" governor is used instead, the
issue doesn't appear.

Also switching over to a different cpufreq governor (on all CPUs)
before pressing the power button makes the issue go away.

3. The issue didn't occur at all before commit e37617c8e53a
("sched/fair: Fix frequency selection for non-invariant case")

Reverting the merge that introduced commit e37617c8e53a into the
mainline makes the issue go away.

4. The issue occurs regardless of how schedutil invokes the cpufreq
driver ("fast switch" vs sugov_deferred_update())

5. The cpufreq driver in question is acpi-cpufreq and it uses a
control register located in the I/O address space (the same control
register is used for all CPUs)

6. If acpi-cpufreq is not allowed to write into the control register
at all, the issue doesn't occur

7. Synchronizing all of the I/O space accesses in the ACPI-related
code (via a spinlock), including acpi-cpufreq, doesn't prevent the
issue from occurring

So overall, it looks like the control register access pattern in
acpi-cpufreq that results from schedutil's use of it after commit
e37617c8e53a somehow puts the platform into a state in which a power
button event causes it to lock up at the hardware level.

While there are a couple of things more to check, I'm afraid that
there may not be a viable way to address this issue other than
replacing the schedutil governor with ondemand on this platform.

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Rafael J. Wysocki]

On Wednesday, April 29, 2026 8:24:02 PM CEST Rafael J. Wysocki wrote:
> On Tue, Apr 28, 2026 at 11:05 PM Evgeny Sagatov
> <evgeny.sagatov@gmail.com> wrote:
> >
> > The PC also froze with this patch when I pressed the power button.
> 
> Which means that the issue is not simply a matter of the lack of
> synchronization between different I/O space accesses, so most likely
> the problem lies deeper.
> 
> Let me summarize what we've learned so far (and expand the CC list somewhat).
> 
> For those who have not seen the previous discussion, it is at:
> 
> https://lore.kernel.org/lkml/CAGAxtY2SEkx7OgMgM5ypA8qsBN0h6pcs111VjnhD-5ZGq7Je6Q@mail.gmail.com/#r
> 
> 1. The issue is basically that the platform locks up completely when
> the power button is pressed
> 
> This is reproducible 100% of the time.
> 
> The power button processing flow is that, if the power button event is
> enabled in the ACPI PM1_ENABLE register, pressing the button causes
> the corresponding status bit in the ACPI PM1_STATUS register to be
> set, which in turn causes an ACPI interrupt (SCI) to trigger (both
> PM1_STATUS and PM1_ENABLE registers are accessible through the I/O
> address space).
> 
> The SCI processing involves reading both the power button status and
> enable bits and clearing the former if set (this needs to be done or
> an interrupt storm would start if the status bit was not cleared).
> 
> We don't actually know which of the steps above specifically causes
> the platform to lock up, but that doesn't matter too much because all
> of them are necessary.
> 
> Clearing the power button enable bit in PM1_ENABLE prevents the issue
> from occurring (but then the power button obviously doesn't work).
> 
> 2. The issue only occurs if the schedutil cpufreq governor is used
> 
> If either the "powersave" or "ondemand" governor is used instead, the
> issue doesn't appear.
> 
> Also switching over to a different cpufreq governor (on all CPUs)
> before pressing the power button makes the issue go away.
> 
> 3. The issue didn't occur at all before commit e37617c8e53a
> ("sched/fair: Fix frequency selection for non-invariant case")
> 
> Reverting the merge that introduced commit e37617c8e53a into the
> mainline makes the issue go away.
> 
> 4. The issue occurs regardless of how schedutil invokes the cpufreq
> driver ("fast switch" vs sugov_deferred_update())
> 
> 5. The cpufreq driver in question is acpi-cpufreq and it uses a
> control register located in the I/O address space (the same control
> register is used for all CPUs)
> 
> 6. If acpi-cpufreq is not allowed to write into the control register
> at all, the issue doesn't occur
> 
> 7. Synchronizing all of the I/O space accesses in the ACPI-related
> code (via a spinlock), including acpi-cpufreq, doesn't prevent the
> issue from occurring
> 
> So overall, it looks like the control register access pattern in
> acpi-cpufreq that results from schedutil's use of it after commit
> e37617c8e53a somehow puts the platform into a state in which a power
> button event causes it to lock up at the hardware level.
> 
> While there are a couple of things more to check, I'm afraid that
> there may not be a viable way to address this issue other than
> replacing the schedutil governor with ondemand on this platform.

Below is one more patch to try.  It should cause acpi-cpufreq to use
one shared cpufreq policy instead of 4 per-CPU policies which is
more adequate because the CPUs share one control register.  It should
also cause acpi-cpufreq to update the control register only on CPU0.

Let's see if this changes the control register access pattern sufficiently
to work around the power button problem.

In any case, please send the output of

$ grep -r . /sys/devices/system/cpu/cpufreq/

from a kernel with this patch applied.

---
 drivers/cpufreq/acpi-cpufreq.c |   10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -743,7 +743,7 @@ static int acpi_cpufreq_cpu_init(struct
 	if (result)
 		goto err_free_mask;
 
-	policy->shared_type = perf->shared_type;
+	policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
 
 	/*
 	 * Will let policy->cpus know about dependency only when software
@@ -751,9 +751,9 @@ static int acpi_cpufreq_cpu_init(struct
 	 */
 	if (policy->shared_type == CPUFREQ_SHARED_TYPE_ALL ||
 	    policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {
-		cpumask_copy(policy->cpus, perf->shared_cpu_map);
+		cpumask_copy(policy->cpus, cpu_present_mask);
 	}
-	cpumask_copy(data->freqdomain_cpus, perf->shared_cpu_map);
+	cpumask_copy(data->freqdomain_cpus, cpu_present_mask);
 
 #ifdef CONFIG_SMP
 	dmi_check_system(sw_any_bug_dmi_table);
@@ -913,7 +913,9 @@ static int acpi_cpufreq_cpu_init(struct
 	data->resume = 1;
 
 	policy->fast_switch_possible = !acpi_pstate_strict &&
-		!(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
+		(!policy_is_shared(policy) ||
+		 policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) &&
+		perf->control_register.space_id != ACPI_ADR_SPACE_SYSTEM_IO;
 
 	if (perf->states[0].core_frequency * 1000 != freq_table[0].frequency)
 		pr_warn(FW_WARN "P-state 0 is not max freq\n");

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Evgeny Sagatov]

The PC froze when I pressed the power button.

grep -r . /sys/devices/system/cpu/cpufreq/
/sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:performance
schedutil
/sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:schedutil
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:2834000
2000000
/sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:1999759
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Отказано в доступе
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:   From  :    To
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:         :
2834000   2000000
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2834000:
      0       844
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
    843         0
/sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:1687
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 1164
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 14130
/sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:160000
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_avg_freq:1999759
/sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000

ср, 29 апр. 2026 г. в 23:22, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Wednesday, April 29, 2026 8:24:02 PM CEST Rafael J. Wysocki wrote:
> > On Tue, Apr 28, 2026 at 11:05 PM Evgeny Sagatov
> > <evgeny.sagatov@gmail.com> wrote:
> > >
> > > The PC also froze with this patch when I pressed the power button.
> >
> > Which means that the issue is not simply a matter of the lack of
> > synchronization between different I/O space accesses, so most likely
> > the problem lies deeper.
> >
> > Let me summarize what we've learned so far (and expand the CC list somewhat).
> >
> > For those who have not seen the previous discussion, it is at:
> >
> > https://lore.kernel.org/lkml/CAGAxtY2SEkx7OgMgM5ypA8qsBN0h6pcs111VjnhD-5ZGq7Je6Q@mail.gmail.com/#r
> >
> > 1. The issue is basically that the platform locks up completely when
> > the power button is pressed
> >
> > This is reproducible 100% of the time.
> >
> > The power button processing flow is that, if the power button event is
> > enabled in the ACPI PM1_ENABLE register, pressing the button causes
> > the corresponding status bit in the ACPI PM1_STATUS register to be
> > set, which in turn causes an ACPI interrupt (SCI) to trigger (both
> > PM1_STATUS and PM1_ENABLE registers are accessible through the I/O
> > address space).
> >
> > The SCI processing involves reading both the power button status and
> > enable bits and clearing the former if set (this needs to be done or
> > an interrupt storm would start if the status bit was not cleared).
> >
> > We don't actually know which of the steps above specifically causes
> > the platform to lock up, but that doesn't matter too much because all
> > of them are necessary.
> >
> > Clearing the power button enable bit in PM1_ENABLE prevents the issue
> > from occurring (but then the power button obviously doesn't work).
> >
> > 2. The issue only occurs if the schedutil cpufreq governor is used
> >
> > If either the "powersave" or "ondemand" governor is used instead, the
> > issue doesn't appear.
> >
> > Also switching over to a different cpufreq governor (on all CPUs)
> > before pressing the power button makes the issue go away.
> >
> > 3. The issue didn't occur at all before commit e37617c8e53a
> > ("sched/fair: Fix frequency selection for non-invariant case")
> >
> > Reverting the merge that introduced commit e37617c8e53a into the
> > mainline makes the issue go away.
> >
> > 4. The issue occurs regardless of how schedutil invokes the cpufreq
> > driver ("fast switch" vs sugov_deferred_update())
> >
> > 5. The cpufreq driver in question is acpi-cpufreq and it uses a
> > control register located in the I/O address space (the same control
> > register is used for all CPUs)
> >
> > 6. If acpi-cpufreq is not allowed to write into the control register
> > at all, the issue doesn't occur
> >
> > 7. Synchronizing all of the I/O space accesses in the ACPI-related
> > code (via a spinlock), including acpi-cpufreq, doesn't prevent the
> > issue from occurring
> >
> > So overall, it looks like the control register access pattern in
> > acpi-cpufreq that results from schedutil's use of it after commit
> > e37617c8e53a somehow puts the platform into a state in which a power
> > button event causes it to lock up at the hardware level.
> >
> > While there are a couple of things more to check, I'm afraid that
> > there may not be a viable way to address this issue other than
> > replacing the schedutil governor with ondemand on this platform.
>
> Below is one more patch to try.  It should cause acpi-cpufreq to use
> one shared cpufreq policy instead of 4 per-CPU policies which is
> more adequate because the CPUs share one control register.  It should
> also cause acpi-cpufreq to update the control register only on CPU0.
>
> Let's see if this changes the control register access pattern sufficiently
> to work around the power button problem.
>
> In any case, please send the output of
>
> $ grep -r . /sys/devices/system/cpu/cpufreq/
>
> from a kernel with this patch applied.
>
> ---
>  drivers/cpufreq/acpi-cpufreq.c |   10 ++++++----
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -743,7 +743,7 @@ static int acpi_cpufreq_cpu_init(struct
>         if (result)
>                 goto err_free_mask;
>
> -       policy->shared_type = perf->shared_type;
> +       policy->shared_type = CPUFREQ_SHARED_TYPE_ANY;
>
>         /*
>          * Will let policy->cpus know about dependency only when software
> @@ -751,9 +751,9 @@ static int acpi_cpufreq_cpu_init(struct
>          */
>         if (policy->shared_type == CPUFREQ_SHARED_TYPE_ALL ||
>             policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) {
> -               cpumask_copy(policy->cpus, perf->shared_cpu_map);
> +               cpumask_copy(policy->cpus, cpu_present_mask);
>         }
> -       cpumask_copy(data->freqdomain_cpus, perf->shared_cpu_map);
> +       cpumask_copy(data->freqdomain_cpus, cpu_present_mask);
>
>  #ifdef CONFIG_SMP
>         dmi_check_system(sw_any_bug_dmi_table);
> @@ -913,7 +913,9 @@ static int acpi_cpufreq_cpu_init(struct
>         data->resume = 1;
>
>         policy->fast_switch_possible = !acpi_pstate_strict &&
> -               !(policy_is_shared(policy) && policy->shared_type != CPUFREQ_SHARED_TYPE_ANY);
> +               (!policy_is_shared(policy) ||
> +                policy->shared_type == CPUFREQ_SHARED_TYPE_ANY) &&
> +               perf->control_register.space_id != ACPI_ADR_SPACE_SYSTEM_IO;
>
>         if (perf->states[0].core_frequency * 1000 != freq_table[0].frequency)
>                 pr_warn(FW_WARN "P-state 0 is not max freq\n");
>
>
>

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Rafael J. Wysocki]

On Wed, Apr 29, 2026 at 11:17 PM Evgeny Sagatov
<evgeny.sagatov@gmail.com> wrote:
>
> The PC froze when I pressed the power button.

Well, we need to dig more I guess.

> grep -r . /sys/devices/system/cpu/cpufreq/
> /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
> /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:performance
> schedutil
> /sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
> /sys/devices/system/cpu/cpufreq/policy0/scaling_governor:schedutil
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:2834000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:2834000
> 2000000
> /sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
> /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:1999759

This kind of calls for some investigation.  It should not be less than
scaling_min_freq, even though this looks like a rounding error.

> /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
> grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Отказано в доступе
> /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:   From  :    To
> /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:         :
> 2834000   2000000
> /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2834000:
>       0       844
> /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
>     843         0
> /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:1687
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 1164
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 14130
> /sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
> /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2834000
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:160000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_driver:acpi-cpufreq
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:2000000
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_avg_freq:1999759
> /sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000

So with the same patch applied (because I think that the one-policy
configuration is suitable for this platform), please capture the
output of

grep -r . /sys/devices/system/cpu/cpufreq/

switch over to the ondemand governor, wait for some time, capture the
output of the above command again and send both.

Also, please send the output of

grep . /sys/firmware/acpi/interrupts/sci*

acquired after doing all of the above.

You may as well check again if the power button works after switching
to ondemand.

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Rafael J. Wysocki]

On Thu, Apr 30, 2026 at 12:40 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Wed, Apr 29, 2026 at 11:17 PM Evgeny Sagatov
> <evgeny.sagatov@gmail.com> wrote:
> >
> > The PC froze when I pressed the power button.
>
> Well, we need to dig more I guess.
>
> > grep -r . /sys/devices/system/cpu/cpufreq/
> > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
> > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
> > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:performance
> > schedutil
> > /sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
> > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor:schedutil
> > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:2834000
> > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:2834000
> > 2000000
> > /sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
> > /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:1999759
>
> This kind of calls for some investigation.  It should not be less than
> scaling_min_freq, even though this looks like a rounding error.
>
> > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
> > grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Отказано в доступе
> > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:   From  :    To
> > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:         :
> > 2834000   2000000
> > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2834000:
> >       0       844
> > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
> >     843         0
> > /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:1687
> > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 1164
> > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 14130
> > /sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
> > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2834000
> > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:160000
> > /sys/devices/system/cpu/cpufreq/policy0/scaling_driver:acpi-cpufreq
> > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:2000000
> > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_avg_freq:1999759
> > /sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000
>
> So with the same patch applied (because I think that the one-policy
> configuration is suitable for this platform), please capture the
> output of
>
> grep -r . /sys/devices/system/cpu/cpufreq/

Actually, the step above isn't necessary.

> switch over to the ondemand governor,

It is better to reset the cpufreq statistics after switching over to
ondemand by writing 1 to

/sys/devices/system/cpu/cpufreq/policy0/stats/reset

as root.  Then, wait for some time and capture the output of

grep -r . /sys/devices/system/cpu/cpufreq/

just once.

> wait for some time, capture the
> output of the above command again and send both.
>
> Also, please send the output of
>
> grep . /sys/firmware/acpi/interrupts/sci*
>
> acquired after doing all of the above.
>
> You may as well check again if the power button works after switching
> to ondemand.

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Evgeny Sagatov]

I noticed that for powersave mode, I'm getting the following values:
cat /proc/cpuinfo | grep MHz
cpu MHz         : 2798.689
cpu MHz         : 1999.659
cpu MHz         : 1999.797
cpu MHz         : 2741.103
Also, there's now no difference in the single-core benchmark between
schedutil, ondemand, powersave and performance modes. The benchmark
always gives a very high result.
This wasn't the case before; the modes had different performance levels.

I switched to ondemand, did a reset and waited a few minutes:
grep -r . /sys/devices/system/cpu/cpufreq/
/sys/devices/system/cpu/cpufreq/ondemand/up_threshold:95
/sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load:0
/sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor:1
/sys/devices/system/cpu/cpufreq/ondemand/powersave_bias:0
/sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:8000
/sys/devices/system/cpu/cpufreq/ondemand/io_is_busy:1
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand
performance schedutil
/sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:2834000
2000000
/sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Access denied
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:   From  :    To
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:         :
2834000   2000000
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2834000:
      0        80
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
     80         0
/sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:160
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 397
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 68525
/sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:160000
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_avg_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000

чт, 30 апр. 2026 г. в 13:53, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Thu, Apr 30, 2026 at 12:40 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Wed, Apr 29, 2026 at 11:17 PM Evgeny Sagatov
> > <evgeny.sagatov@gmail.com> wrote:
> > >
> > > The PC froze when I pressed the power button.
> >
> > Well, we need to dig more I guess.
> >
> > > grep -r . /sys/devices/system/cpu/cpufreq/
> > > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
> > > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
> > > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:performance
> > > schedutil
> > > /sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
> > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor:schedutil
> > > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:2834000
> > > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:2834000
> > > 2000000
> > > /sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
> > > /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:1999759
> >
> > This kind of calls for some investigation.  It should not be less than
> > scaling_min_freq, even though this looks like a rounding error.
> >
> > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
> > > grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Отказано в доступе
> > > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:   From  :    To
> > > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:         :
> > > 2834000   2000000
> > > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2834000:
> > >       0       844
> > > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
> > >     843         0
> > > /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:1687
> > > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 1164
> > > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 14130
> > > /sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
> > > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2834000
> > > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:160000
> > > /sys/devices/system/cpu/cpufreq/policy0/scaling_driver:acpi-cpufreq
> > > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:2000000
> > > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_avg_freq:1999759
> > > /sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000
> >
> > So with the same patch applied (because I think that the one-policy
> > configuration is suitable for this platform), please capture the
> > output of
> >
> > grep -r . /sys/devices/system/cpu/cpufreq/
>
> Actually, the step above isn't necessary.
>
> > switch over to the ondemand governor,
>
> It is better to reset the cpufreq statistics after switching over to
> ondemand by writing 1 to
>
> /sys/devices/system/cpu/cpufreq/policy0/stats/reset
>
> as root.  Then, wait for some time and capture the output of
>
> grep -r . /sys/devices/system/cpu/cpufreq/
>
> just once.
>
> > wait for some time, capture the
> > output of the above command again and send both.
> >
> > Also, please send the output of
> >
> > grep . /sys/firmware/acpi/interrupts/sci*
> >
> > acquired after doing all of the above.
> >
> > You may as well check again if the power button works after switching
> > to ondemand.

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Evgeny Sagatov]

I forgot to say that in ondemand mode, when I pressed the power
button, the PC did not freeze.

чт, 30 апр. 2026 г. в 14:41, Evgeny Sagatov <evgeny.sagatov@gmail.com>:
>
> I noticed that for powersave mode, I'm getting the following values:
> cat /proc/cpuinfo | grep MHz
> cpu MHz         : 2798.689
> cpu MHz         : 1999.659
> cpu MHz         : 1999.797
> cpu MHz         : 2741.103
> Also, there's now no difference in the single-core benchmark between
> schedutil, ondemand, powersave and performance modes. The benchmark
> always gives a very high result.
> This wasn't the case before; the modes had different performance levels.
>
> I switched to ondemand, did a reset and waited a few minutes:
> grep -r . /sys/devices/system/cpu/cpufreq/
> /sys/devices/system/cpu/cpufreq/ondemand/up_threshold:95
> /sys/devices/system/cpu/cpufreq/ondemand/ignore_nice_load:0
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor:1
> /sys/devices/system/cpu/cpufreq/ondemand/powersave_bias:0
> /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate:8000
> /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy:1
> /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:ondemand
> performance schedutil
> /sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
> /sys/devices/system/cpu/cpufreq/policy0/scaling_governor:ondemand
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:2834000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:2834000
> 2000000
> /sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
> /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:2000000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
> grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Access denied
> /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:   From  :    To
> /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:         :
> 2834000   2000000
> /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2834000:
>       0        80
> /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
>      80         0
> /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:160
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 397
> /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 68525
> /sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
> /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2834000
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:160000
> /sys/devices/system/cpu/cpufreq/policy0/scaling_driver:acpi-cpufreq
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:2000000
> /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_avg_freq:2000000
> /sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000
>
> чт, 30 апр. 2026 г. в 13:53, Rafael J. Wysocki <rafael@kernel.org>:
> >
> > On Thu, Apr 30, 2026 at 12:40 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Wed, Apr 29, 2026 at 11:17 PM Evgeny Sagatov
> > > <evgeny.sagatov@gmail.com> wrote:
> > > >
> > > > The PC froze when I pressed the power button.
> > >
> > > Well, we need to dig more I guess.
> > >
> > > > grep -r . /sys/devices/system/cpu/cpufreq/
> > > > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us:240
> > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
> > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:performance
> > > > schedutil
> > > > /sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
> > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor:schedutil
> > > > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:2834000
> > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:2834000
> > > > 2000000
> > > > /sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
> > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:1999759
> > >
> > > This kind of calls for some investigation.  It should not be less than
> > > scaling_min_freq, even though this looks like a rounding error.
> > >
> > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
> > > > grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Отказано в доступе
> > > > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:   From  :    To
> > > > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:         :
> > > > 2834000   2000000
> > > > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2834000:
> > > >       0       844
> > > > /sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
> > > >     843         0
> > > > /sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:1687
> > > > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 1164
> > > > /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 14130
> > > > /sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
> > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2834000
> > > > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:160000
> > > > /sys/devices/system/cpu/cpufreq/policy0/scaling_driver:acpi-cpufreq
> > > > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:2000000
> > > > /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_avg_freq:1999759
> > > > /sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000
> > >
> > > So with the same patch applied (because I think that the one-policy
> > > configuration is suitable for this platform), please capture the
> > > output of
> > >
> > > grep -r . /sys/devices/system/cpu/cpufreq/
> >
> > Actually, the step above isn't necessary.
> >
> > > switch over to the ondemand governor,
> >
> > It is better to reset the cpufreq statistics after switching over to
> > ondemand by writing 1 to
> >
> > /sys/devices/system/cpu/cpufreq/policy0/stats/reset
> >
> > as root.  Then, wait for some time and capture the output of
> >
> > grep -r . /sys/devices/system/cpu/cpufreq/
> >
> > just once.
> >
> > > wait for some time, capture the
> > > output of the above command again and send both.
> > >
> > > Also, please send the output of
> > >
> > > grep . /sys/firmware/acpi/interrupts/sci*
> > >
> > > acquired after doing all of the above.
> > >
> > > You may as well check again if the power button works after switching
> > > to ondemand.

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Rafael J. Wysocki]

On Thu, Apr 30, 2026 at 1:58 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
>
> I forgot to say that in ondemand mode, when I pressed the power
> button, the PC did not freeze.

OK

I think that's because ondemand changes the CPU frequency 10 times
less frequently than schedutil.

Writing a sufficiently large number to

/sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us

when schedutil is the cpufreq governor may help, but I actually don't
know how large that number would need to be.

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Evgeny Sagatov]

> I guess you mean with the powersave governor.

That's the thing, I get these weird values in powersave mode.

> I would expect schedutil, ondemand and performance to give similar
> scores, but for powersave I would expect the score to be lower.

I did some measurements earlier. I got roughly the same values in
schedutil and performance modes. In ondemand mode, it was 7% lower. In
powersave mode, it was significantly lower, but I don't remember the
exact values.
Now, the values are at their maximum in all modes.

I see that the frequencies change frequently.

cat /proc/cpuinfo | grep MHz
cpu MHz         : 2000.000
cpu MHz         : 2000.000
cpu MHz         : 2673.037
cpu MHz         : 2601.029

But I don't see this reflected in the statistics.

grep -r . /sys/devices/system/cpu/cpufreq/
/sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_governors:powersave
performance schedutil
/sys/devices/system/cpu/cpufreq/policy0/freqdomain_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_governor:powersave
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies:2834000
2000000
/sys/devices/system/cpu/cpufreq/policy0/related_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_cur_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/scaling_setspeed:<unsupported>
grep: /sys/devices/system/cpu/cpufreq/policy0/stats/reset: Access denied
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:   From  :    To
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:         :
2834000   2000000
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2834000:
      0         0
/sys/devices/system/cpu/cpufreq/policy0/stats/trans_table:  2000000:
      0         0
/sys/devices/system/cpu/cpufreq/policy0/stats/total_trans:0
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2834000 0
/sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state:2000000 8222
/sys/devices/system/cpu/cpufreq/policy0/affected_cpus:0 1 2 3
/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq:2834000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency:160000
/sys/devices/system/cpu/cpufreq/policy0/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/cpuinfo_avg_freq:2000000
/sys/devices/system/cpu/cpufreq/policy0/bios_limit:2834000

grep . /sys/firmware/acpi/interrupts/sci*
/sys/firmware/acpi/interrupts/sci:       0
/sys/firmware/acpi/interrupts/sci_not:       0


I tried this with the previous patch, and the kernel didn't freeze
when I pressed the button.
But with kernel 6.12.74, it doesn't work.
echo 100000 > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us

чт, 30 апр. 2026 г. в 17:10, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Thu, Apr 30, 2026 at 1:58 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
> >
> > I forgot to say that in ondemand mode, when I pressed the power
> > button, the PC did not freeze.
>
> OK
>
> I think that's because ondemand changes the CPU frequency 10 times
> less frequently than schedutil.
>
> Writing a sufficiently large number to
>
> /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us
>
> when schedutil is the cpufreq governor may help, but I actually don't
> know how large that number would need to be.

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Rafael J. Wysocki]

On Thu, Apr 30, 2026 at 1:41 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
>
> I noticed that for powersave mode, I'm getting the following values:

I guess you mean with the powersave governor.

> cat /proc/cpuinfo | grep MHz
> cpu MHz         : 2798.689
> cpu MHz         : 1999.659
> cpu MHz         : 1999.797
> cpu MHz         : 2741.103
> Also, there's now no difference in the single-core benchmark between
> schedutil, ondemand, powersave and performance modes. The benchmark
> always gives a very high result.
> This wasn't the case before; the modes had different performance levels.

I would expect schedutil, ondemand and performance to give similar
scores, but for powersave I would expect the score to be lower.

With the same patch applied, can you please switch over to powersave,
reset the stats and then capture the output of

grep -r . /sys/devices/system/cpu/cpufreq/

Also, I'd still like to see the output of

grep . /sys/firmware/acpi/interrupts/sci*

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Rafael J. Wysocki]

On Thursday, April 30, 2026 3:57:41 PM CEST Rafael J. Wysocki wrote:
> On Thu, Apr 30, 2026 at 1:41 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
> >
> > I noticed that for powersave mode, I'm getting the following values:
> 
> I guess you mean with the powersave governor.
> 
> > cat /proc/cpuinfo | grep MHz
> > cpu MHz         : 2798.689
> > cpu MHz         : 1999.659
> > cpu MHz         : 1999.797
> > cpu MHz         : 2741.103
> > Also, there's now no difference in the single-core benchmark between
> > schedutil, ondemand, powersave and performance modes. The benchmark
> > always gives a very high result.
> > This wasn't the case before; the modes had different performance levels.
> 
> I would expect schedutil, ondemand and performance to give similar
> scores, but for powersave I would expect the score to be lower.
> 
> With the same patch applied, can you please switch over to powersave,
> reset the stats and then capture the output of
> 
> grep -r . /sys/devices/system/cpu/cpufreq/
> 
> Also, I'd still like to see the output of
> 
> grep . /sys/firmware/acpi/interrupts/sci*

Additionally, please remove all of the debug patches sent so far, apply
the one below and send a dmesg boot log.

I want to check if all of the CPUs use the same control values when
they write to the frequency scaling control register.

---
 drivers/cpufreq/acpi-cpufreq.c |   12 +++++++++---
 drivers/cpufreq/cpufreq.c      |    1 +
 2 files changed, 10 insertions(+), 3 deletions(-)

--- a/drivers/cpufreq/acpi-cpufreq.c
+++ b/drivers/cpufreq/acpi-cpufreq.c
@@ -887,9 +887,14 @@ static int acpi_cpufreq_cpu_init(struct
 		 * unknown and not detectable via IO ports.
 		 */
 		policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
+		pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
+		pr_info("CPU%u: frequency scaling control address: %llu, bit width: %u\n",
+			cpu, perf->control_register.address,
+			perf->control_register.bit_width);
 		break;
 	case ACPI_ADR_SPACE_FIXED_HARDWARE:
 		acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
+		pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
 		break;
 	default:
 		break;
@@ -898,13 +903,14 @@ static int acpi_cpufreq_cpu_init(struct
 	/* notify BIOS that we exist */
 	acpi_processor_notify_smm(THIS_MODULE);
 
-	pr_debug("CPU%u - ACPI performance management activated.\n", cpu);
+	pr_info("CPU%u - ACPI performance management activated.\n", cpu);
 	for (i = 0; i < perf->state_count; i++)
-		pr_debug("     %cP%d: %d MHz, %d mW, %d uS\n",
+		pr_info("     %cP%d: %d MHz, %d mW, %d uS, %u\n",
 			(i == perf->state ? '*' : ' '), i,
 			(u32) perf->states[i].core_frequency,
 			(u32) perf->states[i].power,
-			(u32) perf->states[i].transition_latency);
+			(u32) perf->states[i].transition_latency,
+			(u32) perf->states[i].control);
 
 	/*
 	 * the first call to ->target() should result in us actually
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
 	if (cpufreq_fast_switch_count >= 0) {
 		cpufreq_fast_switch_count++;
 		policy->fast_switch_enabled = true;
+		pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
 	} else {
 		pr_warn("CPU%u: Fast frequency switching not enabled\n",
 			policy->cpu);

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Evgeny Sagatov]

[-- Attachment #1: Type: text/plain, Size: 4121 bytes --]

I have attached the dmesg log to the email.

чт, 30 апр. 2026 г. в 17:42, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Thursday, April 30, 2026 3:57:41 PM CEST Rafael J. Wysocki wrote:
> > On Thu, Apr 30, 2026 at 1:41 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
> > >
> > > I noticed that for powersave mode, I'm getting the following values:
> >
> > I guess you mean with the powersave governor.
> >
> > > cat /proc/cpuinfo | grep MHz
> > > cpu MHz         : 2798.689
> > > cpu MHz         : 1999.659
> > > cpu MHz         : 1999.797
> > > cpu MHz         : 2741.103
> > > Also, there's now no difference in the single-core benchmark between
> > > schedutil, ondemand, powersave and performance modes. The benchmark
> > > always gives a very high result.
> > > This wasn't the case before; the modes had different performance levels.
> >
> > I would expect schedutil, ondemand and performance to give similar
> > scores, but for powersave I would expect the score to be lower.
> >
> > With the same patch applied, can you please switch over to powersave,
> > reset the stats and then capture the output of
> >
> > grep -r . /sys/devices/system/cpu/cpufreq/
> >
> > Also, I'd still like to see the output of
> >
> > grep . /sys/firmware/acpi/interrupts/sci*
>
> Additionally, please remove all of the debug patches sent so far, apply
> the one below and send a dmesg boot log.
>
> I want to check if all of the CPUs use the same control values when
> they write to the frequency scaling control register.
>
> ---
>  drivers/cpufreq/acpi-cpufreq.c |   12 +++++++++---
>  drivers/cpufreq/cpufreq.c      |    1 +
>  2 files changed, 10 insertions(+), 3 deletions(-)
>
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -887,9 +887,14 @@ static int acpi_cpufreq_cpu_init(struct
>                  * unknown and not detectable via IO ports.
>                  */
>                 policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
> +               pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
> +               pr_info("CPU%u: frequency scaling control address: %llu, bit width: %u\n",
> +                       cpu, perf->control_register.address,
> +                       perf->control_register.bit_width);
>                 break;
>         case ACPI_ADR_SPACE_FIXED_HARDWARE:
>                 acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> +               pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
>                 break;
>         default:
>                 break;
> @@ -898,13 +903,14 @@ static int acpi_cpufreq_cpu_init(struct
>         /* notify BIOS that we exist */
>         acpi_processor_notify_smm(THIS_MODULE);
>
> -       pr_debug("CPU%u - ACPI performance management activated.\n", cpu);
> +       pr_info("CPU%u - ACPI performance management activated.\n", cpu);
>         for (i = 0; i < perf->state_count; i++)
> -               pr_debug("     %cP%d: %d MHz, %d mW, %d uS\n",
> +               pr_info("     %cP%d: %d MHz, %d mW, %d uS, %u\n",
>                         (i == perf->state ? '*' : ' '), i,
>                         (u32) perf->states[i].core_frequency,
>                         (u32) perf->states[i].power,
> -                       (u32) perf->states[i].transition_latency);
> +                       (u32) perf->states[i].transition_latency,
> +                       (u32) perf->states[i].control);
>
>         /*
>          * the first call to ->target() should result in us actually
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
>         if (cpufreq_fast_switch_count >= 0) {
>                 cpufreq_fast_switch_count++;
>                 policy->fast_switch_enabled = true;
> +               pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
>         } else {
>                 pr_warn("CPU%u: Fast frequency switching not enabled\n",
>                         policy->cpu);
>
>
>
>

[-- Attachment #2: dmesg.log --]
[-- Type: application/octet-stream, Size: 60560 bytes --]

[    0.000000] Linux version 7.0.3 (root@test) (gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC Fri May  1 01:00:35 MSK 2026
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-7.0.3 root=UUID=6d057775-1872-424c-857d-a9956029d8b0 ro i8042.noaux quiet
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x0000000000093bff]  System RAM
[    0.000000] BIOS-e820: [gap 0x0000000000093c00-0x000000000009f7ff]
[    0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff]  device reserved
[    0.000000] BIOS-e820: [gap 0x00000000000a0000-0x00000000000effff]
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff]  device reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000efedffff]  System RAM
[    0.000000] BIOS-e820: [mem 0x00000000efee0000-0x00000000efee1fff]  ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000efee2000-0x00000000efeeffff]  ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000efef0000-0x00000000efefffff]  device reserved
[    0.000000] BIOS-e820: [gap 0x00000000eff00000-0x00000000f7ffffff]
[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff]  device reserved
[    0.000000] BIOS-e820: [gap 0x00000000fc000000-0x00000000febfffff]
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000ffffffff]  device reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000040fffffff]  System RAM
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] APIC: Static calls initialized
[    0.000000] SMBIOS 2.4 present.
[    0.000000] DMI: Gigabyte Technology Co., Ltd. EP45T-UD3LR/EP45T-UD3LR, BIOS F12e 10/14/2011
[    0.000000] DMI: Memory slots populated: 4/4
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 2832.942 MHz processor
[    0.004657] e820: update [mem 0x00000000-0x00000fff] System RAM ==> device reserved
[    0.004661] e820: remove [mem 0x000a0000-0x000fffff] System RAM
[    0.004668] last_pfn = 0x410000 max_arch_pfn = 0x400000000
[    0.004675] MTRR map: 8 entries (5 fixed + 3 variable; max 21), built from 8 variable MTRRs
[    0.004678] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[    0.006184] e820: update [mem 0xeff00000-0xffffffff] System RAM ==> device reserved
[    0.006193] last_pfn = 0xefef0 max_arch_pfn = 0x400000000
[    0.011631] found SMP MP-table at [mem 0x000f5510-0x000f551f]
[    0.012257] RAMDISK: [mem 0x35dd5000-0x36ee1fff]
[    0.012306] ACPI: Early table checksum verification disabled
[    0.012309] ACPI: RSDP 0x00000000000F6F20 000014 (v00 GBT   )
[    0.012314] ACPI: RSDT 0x00000000EFEE2040 000040 (v01 GBT    GBTUACPI 42302E31 GBTU 01010101)
[    0.012320] ACPI: FACP 0x00000000EFEE20C0 000074 (v01 GBT    GBTUACPI 42302E31 GBTU 01010101)
[    0.012326] ACPI: DSDT 0x00000000EFEE2180 004BE1 (v01 GBT    GBTUACPI 00001000 MSFT 0100000C)
[    0.012330] ACPI: FACS 0x00000000EFEE0000 000040
[    0.012334] ACPI: HPET 0x00000000EFEE6EC0 000038 (v01 GBT    GBTUACPI 42302E31 GBTU 00000098)
[    0.012337] ACPI: MCFG 0x00000000EFEE6F40 00003C (v01 GBT    GBTUACPI 42302E31 GBTU 01010101)
[    0.012341] ACPI: EUDS 0x00000000EFEE6F80 000560 (v01 GBT             00000000      00000000)
[    0.012345] ACPI: TAMG 0x00000000EFEE74E0 00670A (v01 GBT    GBT   B0 5455312E BG?? 00020101)
[    0.012349] ACPI: APIC 0x00000000EFEE6DC0 000084 (v01 GBT    GBTUACPI 42302E31 GBTU 01010101)
[    0.012353] ACPI: SSDT 0x00000000EFEEE520 0003AB (v01 PmRef  CpuPm    00003000 INTL 20040311)
[    0.012356] ACPI: Reserving FACP table memory at [mem 0xefee20c0-0xefee2133]
[    0.012357] ACPI: Reserving DSDT table memory at [mem 0xefee2180-0xefee6d60]
[    0.012359] ACPI: Reserving FACS table memory at [mem 0xefee0000-0xefee003f]
[    0.012360] ACPI: Reserving HPET table memory at [mem 0xefee6ec0-0xefee6ef7]
[    0.012361] ACPI: Reserving MCFG table memory at [mem 0xefee6f40-0xefee6f7b]
[    0.012362] ACPI: Reserving EUDS table memory at [mem 0xefee6f80-0xefee74df]
[    0.012363] ACPI: Reserving TAMG table memory at [mem 0xefee74e0-0xefeedbe9]
[    0.012365] ACPI: Reserving APIC table memory at [mem 0xefee6dc0-0xefee6e43]
[    0.012366] ACPI: Reserving SSDT table memory at [mem 0xefeee520-0xefeee8ca]
[    0.012491] No NUMA configuration found
[    0.012492] Faking a node at [mem 0x0000000000000000-0x000000040fffffff]
[    0.012514] NODE_DATA(0) allocated [mem 0x40ffca500-0x40fff4fff]
[    0.012948] ACPI: PM-Timer IO Port: 0x408
[    0.012956] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
[    0.012958] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
[    0.012959] ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
[    0.012960] ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
[    0.012969] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
[    0.012973] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.012975] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[    0.012981] ACPI: Using ACPI (MADT) for SMP configuration information
[    0.012982] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[    0.012987] CPU topo: Max. logical packages:   1
[    0.012989] CPU topo: Max. logical nodes:      1
[    0.012989] CPU topo: Num. nodes per package:  1
[    0.012993] CPU topo: Max. logical dies:       1
[    0.012993] CPU topo: Max. dies per package:   1
[    0.012999] CPU topo: Max. threads per core:   1
[    0.013000] CPU topo: Num. cores per package:     4
[    0.013000] CPU topo: Num. threads per package:   4
[    0.013001] CPU topo: Allowing 4 present CPUs plus 0 hotplug CPUs
[    0.013013] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
[    0.013015] PM: hibernation: Registered nosave memory: [mem 0x00093000-0x000fffff]
[    0.013017] PM: hibernation: Registered nosave memory: [mem 0xefee0000-0xffffffff]
[    0.013019] [gap 0xeff00000-0xf7ffffff] available for PCI devices
[    0.013020] Booting paravirtualized kernel on bare hardware
[    0.013023] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[    0.022066] Zone ranges:
[    0.022066]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.022069]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
[    0.022071]   Normal   [mem 0x0000000100000000-0x000000040fffffff]
[    0.022073]   Device   empty
[    0.022074] Movable zone start for each node
[    0.022077] Early memory node ranges
[    0.022078]   node   0: [mem 0x0000000000001000-0x0000000000092fff]
[    0.022079]   node   0: [mem 0x0000000000100000-0x00000000efedffff]
[    0.022081]   node   0: [mem 0x0000000100000000-0x000000040fffffff]
[    0.022085] Initmem setup node 0 [mem 0x0000000000001000-0x000000040fffffff]
[    0.022092] On node 0, zone DMA: 1 pages in unavailable ranges
[    0.022130] On node 0, zone DMA: 109 pages in unavailable ranges
[    0.041922] On node 0, zone Normal: 288 pages in unavailable ranges
[    0.041944] setup_percpu: NR_CPUS:8192 nr_cpumask_bits:4 nr_cpu_ids:4 nr_node_ids:1
[    0.042786] percpu: Embedded 62 pages/cpu s217088 r8192 d28672 u524288
[    0.042792] pcpu-alloc: s217088 r8192 d28672 u524288 alloc=1*2097152
[    0.042795] pcpu-alloc: [0] 0 1 2 3 
[    0.042815] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-7.0.3 root=UUID=6d057775-1872-424c-857d-a9956029d8b0 ro i8042.noaux quiet
[    0.042880] printk: log buffer data + meta data: 131072 + 557056 = 688128 bytes
[    0.048124] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes, linear)
[    0.050829] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[    0.050932] software IO TLB: area num 4.
[    0.094404] Fallback order for Node 0: 0 
[    0.094412] Built 1 zonelists, mobility grouping on.  Total pages: 4193906
[    0.094414] Policy zone: Normal
[    0.094429] mem auto-init: stack:all(zero), heap alloc:on, heap free:off
[    0.136101] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.136258] Kernel/User page tables isolation: enabled
[    0.146305] ftrace: allocating 48838 entries in 192 pages
[    0.146310] ftrace: allocated 192 pages with 2 groups
[    0.147058] Dynamic Preempt: lazy
[    0.147208] rcu: Preemptible hierarchical RCU implementation.
[    0.147209] rcu: 	RCU restricting CPUs from NR_CPUS=8192 to nr_cpu_ids=4.
[    0.147211] 	Trampoline variant of Tasks RCU enabled.
[    0.147211] 	Rude variant of Tasks RCU enabled.
[    0.147212] 	Tracing variant of Tasks RCU enabled.
[    0.147213] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.147214] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.147230] RCU Tasks: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[    0.147233] RCU Tasks Rude: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[    0.154868] NR_IRQS: 524544, nr_irqs: 456, preallocated irqs: 16
[    0.155093] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[    0.159208] Console: colour VGA+ 80x25
[    0.159211] printk: legacy console [tty0] enabled
[    0.159471] ACPI: Core revision 20251212
[    0.159649] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
[    0.159663] APIC: Switch to symmetric I/O mode setup
[    0.160033] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.179664] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x28d5d015b9e, max_idle_ns: 440795304592 ns
[    0.179671] Calibrating delay loop (skipped), value calculated using timer frequency.. 5665.88 BogoMIPS (lpj=11331768)
[    0.179695] CPU0: Thermal monitoring enabled (TM2)
[    0.179717] Last level iTLB entries: 4KB 128, 2MB 4, 4MB 4
[    0.179719] Last level dTLB entries: 4KB 256, 2MB 0, 4MB 32, 1GB 0
[    0.179723] process: using mwait in idle threads
[    0.179726] mitigations: Enabled attack vectors: user_kernel, user_user, guest_host, guest_guest, SMT mitigations: auto
[    0.179732] Speculative Store Bypass: Vulnerable
[    0.179734] Spectre V2 : Mitigation: Retpolines
[    0.179736] MDS: Vulnerable: Clear CPU buffers attempted, no microcode
[    0.179738] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[    0.179739] Spectre V2 : Spectre v2 / SpectreRSB: Filling RSB on context switch and VMEXIT
[    0.179745] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.179747] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.179749] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format.
[    0.202583] Freeing SMP alternatives memory: 44K
[    0.202595] pid_max: default: 32768 minimum: 301
[    0.203536] landlock: Up and running.
[    0.203538] Yama: becoming mindful.
[    0.203656] AppArmor: AppArmor initialized
[    0.203686] TOMOYO Linux initialized
[    0.203937] LSM support for eBPF active
[    0.204361] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    0.204405] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    0.204623] VFS: Finished mounting rootfs on nullfs
[    0.314991] smpboot: CPU0: Intel(R) Core(TM)2 Quad CPU    Q9550  @ 2.83GHz (family: 0x6, model: 0x17, stepping: 0xa)
[    0.315337] Performance Events: PEBS fmt0+, Core2 events, 4-deep LBR, Intel PMU driver.
[    0.315355] ... version:                   2
[    0.315356] ... bit width:                 40
[    0.315358] ... generic counters:          2
[    0.315359] ... generic bitmap:            0000000000000003
[    0.315360] ... fixed-purpose counters:    3
[    0.315361] ... fixed-purpose bitmap:      0000000000000007
[    0.315362] ... value mask:                000000ffffffffff
[    0.315364] ... max period:                000000007fffffff
[    0.315365] ... global_ctrl mask:          0000000700000003
[    0.315551] signal: max sigframe size: 1520
[    0.315598] rcu: Hierarchical SRCU implementation.
[    0.315600] rcu: 	Max phase no-delay instances is 1000.
[    0.315667] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
[    0.315667] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
[    0.315667] smp: Bringing up secondary CPUs ...
[    0.315667] smpboot: x86: Booting SMP configuration:
[    0.315667] .... node  #0, CPUs:      #1 #2 #3
[    0.319740] smp: Brought up 1 node, 4 CPUs
[    0.319740] smpboot: Total of 4 processors activated (22663.53 BogoMIPS)
[    0.382916] node 0 deferred pages initialised in 56ms
[    0.382916] Memory: 16345912K/16775624K available (17729K kernel code, 3430K rwdata, 13692K rodata, 4492K init, 4992K bss, 423608K reserved, 0K cma-reserved)
[    0.384541] devtmpfs: initialized
[    0.384541] x86/mm: Memory block size: 128MB
[    0.387723] ACPI: PM: Registering ACPI NVS region [mem 0xefee0000-0xefee1fff] (8192 bytes)
[    0.387785] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.387785] posixtimers hash table entries: 2048 (order: 3, 32768 bytes, linear)
[    0.387785] futex hash table entries: 1024 (65536 bytes on 1 NUMA nodes, total 64 KiB, linear).
[    0.389559] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.390210] DMA: preallocated 2048 KiB GFP_KERNEL pool for atomic allocations
[    0.390690] DMA: preallocated 2048 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.391186] DMA: preallocated 2048 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.391212] audit: initializing netlink subsys (disabled)
[    0.391707] audit: type=2000 audit(1777589109.232:1): state=initialized audit_enabled=0 res=1
[    0.391766] thermal_sys: Registered thermal governor 'fair_share'
[    0.391768] thermal_sys: Registered thermal governor 'bang_bang'
[    0.391770] thermal_sys: Registered thermal governor 'step_wise'
[    0.391772] thermal_sys: Registered thermal governor 'user_space'
[    0.391773] thermal_sys: Registered thermal governor 'power_allocator'
[    0.391790] cpuidle: using governor ladder
[    0.391790] cpuidle: using governor menu
[    0.391790] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.392134] PCI: ECAM [mem 0xf8000000-0xfbffffff] (base 0xf8000000) for domain 0000 [bus 00-3f]
[    0.392141] PCI: ECAM [mem 0xf8000000-0xfbffffff] reserved as E820 entry
[    0.392155] PCI: Using configuration type 1 for base access
[    0.392297] kprobes: kprobe jump-optimization is enabled. All kprobes are optimized if possible.
[    0.393769] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
[    0.393769] HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page
[    0.397827] ACPI: Added _OSI(Module Device)
[    0.397827] ACPI: Added _OSI(Processor Device)
[    0.397827] ACPI: Added _OSI(Processor Aggregator Device)
[    0.401412] ACPI: 2 ACPI AML tables successfully acquired and loaded
[    0.407682] ACPI: \_SB_: platform _OSC: OS support mask [002e7eff]
[    0.407792] ACPI: Dynamic OEM Table Load:
[    0.407800] ACPI: SSDT 0xFFFF8F2A8031A400 00022A (v01 PmRef  Cpu0Ist  00003000 INTL 20040311)
[    0.408055] ACPI: Dynamic OEM Table Load:
[    0.408061] ACPI: SSDT 0xFFFF8F2A8101E400 000152 (v01 PmRef  Cpu1Ist  00003000 INTL 20040311)
[    0.408279] ACPI: Dynamic OEM Table Load:
[    0.408284] ACPI: SSDT 0xFFFF8F2A8101FE00 000152 (v01 PmRef  Cpu2Ist  00003000 INTL 20040311)
[    0.408502] ACPI: Dynamic OEM Table Load:
[    0.408508] ACPI: SSDT 0xFFFF8F2A8101F000 000152 (v01 PmRef  Cpu3Ist  00003000 INTL 20040311)
[    0.408848] ACPI: Interpreter enabled
[    0.408866] ACPI: PM: (supports S0 S3 S4 S5)
[    0.408869] ACPI: Using IOAPIC for interrupt routing
[    0.408900] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.408903] PCI: Using E820 reservations for host bridge windows
[    0.409036] ACPI: Enabled 11 GPEs in block 00 to 3F
[    0.414761] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f])
[    0.414769] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI HPX-Type3]
[    0.414776] acpi PNP0A03:00: _OSC: OS requested [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR]
[    0.414778] acpi PNP0A03:00: _OSC: platform willing to grant [PCIeHotplug SHPCHotplug PME AER PCIeCapability LTR]
[    0.414781] acpi PNP0A03:00: _OSC: platform retains control of PCIe features (AE_ERROR)
[    0.415107] PCI host bridge to bus 0000:00
[    0.415111] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[    0.415114] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[    0.415117] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000dffff window]
[    0.415119] pci_bus 0000:00: root bus resource [mem 0xeff00000-0xfebfffff window]
[    0.415122] pci_bus 0000:00: root bus resource [bus 00-3f]
[    0.415140] pci 0000:00:00.0: [8086:2e20] type 00 class 0x060000 conventional PCI endpoint
[    0.415164] pci 0000:00:00.0: DMAR: Disabling IOMMU for graphics on this chipset
[    0.415166] pci 0000:00:00.0: DMAR: Forcing write-buffer flush capability
[    0.415256] pci 0000:00:1a.0: [8086:3a37] type 00 class 0x0c0300 conventional PCI endpoint
[    0.415293] pci 0000:00:1a.0: BAR 4 [io  0xff00-0xff1f]
[    0.415409] pci 0000:00:1a.1: [8086:3a38] type 00 class 0x0c0300 conventional PCI endpoint
[    0.415446] pci 0000:00:1a.1: BAR 4 [io  0xfe00-0xfe1f]
[    0.415565] pci 0000:00:1a.2: [8086:3a39] type 00 class 0x0c0300 conventional PCI endpoint
[    0.415601] pci 0000:00:1a.2: BAR 4 [io  0xfd00-0xfd1f]
[    0.415732] pci 0000:00:1a.7: [8086:3a3c] type 00 class 0x0c0320 conventional PCI endpoint
[    0.415770] pci 0000:00:1a.7: BAR 0 [mem 0xfdfff000-0xfdfff3ff]
[    0.415904] pci 0000:00:1c.0: [8086:3a40] type 01 class 0x060400 PCIe Root Port
[    0.415924] pci 0000:00:1c.0: PCI bridge to [bus 01]
[    0.415980] pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
[    0.416101] pci 0000:00:1c.3: [8086:3a46] type 01 class 0x060400 PCIe Root Port
[    0.416122] pci 0000:00:1c.3: PCI bridge to [bus 02]
[    0.416126] pci 0000:00:1c.3:   bridge window [io  0xe000-0xefff]
[    0.416130] pci 0000:00:1c.3:   bridge window [mem 0xfdd00000-0xfddfffff]
[    0.416138] pci 0000:00:1c.3:   bridge window [mem 0xfde00000-0xfdefffff 64bit pref]
[    0.416184] pci 0000:00:1c.3: PME# supported from D0 D3hot D3cold
[    0.416305] pci 0000:00:1d.0: [8086:3a34] type 00 class 0x0c0300 conventional PCI endpoint
[    0.416342] pci 0000:00:1d.0: BAR 4 [io  0xfc00-0xfc1f]
[    0.416454] pci 0000:00:1d.1: [8086:3a35] type 00 class 0x0c0300 conventional PCI endpoint
[    0.416491] pci 0000:00:1d.1: BAR 4 [io  0xfb00-0xfb1f]
[    0.416601] pci 0000:00:1d.2: [8086:3a36] type 00 class 0x0c0300 conventional PCI endpoint
[    0.416637] pci 0000:00:1d.2: BAR 4 [io  0xfa00-0xfa1f]
[    0.416751] pci 0000:00:1d.7: [8086:3a3a] type 00 class 0x0c0320 conventional PCI endpoint
[    0.416788] pci 0000:00:1d.7: BAR 0 [mem 0xfdffe000-0xfdffe3ff]
[    0.416908] pci 0000:00:1e.0: [8086:244e] type 01 class 0x060401 conventional PCI bridge
[    0.416928] pci 0000:00:1e.0: PCI bridge to [bus 03] (subtractive decode)
[    0.416934] pci 0000:00:1e.0:   bridge window [mem 0xf0000000-0xf7ffffff]
[    0.417078] pci 0000:00:1f.0: [8086:3a16] type 00 class 0x060100 conventional PCI endpoint
[    0.417136] pci 0000:00:1f.0: quirk: [io  0x0400-0x047f] claimed by ICH6 ACPI/GPIO/TCO
[    0.417141] pci 0000:00:1f.0: quirk: [io  0x0480-0x04bf] claimed by ICH6 GPIO
[    0.417144] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 1 PIO at 0800 (mask 000f)
[    0.417148] pci 0000:00:1f.0: ICH7 LPC Generic IO decode 2 PIO at 0290 (mask 000f)
[    0.417286] pci 0000:00:1f.2: [8086:2822] type 00 class 0x010400 conventional PCI endpoint
[    0.417314] pci 0000:00:1f.2: BAR 0 [io  0xf900-0xf907]
[    0.417317] pci 0000:00:1f.2: BAR 1 [io  0xf800-0xf803]
[    0.417320] pci 0000:00:1f.2: BAR 2 [io  0xf700-0xf707]
[    0.417323] pci 0000:00:1f.2: BAR 3 [io  0xf600-0xf603]
[    0.417325] pci 0000:00:1f.2: BAR 4 [io  0xf500-0xf51f]
[    0.417328] pci 0000:00:1f.2: BAR 5 [mem 0xfdffd000-0xfdffd7ff]
[    0.417359] pci 0000:00:1f.2: PME# supported from D3hot
[    0.417457] pci 0000:00:1f.3: [8086:3a30] type 00 class 0x0c0500 conventional PCI endpoint
[    0.417487] pci 0000:00:1f.3: BAR 0 [mem 0xfdffc000-0xfdffc0ff 64bit]
[    0.417492] pci 0000:00:1f.3: BAR 4 [io  0x0500-0x051f]
[    0.417605] pci 0000:00:1c.0: PCI bridge to [bus 01]
[    0.417675] pci 0000:02:00.0: [10ec:8168] type 00 class 0x020000 PCIe Endpoint
[    0.417726] pci 0000:02:00.0: BAR 0 [io  0xee00-0xeeff]
[    0.417732] pci 0000:02:00.0: BAR 2 [mem 0xfddff000-0xfddfffff 64bit]
[    0.417737] pci 0000:02:00.0: BAR 4 [mem 0xfdefc000-0xfdefffff 64bit pref]
[    0.417828] pci 0000:02:00.0: supports D1 D2
[    0.417830] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.417963] pci 0000:00:1c.3: ASPM: current common clock configuration is inconsistent, reconfiguring
[    0.423688] pci 0000:00:1c.3: PCI bridge to [bus 02]
[    0.423710] pci_bus 0000:03: extended config space not accessible
[    0.423745] pci 0000:03:00.0: [5333:8901] type 00 class 0x030000 conventional PCI endpoint
[    0.423783] pci 0000:03:00.0: BAR 0 [mem 0xf0000000-0xf3ffffff]
[    0.423791] pci 0000:03:00.0: ROM [mem 0x00000000-0x0000ffff pref]
[    0.423806] pci 0000:03:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[    0.423882] pci 0000:00:1e.0: PCI bridge to [bus 03] (subtractive decode)
[    0.423891] pci 0000:00:1e.0:   bridge window [io  0x0000-0x0cf7 window] (subtractive decode)
[    0.423893] pci 0000:00:1e.0:   bridge window [io  0x0d00-0xffff window] (subtractive decode)
[    0.423895] pci 0000:00:1e.0:   bridge window [mem 0x000a0000-0x000dffff window] (subtractive decode)
[    0.423897] pci 0000:00:1e.0:   bridge window [mem 0xeff00000-0xfebfffff window] (subtractive decode)
[    0.424827] ACPI: PCI: Interrupt link LNKA configured for IRQ 12
[    0.424873] ACPI: PCI: Interrupt link LNKB configured for IRQ 0
[    0.424875] ACPI: PCI: Interrupt link LNKB disabled
[    0.424919] ACPI: PCI: Interrupt link LNKC configured for IRQ 7
[    0.424964] ACPI: PCI: Interrupt link LNKD configured for IRQ 11
[    0.425008] ACPI: PCI: Interrupt link LNKE configured for IRQ 10
[    0.425053] ACPI: PCI: Interrupt link LNKF configured for IRQ 3
[    0.425097] ACPI: PCI: Interrupt link LNK0 configured for IRQ 0
[    0.425099] ACPI: PCI: Interrupt link LNK0 disabled
[    0.425143] ACPI: PCI: Interrupt link LNK1 configured for IRQ 5
[    0.425332] iommu: Default domain type: Translated
[    0.425332] iommu: DMA domain TLB invalidation policy: lazy mode
[    0.425332] pps_core: LinuxPPS API ver. 1 registered
[    0.425332] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.425332] PTP clock support registered
[    0.425332] EDAC MC: Ver: 3.0.0
[    0.425332] NetLabel: Initializing
[    0.425332] NetLabel:  domain hash size = 128
[    0.425332] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
[    0.425332] NetLabel:  unlabeled traffic allowed by default
[    0.425332] PCI: Using ACPI for IRQ routing
[    0.425332] PCI: pci_cache_line_size set to 64 bytes
[    0.425332] e820: register RAM buffer resource [mem 0x00093c00-0x0009ffff]
[    0.425332] e820: register RAM buffer resource [mem 0xefee0000-0xefffffff]
[    0.425332] pci 0000:03:00.0: vgaarb: setting as boot VGA device
[    0.425332] pci 0000:03:00.0: vgaarb: bridge control possible
[    0.425332] pci 0000:03:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[    0.427672] vgaarb: loaded
[    0.427718] hpet: 4 channels of 0 reserved for per-cpu timers
[    0.427722] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[    0.427728] hpet0: 4 comparators, 64-bit 14.318180 MHz counter
[    0.429770] clocksource: Switched to clocksource tsc-early
[    0.430578] VFS: Disk quotas dquot_6.6.0
[    0.430622] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.430668] AppArmor: AppArmor Filesystem Enabled
[    0.430668] acpi PNP0C02:00: Skipped [io  0x0010-0x001f]
[    0.430668] acpi PNP0C02:00: Skipped [io  0x0022-0x003f]
[    0.430668] acpi PNP0C02:00: Skipped [io  0x0044-0x005f]
[    0.430668] acpi PNP0C02:00: Skipped [io  0x0062-0x0063]
[    0.430668] acpi PNP0C02:00: Skipped [io  0x0065-0x006f]
[    0.430668] acpi PNP0C02:00: Skipped [io  0x0074-0x007f]
[    0.430668] acpi PNP0C02:00: Skipped [io  0x0091-0x0093]
[    0.430668] acpi PNP0C02:00: Skipped [io  0x00a2-0x00bf]
[    0.430668] acpi PNP0C02:00: Skipped [io  0x00e0-0x00ef]
[    0.430668] acpi PNP0C02:00: Reserved [io  0x04d0-0x04d1]
[    0.430668] acpi PNP0C02:00: Reserved [io  0x0290-0x029f]
[    0.430668] acpi PNP0C02:00: Reserved [io  0x0800-0x087f]
[    0.430668] acpi PNP0C02:00: Reserved [io  0x0290-0x0294]
[    0.430668] acpi PNP0C02:00: Reserved [io  0x0880-0x088f]
[    0.430668] acpi PNP0C02:02: Could not reserve [io  0x0400-0x04cf]
[    0.430668] acpi PNP0C02:02: Reserved [io  0x04d2-0x04ff]
[    0.430668] acpi PNP0C02:03: Reserved [mem 0xf8000000-0xfbffffff]
[    0.430668] acpi PNP0C01:00: Could not reserve [mem 0x000f0000-0x000f3fff]
[    0.430668] acpi PNP0C01:00: Could not reserve [mem 0x000f4000-0x000f7fff]
[    0.430668] acpi PNP0C01:00: Could not reserve [mem 0x000f8000-0x000fbfff]
[    0.430668] acpi PNP0C01:00: Could not reserve [mem 0x000fc000-0x000fffff]
[    0.430668] acpi PNP0C01:00: Could not reserve [mem 0xefee0000-0xefeeffff]
[    0.430668] acpi PNP0C01:00: Could not reserve [mem 0x00000000-0x0009ffff]
[    0.430668] acpi PNP0C01:00: Could not reserve [mem 0x00100000-0xefedffff]
[    0.430668] acpi PNP0C01:00: Reserved [mem 0xefef0000-0xefefffff]
[    0.430668] acpi PNP0C01:00: Could not reserve [mem 0xfec00000-0xfec00fff]
[    0.430668] acpi PNP0C01:00: Reserved [mem 0xfed10000-0xfed1dfff]
[    0.430668] acpi PNP0C01:00: Reserved [mem 0xfed20000-0xfed8ffff]
[    0.430668] acpi PNP0C01:00: Reserved [mem 0xfee00000-0xfee00fff]
[    0.430668] acpi PNP0C01:00: Reserved [mem 0xffb00000-0xffb7ffff]
[    0.430668] acpi PNP0C01:00: Reserved [mem 0xfff00000-0xffffffff]
[    0.430668] acpi PNP0C01:00: Reserved [mem 0x000e0000-0x000effff]
[    0.430668] pnp: PnP ACPI init
[    0.430668] pnp: PnP ACPI: found 1 devices
[    0.438330] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    0.438622] NET: Registered PF_INET protocol family
[    0.439075] IP idents hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    0.457948] tcp_listen_portaddr_hash hash table entries: 8192 (order: 5, 131072 bytes, linear)
[    0.457993] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.458148] TCP established hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.458598] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear)
[    0.458864] TCP: Hash tables configured (established 131072 bind 65536)
[    0.459061] MPTCP token hash table entries: 16384 (order: 7, 393216 bytes, linear)
[    0.459232] UDP hash table entries: 8192 (order: 7, 524288 bytes, linear)
[    0.459404] UDP-Lite hash table entries: 8192 (order: 7, 524288 bytes, linear)
[    0.459567] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.459577] NET: Registered PF_XDP protocol family
[    0.459591] pci 0000:00:1c.0: bridge window [io  0x1000-0x0fff] to [bus 01] add_size 1000
[    0.459596] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 01] add_size 200000 add_align 100000
[    0.459600] pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff] to [bus 01] add_size 200000 add_align 100000
[    0.459614] pci 0000:00:1c.0: bridge window [mem 0xfc000000-0xfc1fffff]: assigned
[    0.459618] pci 0000:00:1c.0: bridge window [mem 0xfc200000-0xfc3fffff 64bit pref]: assigned
[    0.459622] pci 0000:00:1c.0: bridge window [io  0x1000-0x1fff]: assigned
[    0.459625] pci 0000:00:1c.0: PCI bridge to [bus 01]
[    0.459629] pci 0000:00:1c.0:   bridge window [io  0x1000-0x1fff]
[    0.459633] pci 0000:00:1c.0:   bridge window [mem 0xfc000000-0xfc1fffff]
[    0.459637] pci 0000:00:1c.0:   bridge window [mem 0xfc200000-0xfc3fffff 64bit pref]
[    0.459643] pci 0000:00:1c.3: PCI bridge to [bus 02]
[    0.459645] pci 0000:00:1c.3:   bridge window [io  0xe000-0xefff]
[    0.459649] pci 0000:00:1c.3:   bridge window [mem 0xfdd00000-0xfddfffff]
[    0.459653] pci 0000:00:1c.3:   bridge window [mem 0xfde00000-0xfdefffff 64bit pref]
[    0.459659] pci 0000:00:1e.0: PCI bridge to [bus 03]
[    0.459663] pci 0000:00:1e.0:   bridge window [mem 0xf0000000-0xf7ffffff]
[    0.459670] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
[    0.459672] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
[    0.459675] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000dffff window]
[    0.459677] pci_bus 0000:00: resource 7 [mem 0xeff00000-0xfebfffff window]
[    0.459679] pci_bus 0000:01: resource 0 [io  0x1000-0x1fff]
[    0.459681] pci_bus 0000:01: resource 1 [mem 0xfc000000-0xfc1fffff]
[    0.459683] pci_bus 0000:01: resource 2 [mem 0xfc200000-0xfc3fffff 64bit pref]
[    0.459686] pci_bus 0000:02: resource 0 [io  0xe000-0xefff]
[    0.459688] pci_bus 0000:02: resource 1 [mem 0xfdd00000-0xfddfffff]
[    0.459690] pci_bus 0000:02: resource 2 [mem 0xfde00000-0xfdefffff 64bit pref]
[    0.459693] pci_bus 0000:03: resource 1 [mem 0xf0000000-0xf7ffffff]
[    0.459695] pci_bus 0000:03: resource 4 [io  0x0000-0x0cf7 window]
[    0.459697] pci_bus 0000:03: resource 5 [io  0x0d00-0xffff window]
[    0.459699] pci_bus 0000:03: resource 6 [mem 0x000a0000-0x000dffff window]
[    0.459701] pci_bus 0000:03: resource 7 [mem 0xeff00000-0xfebfffff window]
[    0.473247] pci 0000:00:1a.7: quirk_usb_early_handoff+0x0/0x780 took 12806 usecs
[    0.489206] pci 0000:00:1d.7: quirk_usb_early_handoff+0x0/0x780 took 15246 usecs
[    0.489237] PCI: CLS 4 bytes, default 64
[    0.489254] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.489256] software IO TLB: mapped [mem 0x00000000ebee0000-0x00000000efee0000] (64MB)
[    0.489357] Trying to unpack rootfs image as initramfs...
[    0.490026] Initialise system trusted keyrings
[    0.490042] Key type blacklist registered
[    0.490231] workingset: timestamp_bits=36 max_order=22 bucket_order=0
[    0.491638] fuse: init (API version 7.45)
[    0.491968] integrity: Platform Keyring initialized
[    0.491977] integrity: Machine keyring initialized
[    0.516218] Key type asymmetric registered
[    0.516228] Asymmetric key parser 'x509' registered
[    0.516959] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 245)
[    0.517079] io scheduler mq-deadline registered
[    0.525822] ledtrig-cpu: registered to indicate activity on CPUs
[    0.525884] pcieport 0000:00:1c.0: enabling device (0000 -> 0003)
[    0.530297] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    0.531027] Linux agpgart interface v0.103
[    0.534250] i8042: PNP: No PS/2 controller found.
[    0.534252] i8042: Probing ports directly.
[    0.534370] serio: i8042 KBD port at 0x60,0x64 irq 1
[    0.534473] mousedev: PS/2 mouse device common for all mice
[    0.534508] rtc_cmos 00:00: RTC can wake from S4
[    0.534748] rtc_cmos 00:00: registered as rtc0
[    0.534776] rtc_cmos 00:00: setting system clock to 2026-04-30T22:45:10 UTC (1777589110)
[    0.534810] rtc_cmos 00:00: alarms up to one month, 242 bytes nvram, hpet irqs
[    0.537848] intel_pstate: CPU model not supported
[    0.538442] NET: Registered PF_INET6 protocol family
[    0.539147] Segment Routing with IPv6
[    0.539149] RPL Segment Routing with IPv6
[    0.539162] In-situ OAM (IOAM) with IPv6
[    0.539184] mip6: Mobile IPv6
[    0.539188] NET: Registered PF_PACKET protocol family
[    0.539225] mpls_gso: MPLS GSO support
[    0.541288] microcode: Current revision: 0x00000a0e
[    0.549118] IPI shorthand broadcast: enabled
[    0.552183] sched_clock: Marking stable (545583773, 4550930)->(555341732, -5207029)
[    0.552442] registered taskstats version 1
[    0.552718] Loading compiled-in X.509 certificates
[    0.583945] Loaded X.509 cert 'Build time autogenerated kernel key: 77995d5e4d23e9ef52bcdad76505440fbcc5c093'
[    0.587515] Demotion targets for Node 0: null
[    0.587857] Key type .fscrypt registered
[    0.587860] Key type fscrypt-provisioning registered
[    0.657795] Freeing initrd memory: 17460K
[    0.677252] Key type encrypted registered
[    0.677258] AppArmor: AppArmor sha256 policy hashing enabled
[    0.677262] ima: No TPM chip found, activating TPM-bypass!
[    0.677265] ima: Allocated hash algorithm: sha256
[    0.677484] ima: No architecture policies found
[    0.677512] evm: Initialising EVM extended attributes:
[    0.677514] evm: security.selinux
[    0.677516] evm: security.SMACK64 (disabled)
[    0.677517] evm: security.SMACK64EXEC (disabled)
[    0.677518] evm: security.SMACK64TRANSMUTE (disabled)
[    0.677519] evm: security.SMACK64MMAP (disabled)
[    0.677521] evm: security.apparmor
[    0.677522] evm: security.ima
[    0.677523] evm: security.capability
[    0.677524] evm: HMAC attrs: 0x1
[    0.686307] RAS: Correctable Errors collector initialized.
[    0.686563] clk: Disabling unused clocks
[    0.686566] PM: genpd: Disabling unused power domains
[    0.690046] Freeing unused decrypted memory: 2028K
[    0.691388] Freeing unused kernel image (initmem) memory: 4492K
[    0.691490] Write protecting the kernel read-only data: 32768k
[    0.691983] Freeing unused kernel image (text/rodata gap) memory: 700K
[    0.692277] Freeing unused kernel image (rodata/data gap) memory: 644K
[    0.748373] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[    0.748467] x86/mm: Checking user space page tables
[    0.794960] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[    0.794965] Run /init as init process
[    0.794967]   with arguments:
[    0.794969]     /init
[    0.794970]   with environment:
[    0.794971]     HOME=/
[    0.794973]     TERM=linux
[    0.986374] SCSI subsystem initialized
[    1.032423] libata version 3.00 loaded.
[    1.050619] ahci 0000:00:1f.2: controller can't do SNTF, turning off CAP_SNTF
[    1.050726] ahci 0000:00:1f.2: SSS flag set, parallel bus scan disabled
[    1.050756] ahci 0000:00:1f.2: AHCI vers 0001.0200, 32 command slots, 3 Gbps, RAID mode
[    1.050759] ahci 0000:00:1f.2: 6/6 ports implemented (port mask 0x3f)
[    1.050762] ahci 0000:00:1f.2: flags: 64bit ncq stag pm led clo pmp pio slum part ccc ems 
[    1.091737] scsi host0: ahci
[    1.092098] scsi host1: ahci
[    1.092388] scsi host2: ahci
[    1.092586] scsi host3: ahci
[    1.092772] scsi host4: ahci
[    1.092970] scsi host5: ahci
[    1.093040] ata1: SATA max UDMA/133 abar m2048@0xfdffd000 port 0xfdffd100 irq 24 lpm-pol 1 ext
[    1.093043] ata2: SATA max UDMA/133 abar m2048@0xfdffd000 port 0xfdffd180 irq 24 lpm-pol 1 ext
[    1.093046] ata3: SATA max UDMA/133 abar m2048@0xfdffd000 port 0xfdffd200 irq 24 lpm-pol 1 ext
[    1.093048] ata4: SATA max UDMA/133 abar m2048@0xfdffd000 port 0xfdffd280 irq 24 lpm-pol 1 ext
[    1.093050] ata5: SATA max UDMA/133 abar m2048@0xfdffd000 port 0xfdffd300 irq 24 lpm-pol 1 ext
[    1.093052] ata6: SATA max UDMA/133 abar m2048@0xfdffd000 port 0xfdffd380 irq 24 lpm-pol 1 ext
[    1.500568] tsc: Refined TSC clocksource calibration: 2833.010 MHz
[    1.500579] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x28d61000994, max_idle_ns: 440795211167 ns
[    1.500604] clocksource: Switched to clocksource tsc
[    1.564567] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.566329] ata1.00: ATA-8: WDC WD5003ABYX-50WERA1, 01.01S03, max UDMA/133
[    1.566615] ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 32), AA
[    1.567508] ata1.00: configured for UDMA/133
[    1.577735] scsi 0:0:0:0: Direct-Access     ATA      WDC WD5003ABYX-5 1S03 PQ: 0 ANSI: 5
[    2.044567] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    2.045036] ata2.00: ATA-9: HGST HUH721010ALN604, LHGNW92C, max UDMA/133
[    2.056759] ata2.00: 2441609216 sectors, multi 0: LBA48 NCQ (depth 32), AA
[    2.056764] ata2.00: Features: HIPM DIPM NCQ-sndrcv NCQ-prio
[    2.080986] ata2.00: configured for UDMA/133
[    2.100469] scsi 1:0:0:0: Direct-Access     ATA      HGST HUH721010AL W92C PQ: 0 ANSI: 5
[    2.410683] ata3: SATA link down (SStatus 0 SControl 300)
[    2.730729] ata4: SATA link down (SStatus 0 SControl 300)
[    3.050740] ata5: SATA link down (SStatus 0 SControl 300)
[    3.370726] ata6: SATA link down (SStatus 0 SControl 300)
[    3.396498] sd 1:0:0:0: [sdb] 2441609216 4096-byte logical blocks: (10.0 TB/9.10 TiB)
[    3.396515] sd 1:0:0:0: [sdb] Write Protect is off
[    3.396518] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    3.396539] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    3.396693] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[    3.396706] sd 0:0:0:0: [sda] Write Protect is off
[    3.396709] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    3.396758] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    3.396770] sd 1:0:0:0: [sdb] Preferred minimum I/O size 4096 bytes
[    3.396993] sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes
[    3.444038]  sdb: sdb1 sdb2
[    3.444186] sd 1:0:0:0: [sdb] Attached SCSI disk
[    3.446191]  sda: sda1
[    3.446286] sd 0:0:0:0: [sda] Attached SCSI disk
[    3.633273] md: async del_gendisk mode will be removed in future, please upgrade to mdadm-4.5+
[    3.709051] md127: echo current LBS to md/logical_block_size to prevent data loss issues from LBS changes.
               	Note: After setting, array will not be assembled in old kernels (<= 6.18)
[    3.709063] md/raid1:md127: active with 2 out of 2 mirrors
[    3.713047] md127: detected capacity change from 0 to 976506880
[    3.713076] md_update_sb: can't update sb for read-only array md127
[    3.948561] raid6: sse2x4   gen() 10964 MB/s
[    4.016561] raid6: sse2x2   gen() 10573 MB/s
[    4.084561] raid6: sse2x1   gen()  9059 MB/s
[    4.084563] raid6: using algorithm sse2x4 gen() 10964 MB/s
[    4.152560] raid6: .... xor() 5049 MB/s, rmw enabled
[    4.152562] raid6: using ssse3x2 recovery algorithm
[    4.156058] async_tx: api initialized (async)
[    4.159547] xor: measuring software checksum speed
[    4.159774]    prefetch64-sse  : 14616 MB/sec
[    4.160037]    generic_sse     : 12592 MB/sec
[    4.160039] xor: using function: prefetch64-sse (14616 MB/sec)
[    4.517046] EXT4-fs (md127): mounted filesystem 6d057775-1872-424c-857d-a9956029d8b0 ro with ordered data mode. Quota mode: none.
[    4.675474] Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist.
[    5.440523] systemd[1]: Inserted module 'autofs4'
[    5.575868] systemd[1]: systemd 257.9-1~deb13u1 running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF -XKBCOMMON -UTMP +SYSVINIT +LIBARCHIVE)
[    5.575877] systemd[1]: Detected architecture x86-64.
[    5.600395] systemd[1]: Hostname set to <srv>.
[    5.752243] systemd[1]: bpf-restrict-fs: LSM BPF program attached
[    5.811985] random: crng init done
[    6.833383] systemd[1]: Queued start job for default target graphical.target.
[    6.890349] systemd[1]: Created slice system-getty.slice - Slice /system/getty.
[    6.890884] systemd[1]: Created slice system-modprobe.slice - Slice /system/modprobe.
[    6.891376] systemd[1]: Created slice system-nut\x2ddriver.slice - Slice /system/nut-driver.
[    6.891892] systemd[1]: Created slice system-systemd\x2dfsck.slice - Slice /system/systemd-fsck.
[    6.892244] systemd[1]: Created slice user.slice - User and Session Slice.
[    6.892331] systemd[1]: Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch.
[    6.892393] systemd[1]: Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch.
[    6.892633] systemd[1]: Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point.
[    6.892662] systemd[1]: Expecting device dev-disk-by\x2duuid-62d368bf\x2d3189\x2d453a\x2d9474\x2d9ba054bb56c7.device - /dev/disk/by-uuid/62d368bf-3189-453a-9474-9ba054bb56c7...
[    6.892680] systemd[1]: Reached target cryptsetup.target - Local Encrypted Volumes.
[    6.892704] systemd[1]: Reached target integritysetup.target - Local Integrity Protected Volumes.
[    6.892753] systemd[1]: Reached target slices.target - Slice Units.
[    6.892781] systemd[1]: Reached target swap.target - Swaps.
[    6.892811] systemd[1]: Reached target veritysetup.target - Local Verity Protected Volumes.
[    6.892836] systemd[1]: Reached target virt-guest-shutdown.target - libvirt guests shutdown target.
[    6.892931] systemd[1]: Listening on dm-event.socket - Device-mapper event daemon FIFOs.
[    6.893030] systemd[1]: Listening on lvm2-lvmpolld.socket - LVM2 poll daemon socket.
[    6.894221] systemd[1]: Listening on systemd-creds.socket - Credential Encryption/Decryption.
[    6.894312] systemd[1]: Listening on systemd-initctl.socket - initctl Compatibility Named Pipe.
[    6.894447] systemd[1]: Listening on systemd-journald-dev-log.socket - Journal Socket (/dev/log).
[    6.894568] systemd[1]: Listening on systemd-journald.socket - Journal Sockets.
[    6.894605] systemd[1]: systemd-pcrextend.socket - TPM PCR Measurements was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[    6.894629] systemd[1]: systemd-pcrlock.socket - Make TPM PCR Policy was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[    6.894728] systemd[1]: Listening on systemd-udevd-control.socket - udev Control Socket.
[    6.894801] systemd[1]: Listening on systemd-udevd-kernel.socket - udev Kernel Socket.
[    6.906579] systemd[1]: Mounting dev-hugepages.mount - Huge Pages File System...
[    6.907470] systemd[1]: Mounting dev-mqueue.mount - POSIX Message Queue File System...
[    6.908420] systemd[1]: Mounting run-lock.mount - Legacy Locks Directory /run/lock...
[    6.909491] systemd[1]: Mounting sys-kernel-debug.mount - Kernel Debug File System...
[    6.913607] systemd[1]: Mounting sys-kernel-tracing.mount - Kernel Trace File System...
[    6.918381] systemd[1]: Mounting tmp.mount - Temporary Directory /tmp...
[    6.927784] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout...
[    6.928834] systemd[1]: Starting kmod-static-nodes.service - Create List of Static Device Nodes...
[    6.929861] systemd[1]: Starting lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling...
[    6.931116] systemd[1]: Starting modprobe@configfs.service - Load Kernel Module configfs...
[    6.933428] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm...
[    6.936754] systemd[1]: Starting modprobe@efi_pstore.service - Load Kernel Module efi_pstore...
[    6.940923] systemd[1]: Starting modprobe@fuse.service - Load Kernel Module fuse...
[    6.941081] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root).
[    6.942102] systemd[1]: systemd-hibernate-clear.service - Clear Stale Hibernate Storage Info was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67).
[    6.947030] systemd[1]: Starting systemd-journald.service - Journal Service...
[    6.949242] systemd[1]: Starting systemd-modules-load.service - Load Kernel Modules...
[    6.949271] systemd[1]: systemd-pcrmachine.service - TPM PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[    6.956887] systemd[1]: Starting systemd-remount-fs.service - Remount Root and Kernel File Systems...
[    6.956974] systemd[1]: systemd-tpm2-setup-early.service - Early TPM SRK Setup was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[    6.959380] systemd[1]: Starting systemd-udev-load-credentials.service - Load udev Rules from Credentials...
[    6.961967] systemd[1]: Starting systemd-udev-trigger.service - Coldplug All udev Devices...
[    6.964703] systemd[1]: Finished kmod-static-nodes.service - Create List of Static Device Nodes.
[    6.965157] systemd[1]: modprobe@fuse.service: Deactivated successfully.
[    6.965413] systemd[1]: Finished modprobe@fuse.service - Load Kernel Module fuse.
[    6.966623] systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE Control File System...
[    6.967990] systemd[1]: Starting systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully...
[    6.996528] systemd[1]: Mounted dev-hugepages.mount - Huge Pages File System.
[    6.996725] systemd[1]: Mounted dev-mqueue.mount - POSIX Message Queue File System.
[    6.996857] systemd[1]: Mounted run-lock.mount - Legacy Locks Directory /run/lock.
[    6.996985] systemd[1]: Mounted sys-kernel-debug.mount - Kernel Debug File System.
[    6.997112] systemd[1]: Mounted sys-kernel-tracing.mount - Kernel Trace File System.
[    6.997235] systemd[1]: Mounted tmp.mount - Temporary Directory /tmp.
[    6.997369] systemd[1]: Mounted sys-fs-fuse-connections.mount - FUSE Control File System.
[    7.010154] systemd[1]: modprobe@configfs.service: Deactivated successfully.
[    7.010420] systemd[1]: Finished modprobe@configfs.service - Load Kernel Module configfs.
[    7.011552] systemd[1]: Mounting sys-kernel-config.mount - Kernel Configuration File System...
[    7.051432] systemd[1]: Mounted sys-kernel-config.mount - Kernel Configuration File System.
[    7.145464] systemd-journald[321]: Collecting audit messages is disabled.
[    7.183690] systemd[1]: modprobe@efi_pstore.service: Deactivated successfully.
[    7.183970] systemd[1]: Finished modprobe@efi_pstore.service - Load Kernel Module efi_pstore.
[    7.192940] systemd[1]: Finished keyboard-setup.service - Set the console keyboard layout.
[    7.202889] systemd[1]: Started systemd-journald.service - Journal Service.
[    7.276498] EXT4-fs (md127): re-mounted 6d057775-1872-424c-857d-a9956029d8b0 r/w.
[    7.285748] it87: Found IT8718F chip at 0x290, revision 8
[    7.285760] it87: VID is disabled (pins used for GPIO)
[    7.285769] it87: Beeping is supported
[    7.347859] systemd-journald[321]: Received client request to flush runtime journal.
[    7.349964] ACPI: bus type drm_connector registered
[    7.518785] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
[    7.518832] device-mapper: uevent: version 1.0.3
[    7.518921] device-mapper: ioctl: 4.50.0-ioctl (2025-04-28) initialised: dm-devel@lists.linux.dev
[    8.428641] acpi_cpufreq: CPU0: Using I/O space for frequency scaling
[    8.428647] acpi_cpufreq: CPU0: frequency scaling control address: 2176, bit width: 16
[    8.428650] acpi_cpufreq: CPU0 - ACPI performance management activated.
[    8.428651] acpi_cpufreq:      *P0: 2834 MHz, 88000 mW, 160 uS, 54
[    8.428653] acpi_cpufreq:       P1: 2000 MHz, 60000 mW, 160 uS, 310
[    8.428678] cpufreq: CPU0: Fast frequency switching enabled
[    8.428739] acpi_cpufreq: CPU1: Using I/O space for frequency scaling
[    8.428741] acpi_cpufreq: CPU1: frequency scaling control address: 2176, bit width: 16
[    8.428743] acpi_cpufreq: CPU1 - ACPI performance management activated.
[    8.428744] acpi_cpufreq:      *P0: 2834 MHz, 88000 mW, 160 uS, 54
[    8.428746] acpi_cpufreq:       P1: 2000 MHz, 60000 mW, 160 uS, 310
[    8.428765] cpufreq: CPU1: Fast frequency switching enabled
[    8.428817] acpi_cpufreq: CPU2: Using I/O space for frequency scaling
[    8.428819] acpi_cpufreq: CPU2: frequency scaling control address: 2176, bit width: 16
[    8.428821] acpi_cpufreq: CPU2 - ACPI performance management activated.
[    8.428822] acpi_cpufreq:      *P0: 2834 MHz, 88000 mW, 160 uS, 54
[    8.428825] acpi_cpufreq:       P1: 2000 MHz, 60000 mW, 160 uS, 310
[    8.428843] cpufreq: CPU2: Fast frequency switching enabled
[    8.428894] acpi_cpufreq: CPU3: Using I/O space for frequency scaling
[    8.428896] acpi_cpufreq: CPU3: frequency scaling control address: 2176, bit width: 16
[    8.428898] acpi_cpufreq: CPU3 - ACPI performance management activated.
[    8.428900] acpi_cpufreq:      *P0: 2834 MHz, 88000 mW, 160 uS, 54
[    8.428902] acpi_cpufreq:       P1: 2000 MHz, 60000 mW, 160 uS, 310
[    8.428919] cpufreq: CPU3: Fast frequency switching enabled
[    8.436602] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    8.436674] sd 1:0:0:0: Attached scsi generic sg1 type 0
[    8.443662] input: PC Speaker as /devices/platform/pcspkr/input/input1
[    8.536395] input: Power Button as /devices/platform/PNP0C0C:00/input/input2
[    8.536430] ACPI: button: Power Button [PWRB]
[    8.536492] input: Power Button as /devices/platform/LNXPWRBN:00/input/input3
[    8.536539] ACPI: button: Power Button [PWRF]
[    8.552483] i801_smbus 0000:00:1f.3: SMBus using PCI interrupt
[    8.679911] r8169 0000:02:00.0: can't disable ASPM; OS doesn't have ASPM control
[    8.685225] r8169 0000:02:00.0 eth0: RTL8168e/8111e, c0:25:e9:1e:ae:0c, XID 2c2, IRQ 25
[    8.685233] r8169 0000:02:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    8.688289] r8169 0000:02:00.0 enp2s0: renamed from eth0
[    8.837269] ACPI: bus type USB registered
[    8.837332] usbcore: registered new interface driver usbfs
[    8.837345] usbcore: registered new interface driver hub
[    8.837361] usbcore: registered new device driver usb
[    8.898375] Error: Driver 'pcspkr' is already registered, aborting...
[    9.003798] ehci-pci 0000:00:1a.7: EHCI Host Controller
[    9.003811] ehci-pci 0000:00:1a.7: new USB bus registered, assigned bus number 1
[    9.007742] ehci-pci 0000:00:1a.7: irq 18, io mem 0xfdfff000
[    9.016565] ehci-pci 0000:00:1a.7: USB 2.0 started, EHCI 1.00
[    9.016672] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 7.00
[    9.016677] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.016680] usb usb1: Product: EHCI Host Controller
[    9.016682] usb usb1: Manufacturer: Linux 7.0.3 ehci_hcd
[    9.016685] usb usb1: SerialNumber: 0000:00:1a.7
[    9.016881] hub 1-0:1.0: USB hub found
[    9.016897] hub 1-0:1.0: 6 ports detected
[    9.017198] ehci-pci 0000:00:1d.7: EHCI Host Controller
[    9.017208] ehci-pci 0000:00:1d.7: new USB bus registered, assigned bus number 2
[    9.021148] ehci-pci 0000:00:1d.7: irq 23, io mem 0xfdffe000
[    9.036564] ehci-pci 0000:00:1d.7: USB 2.0 started, EHCI 1.00
[    9.036657] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 7.00
[    9.036662] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.036665] usb usb2: Product: EHCI Host Controller
[    9.036668] usb usb2: Manufacturer: Linux 7.0.3 ehci_hcd
[    9.036671] usb usb2: SerialNumber: 0000:00:1d.7
[    9.038850] hub 2-0:1.0: USB hub found
[    9.038865] hub 2-0:1.0: 6 ports detected
[    9.108366] intel_powerclamp: No package C-state available
[    9.136804] uhci_hcd 0000:00:1a.0: UHCI Host Controller
[    9.136817] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3
[    9.136827] uhci_hcd 0000:00:1a.0: detected 2 ports
[    9.136864] uhci_hcd 0000:00:1a.0: irq 16, io port 0x0000ff00
[    9.137160] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 7.00
[    9.137165] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.137169] usb usb3: Product: UHCI Host Controller
[    9.137171] usb usb3: Manufacturer: Linux 7.0.3 uhci_hcd
[    9.137174] usb usb3: SerialNumber: 0000:00:1a.0
[    9.137373] hub 3-0:1.0: USB hub found
[    9.137391] hub 3-0:1.0: 2 ports detected
[    9.137750] uhci_hcd 0000:00:1a.1: UHCI Host Controller
[    9.137759] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4
[    9.137766] uhci_hcd 0000:00:1a.1: detected 2 ports
[    9.137793] uhci_hcd 0000:00:1a.1: irq 21, io port 0x0000fe00
[    9.137943] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 7.00
[    9.137949] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.137952] usb usb4: Product: UHCI Host Controller
[    9.137955] usb usb4: Manufacturer: Linux 7.0.3 uhci_hcd
[    9.137958] usb usb4: SerialNumber: 0000:00:1a.1
[    9.138125] hub 4-0:1.0: USB hub found
[    9.138147] hub 4-0:1.0: 2 ports detected
[    9.138456] uhci_hcd 0000:00:1a.2: UHCI Host Controller
[    9.138465] uhci_hcd 0000:00:1a.2: new USB bus registered, assigned bus number 5
[    9.138473] uhci_hcd 0000:00:1a.2: detected 2 ports
[    9.138492] uhci_hcd 0000:00:1a.2: irq 18, io port 0x0000fd00
[    9.138625] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 7.00
[    9.138631] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.138634] usb usb5: Product: UHCI Host Controller
[    9.138637] usb usb5: Manufacturer: Linux 7.0.3 uhci_hcd
[    9.138639] usb usb5: SerialNumber: 0000:00:1a.2
[    9.138803] hub 5-0:1.0: USB hub found
[    9.138821] hub 5-0:1.0: 2 ports detected
[    9.139118] uhci_hcd 0000:00:1d.0: UHCI Host Controller
[    9.139127] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6
[    9.139134] uhci_hcd 0000:00:1d.0: detected 2 ports
[    9.139153] uhci_hcd 0000:00:1d.0: irq 23, io port 0x0000fc00
[    9.139291] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 7.00
[    9.139297] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.139300] usb usb6: Product: UHCI Host Controller
[    9.139303] usb usb6: Manufacturer: Linux 7.0.3 uhci_hcd
[    9.139305] usb usb6: SerialNumber: 0000:00:1d.0
[    9.139472] hub 6-0:1.0: USB hub found
[    9.139490] hub 6-0:1.0: 2 ports detected
[    9.139782] uhci_hcd 0000:00:1d.1: UHCI Host Controller
[    9.139790] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7
[    9.139798] uhci_hcd 0000:00:1d.1: detected 2 ports
[    9.139824] uhci_hcd 0000:00:1d.1: irq 19, io port 0x0000fb00
[    9.139964] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 7.00
[    9.139970] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.139973] usb usb7: Product: UHCI Host Controller
[    9.139976] usb usb7: Manufacturer: Linux 7.0.3 uhci_hcd
[    9.139978] usb usb7: SerialNumber: 0000:00:1d.1
[    9.140150] hub 7-0:1.0: USB hub found
[    9.140168] hub 7-0:1.0: 2 ports detected
[    9.140461] uhci_hcd 0000:00:1d.2: UHCI Host Controller
[    9.140470] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
[    9.140478] uhci_hcd 0000:00:1d.2: detected 2 ports
[    9.140496] uhci_hcd 0000:00:1d.2: irq 18, io port 0x0000fa00
[    9.140643] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 7.00
[    9.140648] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    9.140651] usb usb8: Product: UHCI Host Controller
[    9.140654] usb usb8: Manufacturer: Linux 7.0.3 uhci_hcd
[    9.140657] usb usb8: SerialNumber: 0000:00:1d.2
[    9.140818] hub 8-0:1.0: USB hub found
[    9.140836] hub 8-0:1.0: 2 ports detected
[    9.264573] usb 1-6: new high-speed USB device number 2 using ehci-pci
[    9.411165] usb 1-6: New USB device found, idVendor=19d2, idProduct=0016, bcdDevice= 0.00
[    9.411173] usb 1-6: New USB device strings: Mfr=3, Product=2, SerialNumber=0
[    9.411177] usb 1-6: Product: MTS WCDMA Technologies MSM
[    9.411180] usb 1-6: Manufacturer: Mobile Telesystems OJSC
[    9.516643] usb 8-2: new full-speed USB device number 2 using uhci_hcd
[    9.565244] usbcore: registered new interface driver usbserial_generic
[    9.565260] usbserial: USB Serial support registered for generic
[    9.699542] usb 8-2: New USB device found, idVendor=1a86, idProduct=7523, bcdDevice=81.34
[    9.699551] usb 8-2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[    9.699554] usb 8-2: Product: USB Serial
[    9.719425] usbcore: registered new interface driver option
[    9.719443] usbserial: USB Serial support registered for GSM modem (1-port)
[    9.719518] option 1-6:1.0: GSM modem (1-port) converter detected
[    9.719656] usb 1-6: GSM modem (1-port) converter now attached to ttyUSB0
[    9.719698] option 1-6:1.1: GSM modem (1-port) converter detected
[    9.719771] usb 1-6: GSM modem (1-port) converter now attached to ttyUSB1
[    9.719807] option 1-6:1.2: GSM modem (1-port) converter detected
[    9.719911] usb 1-6: GSM modem (1-port) converter now attached to ttyUSB2
[    9.757462] usbcore: registered new interface driver ch341
[    9.757482] usbserial: USB Serial support registered for ch341-uart
[    9.757502] ch341 8-2:1.0: ch341-uart converter detected
[    9.764608] usb 8-2: ch341-uart converter now attached to ttyUSB3
[   10.322701] EXT4-fs (sdb1): mounted filesystem 62d368bf-3189-453a-9474-9ba054bb56c7 r/w with ordered data mode. Quota mode: none.
[   10.696269] audit: type=1400 audit(1777589120.653:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="Discord" pid=585 comm="apparmor_parser"
[   10.696279] audit: type=1400 audit(1777589120.653:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="QtWebEngineProcess" pid=587 comm="apparmor_parser"
[   10.696281] audit: type=1400 audit(1777589120.653:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name=4D6F6E676F444220436F6D70617373 pid=586 comm="apparmor_parser"
[   10.696284] audit: type=1400 audit(1777589120.653:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="1password" pid=584 comm="apparmor_parser"
[   10.715880] audit: type=1400 audit(1777589120.673:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="balena-etcher" pid=589 comm="apparmor_parser"
[   10.715920] audit: type=1400 audit(1777589120.673:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="brave" pid=590 comm="apparmor_parser"
[   10.715951] audit: type=1400 audit(1777589120.673:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="buildah" pid=591 comm="apparmor_parser"
[   10.717817] audit: type=1400 audit(1777589120.677:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="busybox" pid=592 comm="apparmor_parser"
[   10.732668] audit: type=1400 audit(1777589120.693:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="cam" pid=593 comm="apparmor_parser"
[   10.732739] audit: type=1400 audit(1777589120.693:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="ch-run" pid=595 comm="apparmor_parser"
[   11.724799] Process accounting resumed
[   12.360157] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.
[   12.368274] br0: port 1(enp2s0) entered blocking state
[   12.368282] br0: port 1(enp2s0) entered disabled state
[   12.368295] r8169 0000:02:00.0 enp2s0: entered allmulticast mode
[   12.368352] r8169 0000:02:00.0 enp2s0: entered promiscuous mode
[   12.461020] RTL8211DN Gigabit Ethernet r8169-0-200:00: attached PHY driver (mii_bus:phy_addr=r8169-0-200:00, irq=MAC)
[   12.743385] r8169 0000:02:00.0 enp2s0: Link is Down
[   12.744304] br0: port 1(enp2s0) entered blocking state
[   12.744309] br0: port 1(enp2s0) entered forwarding state
[   13.372610] br0: port 1(enp2s0) entered disabled state
[   15.042143] r8169 0000:02:00.0 enp2s0: Link is Up - 1Gbps/Full - flow control rx/tx
[   15.042198] br0: port 1(enp2s0) entered blocking state
[   15.042204] br0: port 1(enp2s0) entered forwarding state
[   20.262459] r8169 0000:02:00.0 enp2s0: Link is Down
[   20.262562] br0: port 1(enp2s0) entered disabled state
[   23.091701] r8169 0000:02:00.0 enp2s0: Link is Up - 1Gbps/Full - flow control off
[   23.091734] br0: port 1(enp2s0) entered blocking state
[   23.091739] br0: port 1(enp2s0) entered forwarding state

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Evgeny Sagatov]

Rafael,

I'm leaving on vacation today. I'll be able to conduct new checks
starting May 17th.

Thanks for helping with resolving the issue!

чт, 30 апр. 2026 г. в 17:42, Rafael J. Wysocki <rafael@kernel.org>:
>
> On Thursday, April 30, 2026 3:57:41 PM CEST Rafael J. Wysocki wrote:
> > On Thu, Apr 30, 2026 at 1:41 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
> > >
> > > I noticed that for powersave mode, I'm getting the following values:
> >
> > I guess you mean with the powersave governor.
> >
> > > cat /proc/cpuinfo | grep MHz
> > > cpu MHz         : 2798.689
> > > cpu MHz         : 1999.659
> > > cpu MHz         : 1999.797
> > > cpu MHz         : 2741.103
> > > Also, there's now no difference in the single-core benchmark between
> > > schedutil, ondemand, powersave and performance modes. The benchmark
> > > always gives a very high result.
> > > This wasn't the case before; the modes had different performance levels.
> >
> > I would expect schedutil, ondemand and performance to give similar
> > scores, but for powersave I would expect the score to be lower.
> >
> > With the same patch applied, can you please switch over to powersave,
> > reset the stats and then capture the output of
> >
> > grep -r . /sys/devices/system/cpu/cpufreq/
> >
> > Also, I'd still like to see the output of
> >
> > grep . /sys/firmware/acpi/interrupts/sci*
>
> Additionally, please remove all of the debug patches sent so far, apply
> the one below and send a dmesg boot log.
>
> I want to check if all of the CPUs use the same control values when
> they write to the frequency scaling control register.
>
> ---
>  drivers/cpufreq/acpi-cpufreq.c |   12 +++++++++---
>  drivers/cpufreq/cpufreq.c      |    1 +
>  2 files changed, 10 insertions(+), 3 deletions(-)
>
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -887,9 +887,14 @@ static int acpi_cpufreq_cpu_init(struct
>                  * unknown and not detectable via IO ports.
>                  */
>                 policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
> +               pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
> +               pr_info("CPU%u: frequency scaling control address: %llu, bit width: %u\n",
> +                       cpu, perf->control_register.address,
> +                       perf->control_register.bit_width);
>                 break;
>         case ACPI_ADR_SPACE_FIXED_HARDWARE:
>                 acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> +               pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
>                 break;
>         default:
>                 break;
> @@ -898,13 +903,14 @@ static int acpi_cpufreq_cpu_init(struct
>         /* notify BIOS that we exist */
>         acpi_processor_notify_smm(THIS_MODULE);
>
> -       pr_debug("CPU%u - ACPI performance management activated.\n", cpu);
> +       pr_info("CPU%u - ACPI performance management activated.\n", cpu);
>         for (i = 0; i < perf->state_count; i++)
> -               pr_debug("     %cP%d: %d MHz, %d mW, %d uS\n",
> +               pr_info("     %cP%d: %d MHz, %d mW, %d uS, %u\n",
>                         (i == perf->state ? '*' : ' '), i,
>                         (u32) perf->states[i].core_frequency,
>                         (u32) perf->states[i].power,
> -                       (u32) perf->states[i].transition_latency);
> +                       (u32) perf->states[i].transition_latency,
> +                       (u32) perf->states[i].control);
>
>         /*
>          * the first call to ->target() should result in us actually
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
>         if (cpufreq_fast_switch_count >= 0) {
>                 cpufreq_fast_switch_count++;
>                 policy->fast_switch_enabled = true;
> +               pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
>         } else {
>                 pr_warn("CPU%u: Fast frequency switching not enabled\n",
>                         policy->cpu);
>
>
>
>

Re: Pressing the power button causes the device to freeze completely (schedutil involved)

[Rafael J. Wysocki]

On Fri, May 1, 2026 at 1:18 AM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
>
> Rafael,
>
> I'm leaving on vacation today. I'll be able to conduct new checks
> starting May 17th.

Sure, thanks for the notice!

> Thanks for helping with resolving the issue!

No problem.

> чт, 30 апр. 2026 г. в 17:42, Rafael J. Wysocki <rafael@kernel.org>:
> >
> > On Thursday, April 30, 2026 3:57:41 PM CEST Rafael J. Wysocki wrote:
> > > On Thu, Apr 30, 2026 at 1:41 PM Evgeny Sagatov <evgeny.sagatov@gmail.com> wrote:
> > > >
> > > > I noticed that for powersave mode, I'm getting the following values:
> > >
> > > I guess you mean with the powersave governor.
> > >
> > > > cat /proc/cpuinfo | grep MHz
> > > > cpu MHz         : 2798.689
> > > > cpu MHz         : 1999.659
> > > > cpu MHz         : 1999.797
> > > > cpu MHz         : 2741.103
> > > > Also, there's now no difference in the single-core benchmark between
> > > > schedutil, ondemand, powersave and performance modes. The benchmark
> > > > always gives a very high result.
> > > > This wasn't the case before; the modes had different performance levels.
> > >
> > > I would expect schedutil, ondemand and performance to give similar
> > > scores, but for powersave I would expect the score to be lower.
> > >
> > > With the same patch applied, can you please switch over to powersave,
> > > reset the stats and then capture the output of
> > >
> > > grep -r . /sys/devices/system/cpu/cpufreq/
> > >
> > > Also, I'd still like to see the output of
> > >
> > > grep . /sys/firmware/acpi/interrupts/sci*
> >
> > Additionally, please remove all of the debug patches sent so far, apply
> > the one below and send a dmesg boot log.
> >
> > I want to check if all of the CPUs use the same control values when
> > they write to the frequency scaling control register.
> >
> > ---
> >  drivers/cpufreq/acpi-cpufreq.c |   12 +++++++++---
> >  drivers/cpufreq/cpufreq.c      |    1 +
> >  2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > --- a/drivers/cpufreq/acpi-cpufreq.c
> > +++ b/drivers/cpufreq/acpi-cpufreq.c
> > @@ -887,9 +887,14 @@ static int acpi_cpufreq_cpu_init(struct
> >                  * unknown and not detectable via IO ports.
> >                  */
> >                 policy->cur = acpi_cpufreq_guess_freq(data, policy->cpu);
> > +               pr_info("CPU%u: Using I/O space for frequency scaling\n", cpu);
> > +               pr_info("CPU%u: frequency scaling control address: %llu, bit width: %u\n",
> > +                       cpu, perf->control_register.address,
> > +                       perf->control_register.bit_width);
> >                 break;
> >         case ACPI_ADR_SPACE_FIXED_HARDWARE:
> >                 acpi_cpufreq_driver.get = get_cur_freq_on_cpu;
> > +               pr_info("CPU%u: Using FFH for frequency scaling\n", cpu);
> >                 break;
> >         default:
> >                 break;
> > @@ -898,13 +903,14 @@ static int acpi_cpufreq_cpu_init(struct
> >         /* notify BIOS that we exist */
> >         acpi_processor_notify_smm(THIS_MODULE);
> >
> > -       pr_debug("CPU%u - ACPI performance management activated.\n", cpu);
> > +       pr_info("CPU%u - ACPI performance management activated.\n", cpu);
> >         for (i = 0; i < perf->state_count; i++)
> > -               pr_debug("     %cP%d: %d MHz, %d mW, %d uS\n",
> > +               pr_info("     %cP%d: %d MHz, %d mW, %d uS, %u\n",
> >                         (i == perf->state ? '*' : ' '), i,
> >                         (u32) perf->states[i].core_frequency,
> >                         (u32) perf->states[i].power,
> > -                       (u32) perf->states[i].transition_latency);
> > +                       (u32) perf->states[i].transition_latency,
> > +                       (u32) perf->states[i].control);
> >
> >         /*
> >          * the first call to ->target() should result in us actually
> > --- a/drivers/cpufreq/cpufreq.c
> > +++ b/drivers/cpufreq/cpufreq.c
> > @@ -473,6 +473,7 @@ void cpufreq_enable_fast_switch(struct c
> >         if (cpufreq_fast_switch_count >= 0) {
> >                 cpufreq_fast_switch_count++;
> >                 policy->fast_switch_enabled = true;
> > +               pr_info("CPU%u: Fast frequency switching enabled\n", policy->cpu);
> >         } else {
> >                 pr_warn("CPU%u: Fast frequency switching not enabled\n",
> >                         policy->cpu);
> >
> >
> >
> >