I can’t attach the entire log because text files are blocked from upload, and I can’t paste the entire log here because I get a 403 when I do that, but below is the summary output I got (no specific actions, just links to Git issues):
Explanations for your system
🚦 System had low hardware sleep residency
The system was asleep for 0:01:17.342560, but only spent 72.31%
of this time in a hardware sleep state. In sleep cycles that are at least
60 seconds long it's expected you spend above 90 percent of the cycle in hardware sleep.
🚦 rtc_cmos is not configured to use ACPI alarm
Some problems can occur during wakeup cycles if the HPET RTC emulation is used to
wake systems. This can manifest in unexpected wakeups or high power consumption.
For more information on this failure see:
https://github.com/systemd/systemd/issues/24279
🚦 System had low hardware sleep residency
The system was asleep for 0:01:16.896708, but only spent 71.64%
of this time in a hardware sleep state. In sleep cycles that are at least
60 seconds long it's expected you spend above 90 percent of the cycle in hardware sleep.
🚦 rtc_cmos is not configured to use ACPI alarm
Some problems can occur during wakeup cycles if the HPET RTC emulation is used to
wake systems. This can manifest in unexpected wakeups or high power consumption.
For more information on this failure see:
https://github.com/systemd/systemd/issues/24279
🚦 System had low hardware sleep residency
The system was asleep for 0:01:16.996060, but only spent 71.67%
of this time in a hardware sleep state. In sleep cycles that are at least
60 seconds long it's expected you spend above 90 percent of the cycle in hardware sleep.
🚦 rtc_cmos is not configured to use ACPI alarm
Some problems can occur during wakeup cycles if the HPET RTC emulation is used to
wake systems. This can manifest in unexpected wakeups or high power consumption.
For more information on this failure see:
https://github.com/systemd/systemd/issues/24279
🚦 System had low hardware sleep residency
The system was asleep for 0:01:17.009534, but only spent 71.66%
of this time in a hardware sleep state. In sleep cycles that are at least
60 seconds long it's expected you spend above 90 percent of the cycle in hardware sleep.
🚦 rtc_cmos is not configured to use ACPI alarm
Some problems can occur during wakeup cycles if the HPET RTC emulation is used to
wake systems. This can manifest in unexpected wakeups or high power consumption.
For more information on this failure see:
https://github.com/systemd/systemd/issues/24279
🚦 System had low hardware sleep residency
The system was asleep for 0:01:16.980107, but only spent 71.67%
of this time in a hardware sleep state. In sleep cycles that are at least
60 seconds long it's expected you spend above 90 percent of the cycle in hardware sleep.
🚦 rtc_cmos is not configured to use ACPI alarm
Some problems can occur during wakeup cycles if the HPET RTC emulation is used to
wake systems. This can manifest in unexpected wakeups or high power consumption.
For more information on this failure see:
https://github.com/systemd/systemd/issues/24279
How do I switch to the non-OEM kernel? I was on 22.04 and performed the installation steps, which I believe put me on the OEM kernel. I later upgraded through 23.10 to 24.04. I didn’t do anything further, so I didn’t take any steps to change the kernel
@Matt_Hartley maintains the instructions. I don’t know if he has proper upgrade instructions yet.
But the jist is that you would remove the OEM kernel and install the generic kernel which would get you a 6.8 based kernel. This will fix the rtc cmos issue, or if you want to keep your current kernel you can add a workaround to your kernel command line.
If there’s no other reason to switch kernels, I’d rather avoid doing so. Wrong kernel better than no kernel, and I don’t fully trust myself without instructions. If Matt provides them, I’ll follow the steps.
EDIT: I just sorta yolo’d an updated kernel (apt install linux-generic), and now I’m on 6.8.0-35-generic. The RTC issue is gone from the report (new report added to gist), but I do get a warning that the “kernel is tainted,” so I’m a bit concerned about that…
Tainted kernels can happen for a variety of reasons; but the most common one is proprietary or out of tree kernel module. For example virtual box can cause a taint. It might be totally fine; but the script can’t decide. You can try to run with --force to ignore it.
New report was added to the previous gist as another file (and the forum doesn’t want me to link it again).
And yeah, I checked dmesg and it seems to be related to amdkcl, which might have something to do with ROCm, but I don’t know how to investigate further. Either way, I’ll recheck sleep power consumption today and see if it improved.
Hopefully the new report looks good, and thanks again for all the help!
The only thing that stands out to me about the report now is that it takes quite a while to enter into suspend. Do you have a lot of stuff running in userspace? Particularly anything vram heavy?
Hopefully that’s all it is, and things perform well now.
Sorry for my delayed reply, but I’m not sure? Typically I’m only running Firefox, Discord (background), Steam (background), Sublime Text, and a terminal window that I’m using as a drop-down terminal. All total, ~7-10 GB.
WezTerm uses the GPU, and my open apps do have VRAM footprints, but it’s only about 700 MB total (of 4 GB allocated).
I am still seeing pretty high consumption–About 25% in 12 hours. Having said that, I need to run a test on my work computer to see if the sleep performance is actually better. Windows automatically suspends to disk after a certain amount of time on suspend-to-RAM, so I am starting to realize that I might just be making an invalid comparison since the computers I’m used to aren’t only suspending to RAM the entire time
I think what happened was that I upgraded to 24.04 (forced upgrade, there were reasons…), but doing that didn’t upgrade the kernel since I still only had the OEM kernel (6.5.0-1020-oem).
I was able to apt install to get the latest kernel (at the time), so I am currently on 6.8.0-35-generic, which I hope is satisfactory.
My GRUB doesn’t have any reference to the OEM kernel, so I think we should be good now