From: bugzilla-daemon@kernel.org
To: platform-driver-x86@vger.kernel.org
Subject: [Bug 218696] New: DYTC frequency scaling deterioration
Date: Mon, 08 Apr 2024 19:32:01 +0000 [thread overview]
Message-ID: <bug-218696-215701@https.bugzilla.kernel.org/> (raw)
https://bugzilla.kernel.org/show_bug.cgi?id=218696
Bug ID: 218696
Summary: DYTC frequency scaling deterioration
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Platform_x86
Assignee: drivers_platform_x86@kernel-bugs.osdl.org
Reporter: lmulling@proton.me
Regression: No
Created attachment 306108
--> https://bugzilla.kernel.org/attachment.cgi?id=306108&action=edit
ACPI Feilds dump before during and after the problem
Hi,
I'm trying to implement automatic user-space platform profile controls for my
ThinkPad and noticed that while under load, i.e. compiling the kernel, the
firmware (I think) will start sending `ibm/hotkey LEN0268:00 00000080 00006032`
events non-stop, which causes thinkpad_acpi to update the platform profile.
This happens once every second. However, the profile doe's not change. This
render any userspace tool useless, since we cannot react according to Fn +
[L|M|H] events.
While this is happening, the max frequency scaling will get stuck at a maximum
of around 2990MHz (78 C). The baseline for this model, from my measurements, is
3.400MHz (95 C). This seems to happen only if the GPU is used and DYTC is in
MMC mode.
I can reproduce this reliably by playing a full-screen YouTube video while
compiling the kernel.
Changing platform profile to low-power and then back to performance fixes this
for a while. I've also noticed that leaving the deceive sleeping for long
periods of time fixes this.
I've tried looking at the DYTC implementation but didn't find anything special
about going into low-power, I've tried to dump the the ACPI fields using
acpi_dbg, but haven't found anything useful yet.
I've attached the dumps (in the same file), which are:
- before, taken after reboot.
- during, taken while the firmware is sending 6032 events and frequency scaling
is stuck;
- after, taken after changing the platform profile to low-power and back to
performance (this was done using Fn + L then Fn + H)
Bellow, also, is the diff between during and after. But it does not show
anything useful to me.
```
--- during 2024-04-08 15:17:49.998768985 -0300
+++ after 2024-04-08 15:20:56.829128627 -0300
@@ -151,7 +151,7 @@
\_SB.PCI0.SMB.LRG3 {00000000000000FF}
\_SB.PCI0.SMB.LHC3 {00000000000000FF}
\_SB.PCI0.SMB.SEC {0000000000000031}
-\_SB.PCI0.SMB.MIN {0000000000000017}
+\_SB.PCI0.SMB.MIN {0000000000000020}
\_SB.PCI0.SMB.MX01 {00000000000000FF}
\_SB.PCI0.SMB.MX07 {00000000000000FF}
\_SB.PCI0.SMB.MX14 {00000000000000FF}
@@ -191,7 +191,7 @@
\_SB.PCI0.SMB.MS04 {00000000000000F0}
\_SB.PCI0.SMB.MS40 {0000000000000042}
\_SB.PCI0.SMB.ECES {0000000000000000}
-\_SB.PCI0.LPC0.EC0.SBVO {000000000000317B}
+\_SB.PCI0.LPC0.EC0.SBVO {000000000000317A}
\_SB.PCI0.LPC0.EC0.SBAC {0000000000000000}
\_SB.PCI0.LPC0.EC0.SBRS {0000000000000064}
\_SB.PCI0.LPC0.EC0.SBRC {000000000000110A}
@@ -210,7 +210,7 @@
\_SB.PCI0.LPC0.EC0.SBCH {000000000050694C}
\_SB.PCI0.LPC0.EC0.SBMN {53 4D 50 00 32 30 32 31 00 00 00 00 00 00 C0 C0 }
\_SB.PCI0.LPC0.EC0.SBDN {4C 4E 56 2D 35 42 31 31 48 35 36 33 33 39 }
-\_SB.PCI0.LPC0.EC0.TWBT {C0 C0 01 03 E0 41 00 00 00 00 00 00 00 00 00 00 C0 C0
20 E0 DC 0B 7B 31 00 00 00 00 64 00 0A 11 C0 C0 0A 11 FF FF FF FF FF FF E0 00
0A 00 14 0C C0 C0 68 10 F2 2B 31 00 B4 56 8F 06 EE 12 00 00 C0 C0 53 4D 50 00
32 30 32 31 00 00 00 00 00 00 C0 C0 4C 4E 56 2D 35 42 31 31 48 35 36 33 33 39
C0 C0 4C 69 50 00 00 00 00 00 00 00 00 00 00 00 C0 C0 58 32 58 50 33 35 4C 30
31 4C 46 00 00 00 C0 C0 4C 58 C1 41 80 00 05 00 42 05 00 01 06 00 C0 C0 10 00
02 00 00 00 00 00 00 00 00 00 00 00 C0 C0 42 01 01 01 00 00 7E 10 7E 10 7E 10
04 50 C0 C0 B0 01 B6 0A 29 02 00 00 00 00 00 00 00 00 C0 C0 00 07 00 00 00 00
00 00 00 00 00 00 00 00 C0 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 C0
00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 C0 00 00 00 00 00 00 00 00 00 00
00 00 00 00 }
+\_SB.PCI0.LPC0.EC0.TWBT {C0 C0 01 03 E0 41 00 00 00 00 00 00 00 00 00 00 C0 C0
20 E0 DE 0B 7A 31 00 00 00 00 64 00 0A 11 C0 C0 0A 11 FF FF FF FF FF FF E0 00
0A 00 0D 0C C0 C0 68 10 F2 2B 31 00 B4 56 8F 06 EE 12 00 00 C0 C0 53 4D 50 00
32 30 32 31 00 00 00 00 00 00 C0 C0 4C 4E 56 2D 35 42 31 31 48 35 36 33 33 39
C0 C0 4C 69 50 00 00 00 00 00 00 00 00 00 00 00 C0 C0 58 32 58 50 33 35 4C 30
31 4C 46 00 00 00 C0 C0 4C 58 C1 41 80 00 05 00 42 05 00 01 06 00 C0 C0 10 00
02 00 00 00 00 00 00 00 00 00 00 00 C0 C0 42 01 01 01 00 00 7E 10 7E 10 7E 10
04 50 C0 C0 B0 01 B6 0A 29 02 00 00 00 00 00 00 00 00 C0 C0 00 07 00 00 00 00
00 00 00 00 00 00 00 00 C0 C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 C0
00 00 00 00 00 00 00 00 00 00 00 00 00 00 C0 C0 00 00 00 00 00 00 00 00 00 00
00 00 00 00 }
\_SB.PCI0.LPC0.EC0.T2BT {00 01 00 00 00 00 00 00 7A 00 00 00 00 00 41 50 50 20
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 1A 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 }
\_SB.SMIB {00000000000000B0}
\_SB.PEBA {00000000F8000000}
@@ -903,5 +903,3 @@
\M414 {0000000000000B00}
\M444 {00 00 00 00 00 00 00 00 00 }
\M449 {00 00 00 00 00 00 00 00 00 }
```
Tested on:
- Kernel: 6.8.1
- Host: 21C6000UBO
- UEFI: 0.1.30
I'm willing to help debug this in any way I can, though i'm out of ideas right
now. I'm also not sure if this is a firmware bug and wanted a second opinion
before sinking more time into this.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
next reply other threads:[~2024-04-08 19:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 19:32 bugzilla-daemon [this message]
2024-04-08 20:58 ` [Bug 218696] DYTC frequency scaling deterioration and event spam bugzilla-daemon
2024-04-09 9:14 ` bugzilla-daemon
2024-04-09 9:51 ` bugzilla-daemon
2024-04-09 13:26 ` bugzilla-daemon
2024-04-09 14:30 ` bugzilla-daemon
2024-04-10 0:34 ` bugzilla-daemon
2024-04-10 17:08 ` bugzilla-daemon
2024-04-13 5:23 ` bugzilla-daemon
2024-05-08 4:20 ` bugzilla-daemon
2024-05-14 0:58 ` bugzilla-daemon
2024-05-27 13:25 ` bugzilla-daemon
2024-05-27 17:20 ` bugzilla-daemon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-218696-215701@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).