Unknown thing causing PL1 throttling (HP Spectre x360 2020/i7 1065G7 (U series)

[stevekstevek]

Hi Group,

Something is really bugging me because I can't figure it out.

I almost have my system set up the way I want it (minor undervolt -- can't be too aggressive with this CPU), and generally power limits enabled, but use speedshift adjustments to get either high-response or lower power use for battery.

The problem I have is that my system still sometimes is throttled by a PL1 limit around 14W. If I let it idle for a while then it will peak again with thermal limitations only for about 12 seconds, then throttle down with PL1 again.

The strange thing is that if I unplug it from power (I am using USB-C for power), and then plug it back in, then it's fine and will happily run at 22-23W continuously if it has the workload. Then, mysteriously, it gets itself back into this state -- some hours later.

I'm really perplexed as to what's causing this.

When this is happening, using TS, I see clearly that it it is hitting PL1 when it is throttling. hwinfo64 says the same thing "IA: Package-Level RAPL/PBM PL1". TS reports that PKG Power is 14.2W. I've even dug into CPU settings (using rweverything) to see if there was a "platform level PL1" set, and it is not (MSR is all zeros except for the lock bit).

Since this changes when I switch from AC->DC->AC, it must be something configurable at runtime, but I'm kinda stumped at the moment as to what is setting it or how to either defeat or reset it myself. I can unplug/replug of course, but that's quite annoying (mainly because I also have my USB peripherals going through the same connection and disconnecting/reconnecting them is the pain), and I'm generally just annoyed that I can't figure out what's happening.

Ideas?

 

[unclewebb]

Some computers use an embedded controller (EC) to force feed power limits and the TDP Level to Intel CPUs. These power limits are separate from the power limit that ThrottleStop gives you access to. The same thing for the configurable TDP Level. ThrottleStop shows that you are requesting TDP Level 2 while HWiNFO shows that the CPU is in TDP Level 1. The EC can set the TDP Level internally which can override what you are requesting in ThrottleStop.

After making any changes in ThrottleStop, it is a good idea to exit HWiNFO and then restart it. Some of the data that HWiNFO reports is not being updated in real time so you have to restart it to get it to update. If you do not do this, what HWiNFO shows you when using ThrottleStop might not accurately reflect how the CPU is set up.

I have never really used the Power Balance option and I usually leave the TDP Level at the default 0. I do not bother checking either of these options.

The 1065G7 has a 15W TDP rating. Some manufacturers make sure that you do not go beyond that limit long term. The unplug / plug in trick might briefly get you around this limitation. Long term, it is probably going to get limited again to 15W. Maybe you can use RWEverything to monitor the EC data. I have never really looked into this. I am mostly interested in finding generic solutions to throttling problems.

Have you tried removing the Intel Dynamic Platform and Thermal Framework driver? Removing this driver and blocking Windows from reinstalling it has solved some of these irritating throttling issues. Do a Google search about this driver.

 

[stevekstevek]

Thanks for the reply UW.

The TDP level mismatch was a red herring -- I forgot to refresh hwinfo after playing with the setting in throttlestop.

I separated my peripherals and power supply into two USB-3 connectors, and can now more reliably (and without messing with my peripherals) reproduce the disconnect/reconnect removing the throttling limitation.

I've read you talk about the potential of an EC "setting the TDP level internally", and I'm interested in understanding what that mechanism is -- and perhaps there can be a generic solution to override it's will.

Here's some assertions:
- It has to be integrated with the CPU because when it is throttling the CPU is throwing up the PL1 status.
- It doesn't seem like the "platform" Power settings are the issue because rwe is showing them not set (see image)
- The processor seems to be in Configurable TDP UP (level 2 mode) when this is happening [maybe I ought to double-check this again], and Level-2 is 25W

I'm not sure, from the Intel chip perspective how else an EC might set another throttle. I'll look some more in my "spare" time, but pointers welcome.

 

[unclewebb]

There are 3 unique sets of turbo power limits. There is the MSR power limit that ThrottleStop gives you access to, there is the MMIO power limit that ThrottleStop lets you disable and lock and there is a third turbo power limit controlled by the EC. The CPU compares all of these and uses the lowest power limit that is requested. If the EC wants 15W then that is all you get.

I have never had access to a device with this power limit throttling issue so I have never been able to come up with a solution. Lots of people have looked at this and have run into a wall.

I do not know if the configurable TDP Level and power limit that HWiNFO reports includes the EC set limits. I am pretty sure that HWiNFO does not include these. You would need to contact the developer of HWiNFO to try and find out more about this.

Without access to hardware with this problem and some more documentation, I do not know how to solve this common power limit throttling problem.

 

[stevekstevek]

I did find out that another dptf device seems to have appeared for me -- I needed to add *INT3405 to my list to DenyDeviceIDs to block it. So far this seems to be keeping it out of throttling, but since it was intermittent (and I couldn't figure out the pattern), I'm not calling it a success yet.

Hmm, that wasn't it. It's back to randomly beginning to throttle again. Something in the last set of windows updates must be the culprit.

 

[stevekstevek]

None of the updates seem like they /ought/ to change anything, so I'm back to trying to understand what mechanism could be used to tell the processor to throttle itself.

I probably ought to create a list of what I see in the Intel docs here, but essentially as far as PL1 limits, I see these:

a) The Package-Level limits: These are the ones that TS modifies from the TPL dialog, and go to MSR_PACKAGE_POWER_LIMITS at 0x610. RW-everything and TS both show the same thing here (I have PL1 set to 25W and PL2 set to 50W.
b) The Power-Plane specific limits (MSRs at 0x638 and 0x640). On my system the PP0 (IA [cores]) the PS1 limit was set to 40W (it was 320, but I assume that like the Package limits it is described in 1/8 W increments). I tried setting this much higher, and it didn't make any difference. The PP1 limit register is all zeroes, meaning it's disabled.
c) The Platform Power limit. This one works a bit differently, in that you set a limit with the processor, and then tell the processor what the instantaneous platform power consumption is, then the processor will throttle itself to help keep the overall platform (i.e. your whole laptop) power usage under the threshold. The limit is set with MSR at 0x65c. On my system it's set to all zeroes except for the lock bit. I'm guessing this is the one that TS manipulates from the "Memory" box in the FIVR dialog, since I have that one set to "disable and lock Turbo Power Limits", which matches what I'm seeing.

All of these seem to be manipulated via MSRs. I'm not sure where in the Intel docs to find the "MMIO-controlled" limits unclewebb talked about above. I'm also not sure what the "EC set limits" are. The Intel docs are really long, so I probably missed a lot of things.

Anyone (incl unclewebb) know how the EC might set some other limit? It would seem to me that if an embedded controller wanted to control processor power, the platform power limit would be the way to do it. While I may be not finding the mechanism in the intel docs, maybe I'm naive, but based on how exhaustive they seem, it doesn't seem likely that platform integrators are using some completely undocumented way to do this.

 

[unclewebb]

@stevekstevek - What Intel documentation do you have access to? The publicly available documentation from Intel may seem exhaustive but it leaves out more information than it includes. If you are a developer at a big company like Asus or Dell, then you get to see the real Intel documentation, not the stuff that Intel releases to the public.

I tried setting this much higher, and it didn't make any difference.

How the EC controls the turbo power limits is a well guarded secret. Like you, I would love to know more but that is never likely going to happen. When the EC is in control of the CPU power limits, increasing any of the known MSR power limits will not make any difference.

Here is some more info about where the PL1 and PL2 MMIO power limits are hiding.

English Community-Lenovo Community

it doesn't seem likely that platform integrators are using some completely undocumented way

I am sure the EC is well documented, it is just not publicly documented.

 

[stevekstevek]

So, I still don't quite understand exactly how this works, and that still bugs me.

However, for other readers, I think I may have a solve. It was actually two things that let me figure out this path:

a) I finally figured out how to understand the UEFI forms language (as parsed by UEFITool) that defined the BIOS settings that are all hidden, so that I could change them using ru.efi
b) In another post unclewebb pointed to the IMON parameters as an avenue to explore.

