undervolt
undervolt copied to clipboard
georgewhewell
Undervolt values read at start up does not reset
Thank you for the tool!
I have set up the undervolt service and the timer as instructed. I expect after reboot the voltage offsets should be gone (i.e., back to zero). However, when I use the read command (undervolt -r), the values returned are exactly the same as the most recent offset values.
I know that before reading msr some values must be written. That said, is there anyway to check if the voltage offsets are reset after rebooting?
I am assuming rebooting is the same as crashing due to extreme offsets.
Do you have OnBootSec param in undervolt.timer? If so what value do you have there?
Do you have OnBootSec param in undervolt.timer? If so what value do you have there?
Yes I do. It is OnBootSec=2min.
The timer waits for 2 minutes and runs as expected. My concern is how I can check that the voltage offsets are reset within the 2-minute time frame after boot.
I suggest you to increase it to something around 5min.
OnBootSec=5min
Issue sudo systemctl daemon-reload
Then do a reboot and do sudo undervolt --read as soon as you logged in.
Please report back what happens.
Please report back what happens.
I just did what you said. sudo undervolt --read still shows the negative offset values.
Output of checking the service and the timer:
$ systemctl status undervolt.service
● undervolt.service - undervolt
Loaded: loaded (/etc/systemd/system/undervolt.service; enabled; vendor preset: enabled)
Active: inactive (dead)
$ systemctl status undervolt.timer
● undervolt.timer - Apply undervolt settings
Loaded: loaded (/etc/systemd/system/undervolt.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2019-04-09 23:59:57 PDT; 1min 4s ago
Trigger: Wed 2019-04-10 00:04:51 PDT; 3min 49s left
Apr 09 23:59:57 vincente systemd[1]: Started Apply undervolt settings.
What is the Type under [Service] section of undervolt.service? Please make sure it is oneshot.
It is oneshot. Interestingly, I disabled both the undervolt service and timer, applied undervolt using msr-tools, rebooted, and the offset values were still there when I checked. As per mihic/linux-intel-undervolt, the values should not be sticking around after reboot.
I believe i am running into the same problem. Instantly running on negative values after reboot.
The boot-up scripts seems not to be the root cause. I did reset the values to zeros before forcing a shutdown -r now and it does start with zeroes and applied my negative values later on as expected. So it looks like that these applied values just persist a restart.
How about getting uninstalling undervolt.service and undervolt.timer? If you still see negative values, then there is something else applying these settings.
How about getting uninstalling
undervolt.serviceandundervolt.timer? If you still see negative values, then there is something else applying these settings.
Yes. I even tried uninstalling the undervolt.service and undervolt.timer, resetting the offset values to zeros, and then undervolting using msr-tools. After reboot, the negative values still persist. So it might be another problem causing the issue.
A workaround I've done is having a script (using the same undervolt program here) to reset the offset values to zero right at startup.
This is very strange issue. Can you post the hardware you are running this on and distro, etc.
I don't ask you to try... but I wonder what happens if you set offset too high (to point where CPU crash).. does this make machine impossible to boot again?
My machine is a Dell Inspiron 7000 with the chip Intel(R) Core(TM) i5-7200U. I'm using Kubuntu 18.04 dual boot with Windows 10 Home.
Strangely, even in Windows, I tried shutting off ThrottleStop to see if the offset values persist after reboot - and they do!
Running a similar setup on my XPS 15 (i7-8750H). Dual boot Ubuntu 18.04 / Windows 10.
I have the same problem on Asus Zenbook UX433FN, latest BIOS,FW. Running Ubuntu 18.04. I can also confirm this is not a systemd/startup-scripts issue. I'm testing undervolt (from PYPI) and haven't created a service yet at all. Values still persist.
A workaround is to call the script again with "zeroed" values:
undervolt --core 0 --cache 0 --uncore 0 ....
Can you please adapt the systemd script to call this zeroing on Reset, Shutdown of the service?
Interesting fact, on my machine, the undervolt values survive reboot. But are reset during suspend-resume.
Dmesg:
[ 7647.364378] PM: suspend entry (deep)
[ 7647.364379] PM: Syncing filesystems ... done.
[ 7647.415346] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 7647.417100] OOM killer disabled.
[ 7647.417101] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
[ 7647.418278] printk: Suspending console(s) (use no_console_suspend to debug)
[ 7647.728087] ACPI: EC: interrupt blocked
[ 7647.884938] ACPI: Preparing to enter system sleep state S3
[ 7647.889750] ACPI: EC: event blocked
[ 7647.889751] ACPI: EC: EC stopped
[ 7647.889751] PM: Saving platform NVS memory
[ 7647.889760] Disabling non-boot CPUs ...
[ 7647.890100] IRQ 147: no longer affine to CPU1
[ 7647.891111] smpboot: CPU 1 is now offline
[ 7647.895148] smpboot: CPU 2 is now offline
[ 7647.897596] IRQ 146: no longer affine to CPU3
[ 7647.898849] smpboot: CPU 3 is now offline
[ 7647.902165] smpboot: CPU 4 is now offline
[ 7647.904331] IRQ 22: no longer affine to CPU5
[ 7647.904335] IRQ 142: no longer affine to CPU5
[ 7647.905343] smpboot: CPU 5 is now offline
[ 7647.907595] IRQ 122: no longer affine to CPU6
[ 7647.907597] IRQ 123: no longer affine to CPU6
[ 7647.907600] IRQ 128: no longer affine to CPU6
[ 7647.908604] smpboot: CPU 6 is now offline
[ 7647.911191] IRQ 17: no longer affine to CPU7
[ 7647.911198] IRQ 125: no longer affine to CPU7
[ 7647.911200] IRQ 126: no longer affine to CPU7
[ 7647.912221] smpboot: CPU 7 is now offline
[18446744026.323660] [Firmware Bug]: TSC ADJUST differs: CPU0 0 --> -47845639. Restoring
[ 7647.917919] ACPI: Low-level resume complete
[ 7647.918002] ACPI: EC: EC started
[ 7647.918002] PM: Restoring platform NVS memory
[ 7647.918837] Enabling non-boot CPUs ...
[ 7647.918931] x86: Booting SMP configuration:
[ 7647.918932] smpboot: Booting Node 0 Processor 1 APIC 0x2
[ 7647.919506] cache: parent cpu1 should not be sleeping
[ 7647.919735] CPU1 is up
[ 7647.919763] smpboot: Booting Node 0 Processor 2 APIC 0x4
[ 7647.920327] cache: parent cpu2 should not be sleeping
[ 7647.920567] CPU2 is up
[ 7647.920591] smpboot: Booting Node 0 Processor 3 APIC 0x6
[ 7647.921165] cache: parent cpu3 should not be sleeping
[ 7647.921419] CPU3 is up
[ 7647.921443] smpboot: Booting Node 0 Processor 4 APIC 0x1
[ 7647.922104] cache: parent cpu4 should not be sleeping
[ 7647.922721] CPU4 is up
[ 7647.922749] smpboot: Booting Node 0 Processor 5 APIC 0x3
[ 7647.923311] cache: parent cpu5 should not be sleeping
[ 7647.923596] CPU5 is up
[ 7647.923620] smpboot: Booting Node 0 Processor 6 APIC 0x5
[ 7647.924201] cache: parent cpu6 should not be sleeping
[ 7647.924512] CPU6 is up
[ 7647.924535] smpboot: Booting Node 0 Processor 7 APIC 0x7
[ 7647.925115] cache: parent cpu7 should not be sleeping
[ 7647.925429] CPU7 is up
[ 7647.933795] ACPI: Waking up from system sleep state S3
[ 7647.938016] ACPI: EC: interrupt unblocked
[ 7647.939513] pci 0000:02:00.0: Enabling HDA controller
[ 7647.982301] ACPI: EC: event unblocked
[ 7648.101521] nvme nvme0: 8/0/0 default/read/poll queues
[ 7648.238420] usb 1-4: reset high-speed USB device number 2 using xhci_hcd
[ 7648.390588] acpi LNXPOWER:05: Turning OFF
[ 7648.390665] OOM killer enabled.
[ 7648.390666] Restarting tasks ... done.
[ 7648.414478] thermal thermal_zone9: failed to read out thermal zone (-61)
[ 7648.422932] PM: suspend exit
[ 7649.005229] print_req_error: I/O error, dev sda, sector 67056400 flags 801
[ 7649.034736] BTRFS error (device dm-3): bdev /dev/mapper/sdcardDevice errs: wr 57, rd 12, flush 0, corrupt 0, gen 0
[ 7685.590501] wlo1: authenticate with 30:b5:c2:96:ab:5f
[ 7685.595411] wlo1: send auth to 30:b5:c2:96:ab:5f (try 1/3)
[ 7685.634774] wlo1: authenticated
[ 7685.637277] wlo1: associate with 30:b5:c2:96:ab:5f (try 1/3)
[ 7685.641599] wlo1: RX AssocResp from 30:b5:c2:96:ab:5f (capab=0x431 status=0 aid=1)
[ 7685.644650] wlo1: associated
[ 7685.654816] IPv6: ADDRCONF(NETDEV_CHANGE): wlo1: link becomes ready
[ 768
I have the same problem on Asus Zenbook UX433FN, latest BIOS,FW. Running Ubuntu 18.04. I can also confirm this is not a systemd/startup-scripts issue. I'm testing undervolt (from PYPI) and haven't created a service yet at all. Values still persist.
A workaround is to call the script again with "zeroed" values:
undervolt --core 0 --cache 0 --uncore 0 ....Can you please adapt the systemd script to call this zeroing on Reset, Shutdown of the service?
This is exactly what I did - creating another script to zero out the values.
I can confirm with the Dell 7590 that the number persist after a reboot, but go away on a sleep/resume.
Dell XPS 15 7590 user here. Same here, offset values persist even at reboot. And no I did not make any systemd units yet. Anyone knows what's happening?
I'm pretty sure on my xps15 9560 i7-7700HQ, the processor is always undervolted in linux, even after reboot (and even after booting in windows, and booting back).
I noticed this when trying to update my RAM from 32GB 2400MHz to 64GB 2666MHz and my computer would crash upon boot at linux.
Personally, I like that the settings persist, but it was hard to undo the settings for the upgrade.
Hmmm I left my laptop powered off for over a day now and yes they're now back to 0. Sleeping and hibernating seems to reset the values, confirming @rianquinn's comment since we both have a 7590. Maybe this is a one-off, temporary issue? Or maybe just rebooting will retain the values and if you want to reset the undervolt you actually need to power down the device (not fully tested yet) but I think that's the case.
I applied -100mv core/cache offset using throttlestop in w11. If the offset value in linux doesn't go away after reboot, will the offset value add up and make my system unstable and crash?
