Pressing the power button causes the device to freeze completely

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.

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>.

Unfortunately, my skills are not enough to understand the reason for the freeze.

I'm attaching dmesg and lspci logs.

Quoted 1 line

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.

Quoted 1 line

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.

----------------
Кому: Evgeny Sagatov ([email protected]), Rafael J. Wysocki ([email protected]);
Копия: [email protected], LKML ([email protected]), Michal Wilczynski ([email protected]);
Тема: Pressing the power button causes the device to freeze completely; 16.04.2026, 11:23, "Thorsten Leemhuis" <[email protected]>:

[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

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 <[email protected]>
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:[email protected]):
To: Evgeny Sagatov (mailto:[email protected]), Rafael J. Wysocki (mailto:[email protected]);
Copy: mailto:[email protected], LKML (mailto:[email protected]), Michal Wilczynski (mailto:[email protected]);
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:[email protected]), Rafael J. Wysocki (mailto:[email protected]);
 Copy: mailto:[email protected], LKML (mailto:[email protected]), Michal Wilczynski (mailto:[email protected]);
 Topic: Pressing the power button causes the device to freeze completely; 16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:[email protected]>:

     [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

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 <[email protected]>
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:[email protected]):
To: Evgeny Sagatov (mailto:[email protected]), Rafael J. Wysocki (mailto:[email protected]);
Copy: mailto:[email protected], LKML (mailto:[email protected]), Michal Wilczynski (mailto:[email protected]);
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:[email protected]), Rafael J. Wysocki (mailto:[email protected]);
 Copy: mailto:[email protected], LKML (mailto:[email protected]),
 Michal Wilczynski (mailto:[email protected]);
 Topic: Pressing the power button causes the device to freeze completely;
 16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:[email protected]>:

     [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

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 <[email protected]>
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:[email protected]):
To: Evgeny Sagatov (mailto:[email protected]), Rafael J. Wysocki (mailto:[email protected]);
Copy: mailto:[email protected], LKML (mailto:[email protected]), Michal Wilczynski (mailto:[email protected]);
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:[email protected]), Rafael J. Wysocki (mailto:[email protected]);
 Copy: mailto:[email protected], LKML (mailto:[email protected]),
 Michal Wilczynski (mailto:[email protected]);
 Topic: Pressing the power button causes the device to freeze completely;
 16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:[email protected]>:

     [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

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' <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>; [email protected]; LKML <[email protected]>; Michal Wilczynski <[email protected]>
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.

-----Original Message-----
From: Thorsten Leemhuis <[email protected]>
Sent: Monday, April 20, 2026 9:55 AM
To: Sagatov, Evgeniy <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>; [email protected]; LKML <[email protected]>; Michal Wilczynski <[email protected]>
Subject: Re: Pressing the power button causes the device to freeze completely

Quoted 13 lines · 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 <[email protected]>
Date: Thu Jan 18 11:57:33 2024 -0800

Quoted 2 lines

    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

Quoted 159 lines

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:[email protected]):
To: Evgeny Sagatov (mailto:[email protected]), Rafael J. Wysocki (mailto:[email protected]);
Copy: mailto:[email protected], LKML (mailto:[email protected]), Michal Wilczynski (mailto:[email protected]);
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:[email protected]), Rafael J. Wysocki (mailto:[email protected]);
 Copy: mailto:[email protected], LKML (mailto:[email protected]),
 Michal Wilczynski (mailto:[email protected]);
 Topic: Pressing the power button causes the device to freeze completely;
 16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:[email protected]>:

     [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

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' <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>; [email protected]; LKML <[email protected]>; Michal Wilczynski <[email protected]>
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.

-----Original Message-----
From: Thorsten Leemhuis <[email protected]>
Sent: Monday, April 20, 2026 9:55 AM
To: Sagatov, Evgeniy <[email protected]>
Cc: Rafael J. Wysocki <[email protected]>; [email protected]; LKML <[email protected]>; Michal Wilczynski <[email protected]>
Subject: Re: Pressing the power button causes the device to freeze completely

Quoted 13 lines · 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 <[email protected]>
Date: Thu Jan 18 11:57:33 2024 -0800

Quoted 2 lines

    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

Quoted 162 lines

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:[email protected]):
To: Evgeny Sagatov (mailto:[email protected]), Rafael J. Wysocki (mailto:[email protected]);
Copy: mailto:[email protected], LKML (mailto:[email protected]), Michal Wilczynski (mailto:[email protected]);
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:[email protected]), Rafael J. Wysocki (mailto:[email protected]);
 Copy: mailto:[email protected], LKML (mailto:[email protected]),
 Michal Wilczynski (mailto:[email protected]);
 Topic: Pressing the power button causes the device to freeze completely;
 16.04.2026, 11:23, "Thorsten Leemhuis" <mailto:[email protected]>:

     [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

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.

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.

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>.

Hi,

Quoted 5 lines · Evgeny Sagatov

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

Quoted 8 lines

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.

Quoted 7 lines

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!

Quoted 6 lines

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.

8c94ccc7cd691472461448f98e2372c75849406c    good
e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27    good
b0d326da462e20285236e11e4cbc32085de9f363    bad

Hi,

Quoted 5 lines · Evgeny Sagatov

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

Quoted 8 lines

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.

Quoted 7 lines

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!

Quoted 6 lines

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(-)

drivers/acpi/button.c +1 -4

@@ -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,
 
 
 
 
 
-------- Конец пересылаемого сообщения --------

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?

Quoted 3 lines

8c94ccc7cd691472461448f98e2372c75849406c    good
e37617c8e53a1f7fcba6d5e1041f4fd8a2425c27    good
b0d326da462e20285236e11e4cbc32085de9f363    bad

Quoted 81 lines · Rafael J

Hi,

Quoted 5 lines · Evgeny Sagatov

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

Quoted 8 lines

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.

Quoted 7 lines

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!

Quoted 6 lines

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(-)

drivers/acpi/button.c +1 -4

@@ -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,
 
 
 
 
 
-------- Конец пересылаемого сообщения --------

Hi,

Quoted 5 lines · 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.

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

Quoted 6 lines

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

Quoted 3 lines

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?

Quoted 75 lines

Quoted 75 lines · Rafael J

Hi,

Quoted 5 lines · Evgeny Sagatov

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

Quoted 8 lines

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.

Quoted 7 lines

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!

Quoted 6 lines

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(-)

drivers/acpi/button.c +1 -3

@@ -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,

# 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

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

Quoted 6 lines

# 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).

Quoted 5 lines

/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).