So I found that on my machine, IMON slope was set to 0x64 (100). Based on what I read (and later observed), setting this to 50 instead should cause the system to think it's current (and therefore wattage) is half of the real value.

So I did that. The particular line in my version of the BIOS looks like this:

Numeric: IMON Slope, VarStoreInfo (VarOffset/VarName): 0x109, VarStore: 0x11, QuestionId: 0x15C, Size: 2, Min: 0x0, Max 0xC8, Step: 0x1 {07 94 0A 03 0B 03 5C 01 11 00 09 01 10 11 00 00 C8 00 01 00}
0x2EE9C Default: DefaultId: 0x0, Value (16 bit): 0x0 {5B 07 00 00 01 00 00}
0x2EEA3 End {29 02}

And despite the default being 0, when I looked at the value in question (offset 0x109 in Variable store 0x11 (which is "CPUSetup"), it was 0x64. I changed it to 0x32, and now my system is consistently reporting half of the actual value for power in Throttlestop and HWinfo. So far it's been running now for about 5 hours without any mystery throttling. Hopefully, I've (a) fooled the HP EC mystery throttle, and (b) am not going to overload something important and break things.

I can still set power-based limits in TS (using half of the desired value - so right now I have a PL1 of 13 (26 watts), and a PL2 of 18 (36 watts). I might dial them down a bit so that in normal circumstances I'm near but not at the thermal limits.

If anyone wants to follow in my footsteps (danger -- no warranty from me!), the basic steps to find these settings and change them can be found here: (4) Spectre X360 10th Gen Undervolt Guide : spectrex360 (reddit.com)

 

[Artorias38]

So, I still don't quite understand exactly how this works, and that still bugs me.

However, for other readers, I think I may have a solve. It was actually two things that let me figure out this path:

a) I finally figured out how to understand the UEFI forms language (as parsed by UEFITool) that defined the BIOS settings that are all hidden, so that I could change them using ru.efi
b) In another post unclewebb pointed to the IMON parameters as an avenue to explore.

