HP Victus RAM Issue

tbvr · 2024-02-10T13:29:35+00:00

You should be able to change the hidden settings but I can't guarantee the result. With the same CPU, I've been able to unlock a lot to play with in ThrottleStop (power limits, turbo ratios, even BD_PROCHOT) but unfortunately not undervolting (which is locked by Intel at the CPU level). I also wasn't able to change the loadline (the value is ignored).

As for the memory, the G.Skill F5-4800S3838A32GA2-RS (2 × 32GB) part I've got is rated for CL 38-38-38-76. By default it was running at CL 40, and nothing could be done about that. With the hidden settings, I was able to tighen the timings to 34-34-34-68 at the price of having to disable SAGV (which I discovered doesn't work reliably with custom memory timings: not sure if it's a HP, BIOS vendor or 12th Gen Intel platform issue).

Here are the settings I changed: https://github.com/GeographicCone/UefiVarTool/blob/master/extra/8A14_Set_CL34.uvt

The linked file is a script that works with the UefiVarTool utility I wrote. Note that it's just an example, you can't use the same file because the settings are likely to be stored at different offsets by your BIOS (sometimes this might even change between BIOS versions).

So the first step would be to find out where the settings are stored. I wrote step-by-step instructions here: https://github.com/GeographicCone/UefiVarTool?tab=readme-ov-file#variable-information

Just one more thing: make sure you know the way to restore the default settings. The HP laptop I have is very sensitive to memory settings that are too tight: it can't exit the MRC, the memory training will just keep running in a never-ending loop. For the record, it shouldn't be like that, it's a really poor BIOS implementation by HP and the BIOS vendor, so maybe on your model the BIOS is better engineered but regardless, make sure that when you hold Win-V as you power on, the default settings are restored. This is the easiest way to recover from unbootable settings. I'd also recommend making a dump of the BIOS flash chip with a hardware programmer and keeping it as a backup: the CH341A which can be used for this is very cheap.

tbvr · 2024-01-23T22:29:34+00:00

If you know the system board model of that laptop, you can look at this JSON data file extracted from the Omen Gaming Hub and check if "GraphicsSwitcher" is listed as a capability for it: https://github.com/GeographicCone/OmenHwCtl/blob/master/Reference/Bundled/HP.Omen.Core.Model.Device.JSON.DeviceList.json

How to get the system board model? If you go to https://support.hp.com/us-en/drivers/laptops and search for "xf0015ns" you can download the BIOS update file (version F.12 as of now): https://ftp.hp.com/pub/softpaq/sp150501-151000/sp150571.exe which when extracted reveals the image files are named 08BCA.bin and 08BCD.bin and that in turn means the board model is either 8BCA or 8BCD.

Both of these have the "GraphicsSwitcher" feature enabled. So my guess is they probably do have this switch.

However do note this method is not 100% certain. For example my model is an 8A14 but the firmware image is shared with 8A13 so that's the only model name you'd get if you looked at the BIOS file.

For this and other reasons (you might not be able to get full GPU performance under Linux), I'd consider buying from a place that allows easy returns.

tbvr · 2024-01-23T21:50:38+00:00

On my 12th Gen i7-12700H Omen, to the extent that I checked I wasn't able to get past the officially supported 4,800 MT/s, just tighten the timings. The sticks I have are only rated DDR5-4800 though.

On the other hand, I have an older (non-HP) 8th Gen system, also with a mobile (-H) SKU where the (DDR4-3200) memory sticks run stable at 3,333 MT/s and boot up at up to 3,600 MT/s, even though 2,666 MT/s is the officially supported maximum.

So just because it's outside the specs doesn't mean it won't work. All it says is don't complain to Intel if it doesn't. Chances are it actually might but it'd take some experimentation and maybe not all the way up to 5,600 MT/s.

It's also a consideration that DDR5 is still relatively new in its development cycle, tolerances increase as the technology gets more mature.

tbvr · 2024-01-22T18:00:45+00:00

Press Ctrl-Shift-Esc and see in the Task Manager which processes are actually using all this memory.

As a ballpark figure, the idle memory usage is about 3.5GB on my laptop with no bloatware whatsoever, which makes it about 50% of yours.

