power issue making performance worse

[kaka_tgouku]

Hello,

I'm reporting a performance regression on my HP 15s-fr5007TU (Intel Core i5-1235U) that started immediately after updating the BIOS from version F.22 to F.28 Rev A.

Before the update (BIOS F.22): CPU would boost normally under load, reaching around 1.4GHz+ during gaming and other sustained workloads.

After the update (BIOS F.28 Rev A): CPU clock speed stays pinned below 1GHz (typically 0.4–0.8GHz) during any sustained workload, including gaming. This happens consistently, with no exceptions, regardless of Windows power plan settings or default BIOS power settings.

Using HWiNFO64, I confirmed the following:

• PL1 is configured at 40W and PL2 at 55W — both look correctly configured, not unusually low
• However, VRLimit, IccMax, and PL4 all show 100% (constantly asserted), even at idle
• CPU package temperature stays low throughout — this is not a thermal throttling issue
• The behavior is consistent and does not clear on its own; it is present continuously under any load

Since PL1/PL2 are configured normally but VRLimit/IccMax/PL4 are constantly maxed, this points to a current-delivery/power-management regression introduced specifically by the F.28 Rev A firmware, not a hardware fault or user configuration issue.

I attempted to roll back to BIOS F.22 to confirm this, but HP's rollback protection blocks downgrading past this update.

Could you please:

1. Escalate this as a known/reported issue to the BIOS/firmware team, and
2. Let me know if a corrective BIOS update is planned, or if there's another supported path to restore normal power delivery behavior?

Happy to provide HWiNFO64 screenshots, sensor logs, or a screen recording of the clock behavior during load if useful.

Thank you.

[kaka_tgouku]

there is a model not detected correctly my actual laptop model is 15s-fr5007tu notebook

[NonSequitur777]

@kaka_tgouku,

Welcome to our HP Community forum!

Hello, and thank you for providing such a detailed and technically useful report. The immediate change in CPU behavior following the F.22 → F.28 Rev A BIOS update is significant, and your HWiNFO observations certainly warrant further investigation.

There is, however, one important point I would like to verify before we conclude that F.28 introduced a VRM/current-limit regression.

I checked HP's published BIOS documentation for the 15s family, and HP identifies the 15s-FR5xxx family separately from the FR0xxx/FR1xxx families. HP's published releases show the FR5xxx series receiving F.18, subsequently F.20, and later F.22 BIOS releases, whilst F.28 is associated with other FR-series families.

Because your system is an HP 15s-fr5007TU, I therefore want to verify that F.28 Rev A is actually the BIOS intended for your exact machine rather than assuming that the version number alone establishes compatibility.

Please provide these details:

Open System Information (msinfo32) and provide:

• System Model
• System SKU
• BIOS Version/Date
• BaseBoard Manufacturer
• BaseBoard Product
• Processor

Also, please provide the exact HP SoftPaq number or filename of the F.28 Rev A BIOS package you installed.

That information is important because I don't want to recommend a recovery procedure until we establish that the firmware currently installed is the correct HP firmware for your exact product/SKU.

About the HWiNFO readings:

Your observation that VRLimit, IccMax and PL4 are continuously asserted is certainly interesting. However, I would be a little more cautious about interpreting those readings as proof that the physical VRM is actually hitting a current limit.

HWiNFO is reporting processor/firmware telemetry. A firmware configuration or telemetry problem can potentially produce apparently contradictory readings. In other words, those indicators establish that the processor is reporting a limiting condition; they don't, by themselves, establish exactly why that condition exists.

The much stronger evidence is the before-and-after behavior you have documented:

BIOS F.22
→ normal CPU boost/performance

BIOS F.28 Rev A
→ immediate and persistent 0.4–0.8 GHz behavior under sustained load

CPU temperature
→ remains low

PL1/PL2
→ reported at reasonable values

Windows power plans
→ no meaningful effect

If F.28 Rev A is confirmed to be the correct BIOS for this particular 15s-fr5007TU, that would make a BIOS-level performance/power-management regression a very reasonable possibility.

One additional test would be extremely useful:

With the original HP AC adapter connected and recognized, run a sustained CPU workload and capture HWiNFO showing:

• CPU utilization
• CPU clock
• CPU package temperature
• PL1
• PL2
• VRLimit
• IccMax
• PL4

Please also confirm whether the severe throttling occurs:

1. Only while connected to AC power, or
2. On both AC power and battery

If the processor reaches high utilization while remaining around 0.4–0.8 GHz, with low temperatures and the same limiting indicators asserted, that would provide particularly strong evidence that we're dealing with a firmware/power-management limitation rather than conventional thermal throttling.

Regarding the BIOS rollback:

I would not recommend attempting to bypass HP's BIOS rollback protection with an unofficial BIOS, modified firmware, or an SPI-programming workaround. That could turn a performance problem into a non-booting motherboard.

If F.28 is confirmed as the correct firmware for your exact system and the regression can be reproduced, the appropriate course is to document it as a firmware-induced CPU performance/power-management regression and pursue HP's supported BIOS/firmware path.

The timing you have documented is certainly compelling, and I think you have provided enough information to justify investigating this further. I just want to verify the exact system SKU and F.28 SoftPaq before we attribute the problem to that BIOS with confidence.

Kind Regards,

NonSequitur777

[kaka_tgouku]

thank you for your reply 
i have actually updated so i can't send u the previous bios version with date
System SKU- 6P130PA#ACJ
System Model- HP Laptop 15s-fr5xxx
BIOS Version/Date AMI- F.28, 21-04-2026
BaseBoard Manufacturer- HP
BaseBoard Product- 8A20
Processor- 12th Gen Intel(R) Core(TM) i5-1235U, 1300 Mhz, 10 Core(s), 12 Logical Processor(s)
the download file name of bios was sp173045.exe
my orginal hp charger still is giving me heavy throttling  under sustained load:-
cpu utilization:99%
cpu clock speed:0.63ghz
cpu package temp:68 celsius
pl1:21.7W
pl2:24.2W
with battery:-
cpu utilization:100%(most of the time)
cpu clock speed:0.43ghz
cpu package temp:70 ( highest temp)

pl1:22.9W
pl2:25.2W
i cant see any vr limit and pl4 limit value because of the BIOS restriction

these reading are after that pl4 limit doing heavy downclocks i cant get the normal reading because of how fast the downclocking restrictions  apply
thank you for your reply i appreciate this because other communities don't help much

One additional detail: since the BIOS update, I have also experienced some system instability, including occasional freezes/BSODs.

[kaka_tgouku]

thank you for your reply  these are the specifications
system model-hp laptop 15s-fr5xxx
system SKU-6P130PA#ACJ
bios version/date-AMI f.28, 21-04-2026
baseboard manufacturer-hp
basebaord product-8A20
Processor-12th Gen Intel(R) Core(TM) i5-1235U, 1300 Mhz, 10 Core(s), 12 Logical Processor(s)
with original ac adapter connected under load:-

cpu utilization:100%
cpu clock speed:0.59ghz
cpu package temperature: 68 celsius
pl1:21.4W
pl2:26.5W
on original hp battery:

cpu utilization:100%
cpu clock speed:0.52ghz
cpu package temperature:66 celsius
i alos had many system freeze/BSOD's since the bios f.28 update and  i can't post the vr and iccmax  values because the system downclocks so fast that i cannot see it before it comes and it also isnt showing me the current values because of restriction.

[NonSequitur777]

@kaka_tgouku,

Thank you for providing all of those details. This clarifies the situation considerably, and I need to correct one point from my previous reply.

I have now verified HP's own documentation: F.28 is indeed the correct BIOS for the HP 15s-fr5xxx family, and SP173045 is the HP BIOS package for that family. HP also previously listed F.22 for the 15s-fr5xxx family. So your reported F.22 → F.28 transition is a valid BIOS upgrade path; you did not install the wrong BIOS.

[EDIT:] HP's February 2026 security-update bulletin identifies F.28 Rev 4 / SP173045 for the 15s-fr5xxx family, although HP has subsequently removed that SoftPaq from its download site. 

That is materially different from saying we have a currently downloadable HP BIOS package.