Quoted 2 lines

/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).

Quoted 9 lines

/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

Quoted 9 lines

/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.

Quoted 1 line

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 <[email protected]>:

Quoted 54 lines · Evgeny Sagatov

Quoted 6 lines

# 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).

Quoted 5 lines

/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).

Quoted 2 lines

/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).

Quoted 9 lines

/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

Quoted 9 lines

/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.

Quoted 7 lines

Quoted 1 line

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.

Quoted 55 lines

ср, 22 апр. 2026 г. в 17:04, Rafael J. Wysocki <[email protected]>:

Quoted 54 lines · Evgeny Sagatov

Quoted 6 lines

# 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).

Quoted 5 lines

/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).

Quoted 2 lines

/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).

Quoted 9 lines

/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

Quoted 9 lines

/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(-)

drivers/acpi/button.c +4 -6

@@ -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;
 }
 

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

Quoted 6 lines

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(-)

kernel/sched/cpufreq_schedutil.c +1 -1

@@ -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;
 
        /*

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

Quoted 2 lines

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(+)

drivers/acpi/acpica/evevent.c +5 -0

@@ -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.

drivers/cpufreq/cpufreq.c +1 -0

@@ -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);

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.

Quoted 5 lines

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.

Quoted 1 line

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(-)

drivers/acpi/acpica/evevent.c +5 -0

@@ -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.

drivers/cpufreq/acpi-cpufreq.c +1 -2

@@ -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");

drivers/cpufreq/cpufreq.c +1 -0

@@ -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);

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

Quoted 6 lines · CEST 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?

Yes, it is.

Quoted 6 lines

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(-)

drivers/acpi/acpica/evevent.c +5 -0

@@ -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.

drivers/cpufreq/acpi-cpufreq.c +4 -2

@@ -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;

drivers/cpufreq/cpufreq.c +1 -0

@@ -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);

Quoted 20 lines · CEST Evgeny Sagatov

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 7 lines

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.

Quoted 72 lines

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(-)

drivers/acpi/acpica/evevent.c +5 -0

@@ -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.

drivers/cpufreq/acpi-cpufreq.c +4 -2

@@ -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;

drivers/cpufreq/cpufreq.c +1 -0

@@ -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);

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.

Quoted 10 lines

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

Quoted 4 lines

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.

Quoted 1 line

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(-)

drivers/acpi/acpica/evevent.c +12 -0

@@ -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.

drivers/cpufreq/acpi-cpufreq.c +6 -2

@@ -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;

drivers/cpufreq/cpufreq.c +1 -0

@@ -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);

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

Quoted 10 lines

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

Quoted 3 lines

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(-)

drivers/acpi/acpica/evevent.c +8 -0

@@ -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.

drivers/cpufreq/acpi-cpufreq.c +6 -2

@@ -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;

drivers/cpufreq/cpufreq.c +1 -0

@@ -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);

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 <[email protected]>:

Quoted 11 lines · CEST Evgeny Sagatov

Quoted 9 lines

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

Quoted 15 lines

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 <[email protected]>:

Quoted 11 lines · CEST Evgeny Sagatov

Quoted 9 lines

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(-)

drivers/acpi/osl.c +7 -2

@@ -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);

drivers/cpufreq/acpi-cpufreq.c +6 -3

@@ -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");
 

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

Quoted 1 line

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(-)

drivers/acpi/osl.c +6 -0

@@ -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) {

drivers/cpufreq/acpi-cpufreq.c +3 -1

@@ -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");

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

Quoted 2 lines · Evgeny Sagatov

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.

Quoted 66 lines

Quoted 2 lines · Evgeny Sagatov

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

Quoted 8 lines

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(-)

drivers/cpufreq/acpi-cpufreq.c +6 -4

@@ -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");

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

Quoted 2 lines · Evgeny Sagatov

The PC froze when I pressed the power button.

Well, we need to dig more I guess.

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 9 lines

/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

Quoted 10 lines

/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.

Quoted 44 lines

Quoted 2 lines · Evgeny Sagatov

The PC froze when I pressed the power button.

Well, we need to dig more I guess.

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 9 lines

/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

Quoted 10 lines

/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

Quoted 5 lines

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.

Quoted 1 line

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.

Quoted 11 lines

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.

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 <[email protected]>:

Quoted 78 lines · Rafael J. Wysocki

Quoted 44 lines

Quoted 2 lines · Evgeny Sagatov

The PC froze when I pressed the power button.

Well, we need to dig more I guess.

Quoted 4 lines

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

Quoted 8 lines

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.

Quoted 9 lines

/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

Quoted 10 lines

/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

Quoted 5 lines

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.

Quoted 1 line

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.

Quoted 11 lines

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.

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

I guess you mean with the powersave governor.

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

Quoted 3 lines

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.

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.

Quoted 2 lines · Evgeny Sagatov

I noticed that for powersave mode, I'm getting the following values:

I guess you mean with the powersave governor.

Quoted 9 lines

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*

Quoted 19 lines · Evgeny Sagatov

Quoted 2 lines

I noticed that for powersave mode, I'm getting the following values:

I guess you mean with the powersave governor.

Quoted 9 lines

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.

Quoted 8 lines

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(-)

drivers/cpufreq/acpi-cpufreq.c +9 -3

@@ -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

Quoted 19 lines · Evgeny Sagatov

Quoted 2 lines

I noticed that for powersave mode, I'm getting the following values:

I guess you mean with the powersave governor.

Quoted 9 lines

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.

Quoted 8 lines

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(-)

drivers/cpufreq/acpi-cpufreq.c +9 -3

@@ -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

drivers/cpufreq/cpufreq.c +1 -0

@@ -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);

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 <[email protected]>:

Quoted 90 lines · CEST Rafael J. Wysocki

Quoted 19 lines · Evgeny Sagatov

Quoted 2 lines

I noticed that for powersave mode, I'm getting the following values:

I guess you mean with the powersave governor.

Quoted 9 lines

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.

Quoted 8 lines

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(-)

drivers/cpufreq/acpi-cpufreq.c +9 -3

@@ -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

drivers/cpufreq/cpufreq.c +1 -0

@@ -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);