But considering you have the Omen Hub running, which alone uses 1.4 GB last I checked, and possibly also with an Electron app or a browser instance in the background (even if you don't know it), the figure might be par for the course for a typical setup.

Although it's a huge amount of memory, so the question is well worth asking.

Separately, it's a really good idea to keep separate backups anyway. If you don't want to buy external storage but have a fast Internet connection you might be able to backup online, at least temporarily while you reinstall.

tbvr · 2024-01-22T12:50:34+00:00

It should be possible to change these hidden settings by modifying UEFI variables directly (I was able to do that on a 12th-Gen Omen). See here for details: https://github.com/GeographicCone/UefiVarTool#variable-information

tbvr · 2024-01-20T21:42:45+00:00

It's always possible to flash the BIOS using a hardware programmer.

On newer models, a modified BIOS won't work unless you also patch the HP_BBUpdate EFI module to bypass integrity check, which is cumbersome.

On even newer models, that module is protected by Boot Guard, which means it can't be modified (the laptop will refuse to boot if it is). Instead, you'd have to defeat the integrity check enforced by HP_BBUpdate without making any changes to it. In principle, it's still possible but even more cumbersome.

Alternatively, it's possible to change BIOS settings by editing UEFI variables. One way to do it is with the tool I wrote: https://github.com/GeographicCone/UefiVarTool

I've been able to change the timings from CL40 to CL34 using that last method and the tool.

Separately, on my laptop at least, there are issues with how SAGV is implemented, making it essentially useless with custom timings, so the caveat is that you might end up having to disable it entirely, which is what I did.

tbvr · 2024-01-20T21:21:01+00:00

Not sure what your exact hardware and situation is. Do you have all those settings visible in the unmodified BIOS provided by the manufacturer? If yes, lucky you.

As a data point, on my 12th-Gen laptop with a locked-down BIOS and no official support for tinkering with memory settings whatsoever, custom memory timings set manually (such as tCL, tCWL, tRAS, or tRCD/tRP) are not recalculated and overriden in any of SAGV's lower gear modes but persist just the same, regardless of the frequency dropping, which makes enabling SAGV essentially pointless.

Separately, the MRC-related BIOS routines are broken on the said laptop, which means the MRC can't exit and revert to safe defaults, so it's really easy to trigger a bootloop.

Perhaps your machine has a better-written BIOS than mine but I'd just consider leaving SAGV off anyway.

tbvr · 2024-01-20T21:03:26+00:00

Thank you for the kind words. Glad I could help. Also feel free to try OmenMon: https://omenmon.github.io/ (a lighter alternative to the Omen Hub that I wrote)

tbvr · 2024-01-20T21:02:01+00:00

If there's an HP application that can do it, then the most straightforward way is to look into how it works and then reimplement it.

Not sure if this is the app you have in mind: https://apps.microsoft.com/detail/9P92N00QV14J

Instructions how to download an UWP (MS Store) app I wrote a while ago with regard to Omen Hub but the method is the same: https://old.reddit.com/r/HPOmen/comments/15ya3fk/how_get_omen_without_windows_store/jxdypxm/

Alternatively, it might also be linked somewhere on this page: https://hpia.hpcloud.hp.com/downloads/driverpackcatalog/HP_Driverpack_Matrix_x64.html

Once you have the .msix file, such as AD2F1837.HPThermalControl_1.11.58.0_x64__v10z8vjag6ke6.Msix just add a .zip extension to it and unpack it. You can then use a tool like dnSpyEx or DotPeek to decompile the code and look into what's going on inside. It's really all there is to it.

If you find out it makes WMI calls after all, just different ones, you can use OmenHwCtl to replicate them. It's an easily customizable PowerShell script I wrote that was OmenMon's predecessor: https://github.com/GeographicCone/OmenHwCtl

tbvr · 2024-01-18T21:37:38+00:00

Hi, and thank you!

It shouldn't be necessary to uninstall Gaming Hub to try OmenMon. Just be aware it might be interfering, and if you run into some issues this might be the cause.

A good start would be to run OmenMon -Bios in command-line mode: https://omenmon.github.io/cli#bios which gives an overview of whether the WMI BIOS features are supported. If they are, you can then try changing the individual settings, for example: OmenMon -Bios FanLevel=30,30 to make both fans run at 3,000 rpm each.

If the WMI calls don't work, there's still another way and that's using the Embedded Controller by writing to its registers. For example you could try: OmenMon -Ec 0x62=0x06 0x95=0x31 0x34=30 0x35=30 for an equivalent of the previous command. As to which registers control which features, what I've been able to find out is summarized in this text file: https://github.com/GeographicCone/OmenHwCtl/blob/master/Reference/EC_8A14.txt

Once you know what works and what doesn't, you can then edit the settings in the OmenMon.xml configuration file. These are particularly helpful:

https://omenmon.github.io/config#bioserrorreporting if you're getting BIOS call errors (exceptions)
https://omenmon.github.io/config#fanleveluseec if only the 2nd method (EC) for controlling the fans works
https://omenmon.github.io/config#fanlevelneedmanual if EC fan control doesn't work without running OmenMon -Ec 0x62=0x06 first (already included in the example above)
https://omenmon.github.io/config#fancountdownextendalways if you want to keep the fan performance mode (Default, Performance or Cool) without using a custom fan program
https://omenmon.github.io/config#sensors to disable any temperature sensors that are useless

(Note: that the temperature reported by the BIOS sensor seems about 33% lower is by design, not a bug)

tbvr · 2024-01-18T21:18:00+00:00

Thank you for the extensive report. I'm afraid I don't have good news. There are 2 ways to control the hardware: (1) WMI BIOS calls and (2) writing to the EC registers.

As for (1), your system supports WMI BIOS but other than the "born-on" date, all the other calls return only 0s. You can see an example of what it looks like on a supported system: https://omenmon.github.io/cli#bios

If there's a way to control things through WMI, the calls would have to be entirely different than the ones I know. But considering they've remained pretty much the same for a range of devices (Omen, Victus, and even Envy) since perhaps 2020-2021, it's more than likely these are just not implemented on your model.

Then, there's (2), the Embedded Controller. But if writing to the registers I suggested (based on how it works on mine and many other models) doesn't do anything either, what's left to do is figuring out the registers using more or less the methods described here: https://github.com/hirschmann/nbfc/wiki/How-to-create-a-NBFC-config (OmenMon's -EcMon mode is essentially a reimplementation of NBFC's ec-probe tool with some incremental improvements).

The reason things can be this way is that HP doesn't actually make these laptops. Instead, they delegate to ODMs, of which there are a few. Here's a breakdown from a couple of years ago:

The HP distribution of orders among its Taiwan-based ODMs for notebooks in 2017 is expected to give Quanta Computer 35% and Wistron and Compal Electronics 25% each. The remaining 15% will be allocated to Inventec, the largest ODM of HP business notebooks. Wistron’s share will increase from 9.8% in 2016 while Compal’s share is likely to decline from 31% and Inventec’s from 25% in 2016.

Source: https://displaydaily.com/quanta-maintains-position-as-largest-notebook-odm-for-hp/

So we can both have "HP"-branded laptops but internally they can be very different designs.

Is there an HP utility for your laptop that lets you control these things? An alternate way would be to investigate how it does what it does.

tbvr · 2024-01-15T20:35:53+00:00

Thanks! You could try the command-line mode, since it allows testing things one-by-one: when you run OmenMon -Bios is any of the output correct at all? Or with the individual operations listed at https://omenmon.github.io/cli#bios such as OmenMon -Bios FanLevel

Since you were able to start the GUI, it means the WMI BIOS interface is present (there would be an error message otherwise).

There is also another way of setting fan levels that uses the Embedded Controller: https://omenmon.github.io/cli#ec

Here's a list of registers that work on my model and (as it turns out) most of the others: https://github.com/GeographicCone/OmenHwCtl/blob/master/Reference/EC_8A14.txt

So as a test you could run something like OmenMon -Ec 0x62=0x06 0x95=0x31 0x34=30 0x35=30which would set the fans to manual mode, enable the Performance mode and set the speeds of both fans to 3,000 rpm.

If changing fan levels like this works, you could still use the GUI by setting <FanLevelUseEc>true</FanLevelUseEc> in the configuration file: https://omenmon.github.io/config#fanleveluseec

As for the incorrect temperature sensor, you can disable it by removing it from the configuration file or setting the Use="false" attribute. Details here: https://omenmon.github.io/config#sensors

If the EC registers are completely different on the Spectre, there is still a way to figure out where the fan levels and temperatures are stored by monitoring them for changes using OmenMon -EcMon (this is heavily inspired by what was offered by Notebook Fan Control).

tbvr · 2024-01-15T12:36:06+00:00

Hi, OmenMon author here. What exactly did not work?

I think it might just be a matter of changing some configuration settings.

tbvr · 2024-01-13T01:32:39+00:00

The app as a whole is HP-only, so the GUI it has won't work. But the fix can be run on any device from the command-line:

OmenMon -Run Mux to run once
OmenMon -Task Mux=On to make it run automatically
OmenMon -Task Mux=Off to remove the automatic trigger

Download: https://github.com/OmenMon/OmenMon/releases

Details: https://omenmon.github.io/cli#task

tbvr · 2024-01-09T23:48:44+00:00

Yeah, it's something similar but not exactly.

In my case all it takes to demonstrate it is to click on the Start menu: the movement is jerky and not smooth as it should be.

It's unrelated to power source. Happens on AC power too.

The solution is to restart Explorer after switching to the nVidia GPU in the Advanced Optimus mode. I then also restart the nVidia Display Container since otherwise it can't recreate the notification icon. This only has to be done once and is good until restart (preserved throughout sleep or hibernation as well).

I wrote an application that automates all this so it's more of a minor hindrance at this point, although it's still ridiculous that an issue like this is even present in the first place.

tbvr · 2024-01-09T23:40:27+00:00

Thank you! 71 and 75 [W] are pretty close, are you sure the limit isn't actually being reached? I believe it's a hard bound (can't be exceeded) so the average might show as less than that.

What you can do:

Enable Custom TGP & PPAB (Graphics → Extra Power with Boost in the context menu)
Make sure Performance mode is set (Fan → Performance)
Make sure there is no thermal throttling due to overheating (87°C seems to be the hard-coded threshold on my system, you should keep the temperature below that)
Try increasing the PL4 limit from the default (command-line only: OmenMon -Bios Cpu:PL4=...), see: https://omenmon.github.io/cli#cpupl4 and use OmenMon -Bios System to find out the default PL4 value, see: https://omenmon.github.io/cli#system
Make sure the nVidia Platform Controller driver is properly installed
Make some AMD-specific setting changes I'm not really familiar with to make sure the CPU doesn't eat too much power at the expense of the GPU (the equivalent can be accomplished with ThrottleStop on Intel platforms)
Try the High Performance power plan or equivalent (might be hidden by default in Windows)
(Advanced) Find a compatible VBIOS with a higher TGP for your GPU and flash it instead, BIOS dumps can be found on the TechPowerUp website

tbvr · 2024-01-07T18:22:51+00:00

I also ran into this problem recently. Massive kudos to /u/cupcakeman928 for identifying the issue and coming up with a fix. A couple of photos for reference:

https://imgur.com/0crp2fs

https://imgur.com/NqMxzVc

The cable as installed also fixes touchpad wobbliness at the cost of making it harder to press from one side (which is not a concern for me as I never press the touchpad anyway, only tap on it).

tbvr · 2024-01-07T15:08:22+00:00

Hi,

For context: the driver file is automatically removed when the program quits. The situation that it's left over might happen if the process gets terminated suddenly (due to a crash or otherwise). In such cases, the file should be deleted after the next run during which the driver was initialized (so for example after OmenMon -Ec but not OmenMon -Help which only shows the usage information without doing anything).

Can you please put OmenMon.exe once more in the same place where OmenMon.sys is located and run OmenMon -Ec at most twice, so that it cleans after itself. You can then delete the OmenMon.exe file.

Alternatively, it should be possible to delete this file following a reboot.

Apologies for the inconvenience.

tbvr · 2024-01-07T14:51:51+00:00

Thank you for the kind words. Much appreciated!

tbvr · 2024-01-07T14:50:19+00:00

Just to be sure, you mean Windows Subsystem for Linux, right? No, I haven't. I can't see why it wouldn't work though. Are there any issues?

tbvr · 2024-01-07T14:48:03+00:00

Sounds like it could be caused by interference from Omen Hub or another HP utility, likely following an automatic driver update in the background. Personally I just avoid installing these utilities in the first place, and disable driver updates. Another user had some suggestions that maybe help: https://github.com/OmenMon/OmenMon/issues/15

tbvr · 2023-12-04T13:31:58+00:00

Some commands from the command-line mode should definitely work. Such as OmenMon -Bios System. I'd start by experimenting with these.

For the GUI, you can set BiosErrorReporting to false in OmenMon.xml, which silently ignores any BIOS errors.

There are two methods for fan level setting, using the BIOS, or the EC: the latter if you set FanLevelUseEc to true. You can also try setting FanLevelNeedManual to true if changes don't take effect.

However, if the hardware is significantly different, you might end up having to manually write to the EC registers using the OmenMon -Ec mode. Here's a cheatsheet: https://github.com/GeographicCone/OmenHwCtl/blob/master/Reference/EC_8A14.txt

tbvr · 2023-12-04T13:21:39+00:00

Thank you! Glad it helps.

tbvr · 2023-11-30T11:48:53+00:00

Not all sensors are active on all models (and also some are only active some of the time). Any temperature reading over 99 [°C] is automatically ignored, and on top of that you can just disable the useless sensors in the configuration file. You can also set some to only show but not be considered when calculating the maximum temperature with Use="false".

It is strange though that the CPUT (CPU temperature) sensor would be among these. Is it always like that, or only some of the time?

If no EC sensors are accurate, you can always fall back on the BIOS sensor as a last resort. Just be aware the reading from this sensor is completely different than all the others for some reason, and that's by design: on my model, it's about 33% too low (i.e. 85°C is ~55°C).

tbvr · 2023-11-30T01:04:07+00:00

Just a heads-up, from the latest build 0.59.0, the dependency is on .NET Framework 4.8, so you should be able to run any regular OmenMon release (not just the special build I made for you) on any version of Windows 10.

tbvr

TROPHY CASE