However, the bulletin itself is enough to establish that HP assigned F.28/SP173045 to the 15s-fr5xxx family, but it does not establish that F.28 is currently the latest BIOS available for the OP's specific 6P130PA#ACJ SKU.

Your additional testing also makes the case considerably stronger.

What your results now show:

With the original HP AC adapter connected:

• CPU utilization: 100%
• CPU clock: ~0.59 GHz
• CPU temperature: 68°C
• PL1: 21.4 W
• PL2: 26.5 W

On battery:

• CPU utilization: 100%
• CPU clock: ~0.52 GHz
• CPU temperature: 66°C

This is not behaving like conventional thermal throttling. The CPU is heavily loaded, temperatures are nowhere near the point where we would expect thermal protection to force the processor down to ~0.5–0.6 GHz, yet the processor is being held at an extremely low frequency.

The fact that the same basic behavior occurs both on the original AC adapter and on battery is also useful. It makes an adapter-recognition problem much less likely.

The new BSOD/freezing information is particularly important:

The fact that you began experiencing system freezes and BSODs only after installing F.28 is significant.

We therefore now have two separate categories of regression following the same firmware update:

Performance regression

F.22

→ normal CPU boosting

F.28

→ sustained ~0.4–0.8 GHz under 100% load

System stability regression

F.22

→ no reported pattern of these freezes/BSODs

F.28

→ freezes and BSODs began occurring

That combination makes a BIOS/firmware regression a reasonable working hypothesis, rather than simply a Windows power-plan problem.

I also agree that there is little value in chasing the VRLimit/IccMax/PL4 readings further if F.28 is forcing the processor into the throttled state before HWiNFO can capture meaningful values. The absence of those values in your current HWiNFO display does not invalidate the much more important evidence you already have.

One thing I would like you to check before we go further:

Because you are experiencing BSODs, please open:

Event Viewer → Windows Logs → System

and look around the time of one of the BSODs/freezes for:

• WHEA-Logger
• Kernel-Power
• BugCheck
• Kernel-Processor-Power
• ACPI
• Kernel-PnP

If you find a WHEA-Logger event, please post the complete event details, particularly the Event ID and the text under General.

Also, if Windows has created a minidump, please check:

C:\Windows\Minidump

and tell me whether there are .dmp files there. Do not delete them.

Those results could tell us whether F.28 is causing a processor/power-management fault, an ACPI/firmware error, or a separate Windows driver problem.

I would not try to bypass HP's rollback protection:

I understand why you want to get back to F.22, because the timing makes that an obvious diagnostic test. However, I would not recommend forcing a BIOS downgrade through an unofficial method, modified firmware, or SPI programming.

The safer approach is to document the regression and have HP investigate the firmware.

At this point, I think you have a much stronger technical case to present to HP:

HP 15s-fr5007TU / 15s-fr5xxx, SKU 6P130PA#ACJ, board 8A20, Core i5-1235U

Immediately after F.28:

• CPU becomes limited to approximately 0.4–0.8 GHz under sustained load
• CPU utilization reaches 100%
• CPU temperature remains approximately 66–70°C
• Severe throttling occurs on both AC and battery
• System freezes and BSODs also began after the BIOS update

HP's own documentation confirms F.28/SP173045 is the intended BIOS for the 15s-fr5xxx family.

That is now a substantially more compelling firmware regression report than the original performance-only report.

Please post the WHEA/Kernel-Power/BugCheck event information and whether C:\Windows\Minidump contains dumps. Those are the next pieces of evidence I'd want before recommending anything more invasive.

Kind Regards,

NonSequitur777

[kaka_tgouku]

thank you for your reply sir
i don't have older event logged history because i have recently reinstalled windows because i had a possibility that these errors and BSOD's  but it clearly was not but i do remmeber therew were no whea logger events but around 50 kernel power events and right now i have 30 kernel power events ( 13-14 kernel power errors per month)
the current ID's of major errors

TPM-WMI errors event id: 1796 always 
i have also found many secure boot update failed causing some hard freezes and crashes
there are also HAL errors with event id 21 they made a very hard crashes for my laptop  it made my laptop not booting and corrupting some parts of kernel because i also got kernel corruption errors these are new and have never happened to me in f.22 
i am also getting kernel processor power errors and warning saying my cpu cores  go in reduced performance state for more than 2mins and having the event id of 37 and the most errors i found after the f.28 bios update is ditributed COM event id 10016
 some kernel PnP errors also here with event id of225
