You are not logged in.
since kernel 6.9 was released, my laptop has been getting ever so slightly warm and draining battery during sleep. nothing else has changed, and it's true with every kernel starting with 6.9.0. reverting to 6.8.9 resolves it.
i am running arch on an Asus Zenbook 14 (UX3405MA, BIOS UX3405MA.305) with the new intel core ultra chipset. it's interesting because 6.9 is supposed to include performance upgrades for these new intel chips.
using systemd for suspend, s2idle state. deep sleep has never worked as it doesnt wake properly (maybe false advertisement from firmware) and s2idle has been excellent in terms of battery life on every kernel from 6.6-6.8.
journalctl has not revealed anything obvious. the logs look nearly identical. test procedure was putting the laptop to sleep for 5 minutes then waking and retrieving logs. here are links in case anyone has a keener eye:
6.8.9 log: https://0x0.st/Xb4A.txt
6.9.3 log: https://0x0.st/Xb4u.txt
any recommended next steps for troubleshooting?
Last edited by electronarchy (2024-06-24 18:00:37)
Offline
I have the same problem. Same CPU.
My machine is an Asus Zenbook 14 oled.
Following this thread.
Had this problem since the first 6.9 kernel. Both stock and zen.
Edit: It still works fine on the 6.8 kernel. Tested this a few days ago.
Last edited by tho068 (2024-06-11 15:12:57)
Offline
Try to disconnect and rfkill the wifi before suspending and while counter-intuitive to limit the c-states, https://wiki.archlinux.org/title/Intel_ … Intel_CPUs
Ftr, b/c of the 5 partitions, there isn't a parallel windows installation?
Downgrading the kernel restores the previous behavior?
Online
Yes, that worked. Disconnecting from wifi and running rfkill before suspend.
Offline
That's probably a "feature", not a bug…
https://wiki.archlinux.org/title/Power_ … leep_hooks
Online
Damn, I spoke too soon. The laptop definitively gets less hot during suspend, but it does not work still.
I found a debug utility for s2idle for intel processors and tried running it. Here is the ouput for the 6.8 kernel
---Check whether your system supports S0ix or not---:
Low Power S0 Idle is:1
Your system supports low power S0 idle capability.
---Check whether intel_pmc_core sysfs files exit---:
The pmc_core debug sysfs files are OK on your system.
---Judge PC10, S0ix residency available status---:
Test system supports S0ix.y substate
S0ix substate before S2idle:
S0i2.0 S0i2.1 S0i2.2
S0ix substate residency before S2idle:
0 0 0
Turbostat output:
15.172585 sec
CPU%c1 CPU%c6 CPU%c7 Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 SYS%LPI
1.15 62.28 36.39 8.81 0.03 0.06 0.00 0.76 0.00 82.42 84.89
0.37 99.22 0.00
0.28 99.44 0.00
0.36 99.25 0.00
0.25 99.45 0.00
0.25 99.50 0.00
0.40 99.28 0.00
0.39 99.35 0.00
0.24 99.52 0.00
1.93 0.61 95.74
2.46
2.30 0.49 96.03
2.47
1.55 0.66 97.30 8.81 0.03 0.06 0.00 0.76 0.00 82.42 84.89
1.49
0.64 0.17 98.62
0.76
3.68 0.12 95.80
3.61
0.49 0.18 98.74
0.82
0.22 99.61 0.00
0.25 99.57 0.00
CPU Core C7 residency after S2idle is: 36.39
GFX RC6 residency after S2idle is:
CPU Package C-state 2 residency after S2idle is: 8.81
CPU Package C-state 3 residency after S2idle is: 0.03
CPU Package C-state 8 residency after S2idle is: 0.76
CPU Package C-state 9 residency after S2idle is: 0.00
CPU Package C-state 10 residency after S2idle is: 82.42
S0ix residency after S2idle is: 84.89
S0ix substate after S2idle:
S0i2.0 S0i2.1 S0i2.2
S0ix substate residency after S2idle:
0 8204 12869231
S0ix substates residency delta value: S0i2.0 0
S0ix substates residency delta value: S0i2.1 8204
S0ix substates residency delta value: S0i2.2 12869231
Congratulations! Your system achieved the deepest S0ix substate!
Here is the S0ix substates status:
Substate Residency
S0i2.0 0
S0i2.1 8204
S0i2.2 12869231
Edit: I am going to reboot and run the same command with the 6.9 kernel.
Edit: Here is the output with 6.9
---Check whether your system supports S0ix or not---:
Low Power S0 Idle is:1
Your system supports low power S0 idle capability.
---Check whether intel_pmc_core sysfs files exit---:
The pmc_core debug sysfs files are OK on your system.
---Judge PC10, S0ix residency available status---:
Test system supports S0ix.y substate
S0ix substate before S2idle:
S0i2.0 S0i2.1 S0i2.2
S0ix substate residency before S2idle:
0 0 0
Turbostat output:
15.651602 sec
CPU%c1 CPU%c6 CPU%c7 GFX%rc6 Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 SYS%LPI
7.61 61.65 29.44 373.64 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
2.16 97.28 0.00
1.24 98.46 0.00
1.15 98.57 0.00
1.73 97.93 0.00
1.08 98.58 0.00
1.28 98.37 0.00
0.95 98.77 0.00
0.59 99.13 0.00
97.53 0.00 0.00
6.12 0.07 92.11
7.27
6.54 0.02 92.94 373.64 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
6.50
3.13 0.01 96.35
3.29
3.87 0.04 95.71
3.89
5.43 0.01 93.89
5.61
0.21 99.53 0.00
0.22 99.57 0.00
CPU Core C7 residency after S2idle is: 29.44
GFX RC6 residency after S2idle is: 373.64
CPU Package C-state 2 residency after S2idle is: 0.00
CPU Package C-state 3 residency after S2idle is: 0.00
CPU Package C-state 8 residency after S2idle is: 0.00
CPU Package C-state 9 residency after S2idle is: 0.00
CPU Package C-state 10 residency after S2idle is: 0.00
S0ix residency after S2idle is: 0.00
Your system did not achieve PC2 state or PC2 residency is low:
0.00
---Debug no PC2 residency scenario---:
modprobe cpufreq_stats failed
Loaded 0 prior measurements
Cannot load from file /var/cache/powertop/saved_parameters.powertop
File will be loaded after taking minimum number of measurement(s) with battery only
RAPL device for cpu 0
RAPL Using PowerCap Sysfs : Domain Mask d
RAPL device for cpu 0
RAPL Using PowerCap Sysfs : Domain Mask d
Devfreq not enabled
glob returned GLOB_ABORTED
Cannot load from file /var/cache/powertop/saved_parameters.powertop
File will be loaded after taking minimum number of measurement(s) with battery only
Leaving PowerTOP
Turbostat output:
15.226522 sec
CPU%c1 CPU%c6 CPU%c7 GFX%rc6 Pkg%pc2
6.56 61.94 30.14 527.47 0.00
0.84 98.94 0.00
0.91 98.83 0.00
0.71 99.00 0.00
0.77 98.98 0.00
0.90 98.88 0.00
1.14 98.59 0.00
0.72 99.04 0.00
0.46 99.31 0.00
99.23 0.00 0.00
2.92 0.01 96.75
2.62
4.57 0.02 94.92 527.47 0.00
4.65
1.85 0.02 97.78
1.95
2.86 0.05 96.70
2.99
3.59 0.00 96.09
3.63
0.20 99.59 0.00
0.20 99.65 0.00
CPU Core c6:30.14
GFX rc6:527.47
Your CPU Core C6 residency is available: 30.14
Your system Intel graphics RC6 residency is available,
please double confirm whether the latest Linux Kernel and the latest
BIOS are in use,
some hidden kernel or FW issues are beyond this script ability to isolate
Your system CPU Core C6 and Intel graphics RC6 is OK,
then this script cannot handle the exception which IP blocked PC2 state.
If your HW is unstable, suggest to re-run this script.
Any other suggestions? I will try to experiment with the c-states boot options some time during the next few days.
Last edited by tho068 (2024-06-11 19:35:03)
Offline
CPU Core C7 residency after S2idle is: 29.44
GFX RC6 residency after S2idle is: 373.64
CPU Package C-state 2 residency after S2idle is: 0.00
CPU Package C-state 3 residency after S2idle is: 0.00
CPU Package C-state 8 residency after S2idle is: 0.00
CPU Package C-state 9 residency after S2idle is: 0.00
CPU Package C-state 10 residency after S2idle is: 0.00
S0ix residency after S2idle is: 0.00
Your system did not achieve PC2 state or PC2 residency is low:
0.00
Was that already w/ c-states limited to "1"?
Online
CPU Core C7 residency after S2idle is: 29.44 GFX RC6 residency after S2idle is: 373.64 CPU Package C-state 2 residency after S2idle is: 0.00 CPU Package C-state 3 residency after S2idle is: 0.00 CPU Package C-state 8 residency after S2idle is: 0.00 CPU Package C-state 9 residency after S2idle is: 0.00 CPU Package C-state 10 residency after S2idle is: 0.00 S0ix residency after S2idle is: 0.00 Your system did not achieve PC2 state or PC2 residency is low: 0.00
Was that already w/ c-states limited to "1"?
No, it is the same setup for both kernels. No additions to the kernel boot params.
Offline
Hi guys, I have the same problem here Same laptop: Zenbook OLED UX3405M. I also didn't expect it to be the 6.9 Kernel, as it had performance improvments for the ultra chipset.
Batterydrain on s2idle with 6.9 is almost as it wouldn't even go to sleep for me, and the laptop gets even warmer than in actual use. Downgrading to 6.8 solves it. Deep sleep does work, but the laptop won't ever wake up again.
I don't exactly know what to do here. I can post any information needed if someone has an idea
Offline
Same laptop, same issue. I noticed this also affects power usage when on and idle, I used to idle at <3W and now I can hardly get below 8.
In addition, of course, s2idle is broken.
I've reverted 5.8.9 for now but plan on bisecting the kernel this weekend to find the culprit, I'll update this post if I find any news.
Offline
https://wiki.archlinux.org/title/Genera … mpty_posts
Try to disconnect and rfkill the wifi [edit: reported to have *some* benefit] before suspending and while counter-intuitive to limit the c-states, https://wiki.archlinux.org/title/Intel_ … Intel_CPUs
Online
this issue appears to be resolved with the release of kernel 6.9.4. my laptop has been asleep for over 4 hours and woke up with 100% battery.
this is also odd, because I built an rc of 6.10 last week to test, and that had the same battery drain issue.
can anyone else verify that this is resolved for them with 6.9.4?
Offline
this issue appears to be resolved with the release of kernel 6.9.4. my laptop has been asleep for over 4 hours and woke up with 100% battery.
this is also odd, because I built an rc of 6.10 last week to test, and that had the same battery drain issue.
can anyone else verify that this is resolved for them with 6.9.4?
I can confirm that the debug tool says that it works in 6.9.4
S0ix substates residency delta value: S0i2.0 54412
S0ix substates residency delta value: S0i2.1 10157
S0ix substates residency delta value: S0i2.2 39877652
Congratulations! Your system achieved the deepest S0ix substate!
Here is the S0ix substates status:
Substate Residency
S0i2.0 5962780
S0i2.1 26527009
S0i2.2 4072423989
Offline
ok, so this has been resolved in 6.9.4, and still good in 6.9.5.
should I mark this as solved? or do we still need to figure out where this went wrong in case the issue comes back with future kernels?
Offline
You could bisect between 6.9.3 and 6.9.4 but it's probably more reasonable to spend time on bisecting regressions than on bisecting what might maybe possibly at some point in the future become a regression again. Perhaps.
SInce there's nothing left to do and an answer for users hitting the problem (if there still some), please mark the thread as solved, yes.
Online