I5 Doesn't go to C states below C3 KDE Neon

Framework Laptop Linux
#1

I thought that ~5 hours on the battery is ok, but now I’ve noticed that the laptop should do about 10 hours.

I did everything related to idle power usage from this post:

And typical idle usage is 10W. Both powertop and turbostat report 0% on C6, C7 and C8, however, when the laptop is in sleep mode then C10 is used properly.

I also set PCIE_ASPM_ON_BAT=“powersupersave” in tlp.

I am using KDE Neon - 5.24
Kernel: 5.13.0-41-generic

This very sucks, now I know that I am getting half of the battery life.

Pls, help.

1 Like
#2

I have seen this happen when my SSD is not sleeping properly. Have you tried setting nvme.noacpi=1 in the kernel command line? (see Linux battery life tuning - #157 by MarkB).

If the above doesn’t work, you could try a tool from Intel which can diagnose problems with PC10. You have to clone it from github:

sudo apt install git
git clone https://github.com/intel/S0ixSelftestTool
cd S0ixSelftestTool
sudo ./s0ix-selftest-tool.sh -r on

It’s pretty good at diagnosing problems (at least it has told me in the past when my SSD was being weird).

Hope this helps.

1 Like
#3

I tried that, but I don’t get those posts. Should the line in “/etc/default/grub” look like that " GRUB_CMDLINE_LINUX_DEFAULT=“quiet splash; nvme.noacpi=1” "?

If yes then this does not work.

1 Like
#4

Well, yes. SSD is not going to sleep:

The PCIe bridge link power management state is:
0000:00:06.0 Link is in L0

The link power management state of PCIe bridge: 0000:00:06.0 is not expected.
which is expected to be L1.1 or L1.2, or user would run this script again.

But the question is WTF I am supposed to do about it?

This is so fucking annoying.

#5

I would lose the semicolon, so it’s

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvme.noacpi=1"

The whole procedure is:

  1. Edit /etc/default/grub
  2. sudo update-grub
  3. Reboot
  4. Check the change was applied using cat /proc/cmdline
2 Likes
#6

cat cmdline shows correctly that “nvme.noacpi=1”

“s0ix-selftest-tool.sh” once says that SSD is in L0 and once that ist is in L1.2, regardless of nvme.noacpi=1

What’s next?

(This forum is broken. I was fighting with error 403 that prevented me from posting reply for like a 30mins. Someone F! fix this!!!)

#7

Well, that’s good that the disk can sometimes get into L1.2. You should check to see if any process is doing lots of disk I/O: try something like “iotop” or “atop” (I use “atop”… press ‘d’ to see disk I/O).

Or, you could try logging out of KDE and entering the console with Ctrl+Alt+F3. Then try the s0ix-selftest-tool.sh there. If it looks better, that means the something in your KDE session is causing the problem. Ctrl+Alt+F1 (or sometimes Ctrl+Alt+F7 or Ctrl+Alt+F2) to get back to graphical login.

1 Like
#8

I did all my testing now out of the console to exclude Plasma and stuff.

I manually started TLP and powertop --auto-tune.
Powertop showed all good.

S0ixSelftestTool still failed and I’ve noticed that it shows that the drive is in L0 only when I run it for the first time. After that it always shows L1.2.

atop shows that everything is fine. In Terminal everything is usually @ 0, with atop being at the top of the list.

CPU still stays @ C3 and C6 and does not go to C7, C8, C9, or C10.

I am gonna download the newest ISO of KDE Neon and Ubuntu and boot them from USB and see what happens there.

Thx for help @jubnut

#9

Update:

On USB boot everything works fine until the device goes to sleep, after awakening, it is unable to go below C3 and that’s regardless of PCIE settings, TLP, and powertop, while on SSD boot I am unable to make it below C3.

I really don’t want to distro hop or reinstall the system, but it seems that I have to install Neon on a separate drive, fix the problem after going to sleep, and then reinstall my main os, or distro hop.

#10

The SSD can still cause problems even when running the OS from an USB stick (I confirmed this using S0ixSelftestTool on a Void Linux live USB).

The USB boot should give you the option of editing the kernel command line before booting (eg. on Ubuntu you can press ‘e’ on the boot menu). Then you can try adding nvme.noacpi=1 to the USB boot.

Did it print a message on failure?

#11

It just says that “PC10 wasn’t achieved”, but neither of the states below C6 were achieved.

I was ignoring the BIOS update from 3.06 to 3.07 because their Change Log says that they mostly fixed some charging issues, but after the BIOS update I am getting the same results in USB boot and SSD boot and now S0ixSelftestTool clearly says that after awakening from sleep SSD is stuck in L1 (not L1.1 or L1.2).

I removed TLP, powertop, and set grub to default for testing purposes before, so now I will set those things up again and if it does not help then I will change the sleep mode or just replace it with hibernation.

I think it should be noted in the tutorial that BIOS 3.06 is fucked.

#12

What is the make and model of the SSD?

#13

WD SN580, bought with the laptop.

Update:
After BIOS update and setting nvme.noacpi=1 in grub, everything was perfect. CPU hit C8 and C10 after and before sleep, but I decided to install tlp and powertop and now I am getting this from S0ixSelftestTool:

The deeper CPU Package C-state is available after
PCI devices LTR ignore,please investigate the potential IP LTR issue.

Without LTR ignore it’s stuck again @ C3. (Yes, I set PCIE_something=powersupersave in TLP) Removing TLP and powertop didn’t fix it.

#14

I have the same drive, it hits c10. I am running Manjaro Gnome and powertop. So the good news is that it should work. The bad news is that you’re still trying to determine what is preventing the system from hitting that state. Finally, this may not be relevant to your issue, but there is a firmware update for the drive - you have to use windows to update it.

#15

Well, I got this, but either TLP or powertop fucked me.

Does anyone know what to do with this message from S0ixSelftestTool and how to fix it?:
The deeper CPU Package C-state is available after
PCI devices LTR ignore,please investigate the potential IP LTR issue.

#16

This is a stupid piece of trash. Frame.work did really SCREWED UP. I don’t know whether any of the devs gonna see that, but I believe I have that stupid temporary audio codec and using it was a mistake!

It sounds bad, it doesn’t support energy-saving, and it creates tons of high pitch noise when you turn it off, and at the top of that, IT WAS CAUSING ALL THE ISSUES WITH CPU AND ENERGY STATES. As soon as I ignore LTR from that chip, the CPU starts working correctly, but the audio gets unbearably choppy.

I want that Realtek!

#17

What the hell I am supposed to do now!

#18

For those with the same problem:

#19

xses@xses:~$ sudo cat /sys/kernel/debug/pmc_core/ltr_show

XHCI LTR: RAW: 0x8990 Non-Snoop(ns): 0 Snoop(ns): 409600

HD_AUDIO LTR: RAW: 0x883b Non-Snoop(ns): 0 Snoop(ns): 60416

#20

sudo su
echo 9 > /sys/kernel/debug/pmc_core/ltr_ignore

I was just echoing one by one and I assume that 9 is HD_AUDIO, because it correlates with the chopines of the audio.

I’ve cheacked on the motherboard and yes, I’ve that fucking 92HD95B