because of those HAL errors my time and clock was set to year 1994 which is impossible for this system because it was never bought in 1994 not even close
and since this update my laptop has stopped taking updates most of the time i always fail a windows update and i am extremely disappointed by this service
i would much appreciate a way to help me with these errors

[NonSequitur777]

@kaka_tgouku,

Thank you for coming back with this additional information, and I'm sorry you're having to deal with all of this. The new information actually makes the F.28 regression hypothesis considerably stronger.

And I want to make one distinction right away: not every error in Event Viewer is necessarily being caused directly by F.28. Windows Event Viewer can contain a lot of secondary errors after a firmware, boot, or power-management failure. We need to identify which events are actually significant.

The events I consider most important:

From what you've reported, these are the ones I would concentrate on:

1. HAL Event ID 21 — HIGH PRIORITY

You said these events have caused extremely hard crashes, including a situation where the laptop would not boot and you subsequently saw kernel-corruption errors.

That is not something I would dismiss as an ordinary Windows error, particularly because you say this behavior did not occur with F.22.

The Hardware Abstraction Layer (HAL) sits very low in the Windows architecture and interfaces with processor/platform hardware. If these events are occurring during firmware/power-management failures, they deserve close examination.

Please post the complete "General" text from one of the HAL Event ID 21 events.

2. TPM-WMI Event ID 1796 — HIGH PRIORITY

The fact that Event 1796 occurs repeatedly is also interesting, especially because we've already been investigating Secure Boot/firmware certificate problems on other HP systems.

Please post the complete text under General for one TPM-WMI 1796 event.

3. Secure Boot certificate-update failures — HIGH PRIORITY

This is particularly important.

If Windows is repeatedly attempting to update the Secure Boot certificates and the firmware rejects or fails the operation, that is another indication that the interaction between Windows and the system firmware may not be functioning correctly.

Please post the complete General message from one of these Secure Boot update failure events, including the Event ID and Provider.

4. Kernel-Processor-Power Event ID 37 — VERY IMPORTANT

This one directly relates to the performance problem we've already established.

You are seeing Windows report that processor cores are being placed into a reduced-performance state for an extended period, while HWiNFO is simultaneously showing the processor sitting around 0.4–0.8 GHz under 100% load.

That is a meaningful correlation.

It doesn't prove that F.28 is responsible by itself, but when combined with:

F.22 → normal operation

F.28 → severe clock restriction + processor-power events

it makes the firmware/power-management hypothesis considerably more credible.

Kernel-Power is a little different:

Your approximately 30 Kernel-Power events, including roughly 13–14 per month, are worth recording, but I don't want to interpret those as proof of a particular hardware failure.

Kernel-Power Event ID 41 generally means Windows detected that the previous shutdown/restart was not clean. It tells us that something went wrong, but generally not why it went wrong.

So the Kernel-Power events may be the result of the hard freezes rather than the cause.

The same principle applies to some of the kernel-corruption messages.

DCOM 10016 is probably not our culprit:

You mentioned that you have found many DistributedCOM Event ID 10016 errors.

I would not focus on those right now.

Event 10016 is extremely common in Windows installations and is frequently generated by normal permission behavior involving COM/DCOM components. It is generally not an explanation for severe CPU throttling, firmware failures, or hard system crashes.

So please don't start changing DCOM permissions based on those events.

Kernel-PnP Event 225:

This one is worth looking at, but again, the complete event text matters.

Event ID 225 can be associated with a device that Windows was unable to stop/eject correctly, so the Event ID alone doesn't tell us whether it has anything to do with your problem.

Please post the General text from one representative Event 225.

Your Windows Update problem is interesting:

You said Windows Update has also been failing repeatedly since the F.28 update.

That is worth investigating, but I don't want to assume that F.28 is directly preventing Windows Update.

There are at least two possibilities:

A. F.28 is causing a low-level firmware/power-management problem which is destabilizing Windows and consequently causing updates to fail.