So I found that on my machine, IMON slope was set to 0x64 (100). Based on what I read (and later observed), setting this to 50 instead should cause the system to think it's current (and therefore wattage) is half of the real value.

So I did that. The particular line in my version of the BIOS looks like this:

Numeric: IMON Slope, VarStoreInfo (VarOffset/VarName): 0x109, VarStore: 0x11, QuestionId: 0x15C, Size: 2, Min: 0x0, Max 0xC8, Step: 0x1 {07 94 0A 03 0B 03 5C 01 11 00 09 01 10 11 00 00 C8 00 01 00}
0x2EE9C Default: DefaultId: 0x0, Value (16 bit): 0x0 {5B 07 00 00 01 00 00}
0x2EEA3 End {29 02}

And despite the default being 0, when I looked at the value in question (offset 0x109 in Variable store 0x11 (which is "CPUSetup"), it was 0x64. I changed it to 0x32, and now my system is consistently reporting half of the actual value for power in Throttlestop and HWinfo. So far it's been running now for about 5 hours without any mystery throttling. Hopefully, I've (a) fooled the HP EC mystery throttle, and (b) am not going to overload something important and break things.

I can still set power-based limits in TS (using half of the desired value - so right now I have a PL1 of 13 (26 watts), and a PL2 of 18 (36 watts). I might dial them down a bit so that in normal circumstances I'm near but not at the thermal limits.

If anyone wants to follow in my footsteps (danger -- no warranty from me!), the basic steps to find these settings and change them can be found here: (4) Spectre X360 10th Gen Undervolt Guide : spectrex360 (reddit.com)

So did it worked? I want to try something similar on my HP Spectre x360 14 with 1165g7.
So I am curoius if it is safe to use it.

 

[stevekstevek]

Yup. It’s working great.
I provide no warranty or guarantee of safety, but it’s been working for me as I hoped for 2.5 months now.

 

[OmegaMalkior]

Pretty sure this workaround only works on 10th gen CPUs for the Spectre line (both 13 inch and 15), but the 1165G7 on the Spectre 14 isn't compatible with this undervolt trick as it uses another method at locking the undervolt. I THINK the 1165G7 in the Spectre 15 remained the same as previous gen so that might be the exception. But I also checked the Spectre 16's 11390H and I think it's the same case as the 14. Really weird way at locking undervolting settings that I haven't found a way at overriding it.