B. The Windows installation has accumulated separate servicing problems, possibly as a consequence of the hard crashes.

Your recent clean Windows installation makes this particularly interesting. If Windows Update problems continue on a fresh installation while the F.28 BIOS remains installed, that would be another useful data point.

And the 1994 date is especially interesting:

The fact that the system clock suddenly reverted to 1994 following one of these severe HAL-related crashes is certainly unusual.

However, I don't want to jump straight to "the BIOS corrupted the RTC".

A sudden incorrect system date can occur if the platform/RTC loses its stored time or if firmware/Windows encounters a low-level failure during initialization.

Please don't replace the CMOS/RTC battery yet.

If the date repeatedly resets to the same incorrect value after hard crashes, that becomes a much more significant clue.

Here's what I'd like you to do next:

Because you've already reinstalled Windows, please don't reinstall Windows again. We have enough evidence now that another clean installation isn't going to answer the fundamental question.

Instead, let's collect the actual event messages.

Please post the complete General text from:

1. HAL — Event ID 21
2. TPM-WMI — Event ID 1796
3. One Secure Boot certificate-update failure
4. Kernel-Processor-Power — Event ID 37
5. Kernel-PnP — Event ID 225

For each one, please include:

• Provider
• Event ID
• Level
• Date/time
• Complete text under General

The date and time are particularly important. If several of these events occurred within seconds or minutes of one another, we may be able to establish a sequence such as:

firmware/Secure Boot event → processor power-management event → HAL failure → system freeze/restart → Kernel-Power 41

That would be considerably more useful than simply counting the number of errors.

One more thing:

If you can identify one specific hard freeze/crash that you remember occurring, give me approximately when it happened — even just the date and approximate time.

Then we can look at the events immediately before and after that incident rather than trying to interpret hundreds of unrelated Event Viewer entries.

At this point, I would describe your situation to HP as follows:

The F.28 BIOS update was followed by severe processor frequency restriction, new processor-power events, HAL-related hard crashes, Secure Boot servicing failures, TPM-WMI errors, Windows Update failures, and system instability that was not present under F.22.

That is a substantially stronger firmware-regression report than simply saying "my laptop became slower."

And I understand your frustration. You should not have to chase dozens of unrelated Event Viewer errors just to get a laptop functioning normally after a BIOS update. Let's separate the meaningful firmware/platform evidence from the normal Windows noise and work from there.

For now, do not attempt another BIOS downgrade, don't modify TPM/Secure Boot keys, and don't make DCOM registry/permission changes.

Post those five event details, and we'll see whether they are actually connected.

Kind Regards,

NonSequitur777

[kaka_tgouku]

thank you for helping me with this issue  these are the things u asked for .I checked the requested events. I found repeated Secure Boot/sbat update failures with error 0x800700c1. I also found repeated processor power-management events stating that processor 7 and processor 11 in group 0 were being limited by system firmware and had remained in the reduced-performance state for 71 seconds. In addition, I found repeated acpi errors stating: “The hardware real-time clock was not set because evaluation of the acpi Time and Alarm Device method failed. Status: 0xC0000001.” These are the main relevant events I was able to find. My Event Viewer contains several months of entries, so I did not go through every occurrence, but these events were repeated. The processor-limitation events seem particularly relevant because they match the severe ~0.4–0.8 GHz behavior I have been experiencing after F.28. I also previously mentioned that the system clock unexpectedly reverted to an incorrect date after one of the severe crashes. Since I reinstalled Windows after the earlier crashes, I no longer have the original Event Viewer history or mini dumps from that period. i am sorry i can't send all dates because they are 4-7 months  of events which i cannot send  also  just almost a week ago i had 4 back to back BSODs which did not even let me turn on laptop also that display turned on but no output i feared of having a dead graphics processing unit i was not even using anything i just had a browser open with my study materials because of freeze no output or input taken from laptop i had to restart it and then i got these BSODs the approximate date according to me was maybe 23rd august or 21st august (this month) if u can please help me fix these issues as soon as possible because i am a student who having these issues are having an affect on my studies and i am trying me best to keep the laptop running for some years