Diagnostics on battery utilisation?

[harun911]

Hello everybody, I have a couple of questions actually. The first one question is for everyone. I was wondering how many hours of use before complete depletion everyone is getting on their chromeOS install. I have a feeling that my battery is depleting faster then it should be.

Which brings me to my second question. Is their something similar to Powertop or TLP in someway available for ChromeOS? A program which shows me how much battery every app/process/service uses. I already discovered the 'battery_test' command for crosh which gives a percentile discharge value based on 300 seconds of Idle time. My battery_test command returned me 2.26% for every 5 min. of idle time... Which I think is way too high, especially considering the computer was idle..

My third question: is it possible to see somehow on what clockspeed ChromeOS is running? It could be that the CPU isn't correctly dropping in clockspeed to conserve power when not being actively used.

Specs of the laptop in question: Xiaomi Mi Notebook 13.3 (2016 model I think?)

8gb 2133mhz ram Intel i5 6200u (with Intel HD 520 graphics) 256gb nvme drive + 512gb m2. sata Nvidia Geforce 940MX 40W Battery (with a health of about 79.07%). Used with 50% brightness on the screen (with the use of advanced_als kernel parameter.)

Used recovery: rammus r81 Used brunch version: r81 stable. Crostini is enabled.

[sebanc]

Hi,

Indeed it is a good idea to open a discussion on battery life which is probably not as great as it could be.

However, it's important to make sure we discuss things on the same basis which means always including information on:

• the recovery image you have used as ipu3 camera recovery images cause a battery drain due to the camera service running in an endless loop in the background (ipu3 recovery images are notably nocturne, atlas, nautilus, soraka).
• the screen brightness setting you use (default or modified) as screen brightness is by default very high in chromeos and it may greatly impact results.
• the use of crostini: xalexis from telegram croissant group identified that he gets 1.5 hours more screen on time of a full charge with crostini disabled (but that may depend of the packages you have installed)
• The presence of a dual gpu.

Well, that's all I can think of right now, don't hesitate to share your findings / tips here :)

[harun911]

@sebanc thanks for your response. I've updated my initial post with the missing requirements. The fact that you're mentioning dual gpu so specifically got me wondering. I think I remember reading in another issue that you mentioned, that chrome OS could never run on a secondary gpu. So could that mean, that my installation is currently using the on-board gpu, while the dedicated gpu is still draining power even when it's not usable? I remember I needed to disable nvidia graphics on Linux through a config for powertop. Could something similar be at play here?

UPDATE: I added the kernel parameter "module_blacklist=nouveau" in the grub config and that seems to have fixed my rapid depletion problem. I get a discharge percentage of around ~0.94 to 0.99% now with the "battery_test" command in crosh, which seems more logical to me. My recall of my laptop's battery health was incorrect, so I updated that in my initial post. With a battery health of around 0.79%, I get around 6.5 to 7 hours screen-on time. Which is totally fine for me. Without the parameter it was around 2.5 to 3.5 hours.

[sebanc]

Nice to see you were able to fix the issue with the dual gpu. My understanding regarding dual gpu power saving is that it depends on a combination of BIOS internal behavior + kernel drivers + userspace components, as such:

• For some, dgpu is disabled by default and nothing specific is needed,
• Others might need to blacklist the dual gpu kernel module as you did (but it does not work for everyone, some dgpu remain active even when the driver is blacklisted),
• Others need to force the dgpu power/control sysfs attribute to auto.

[harun911]

Ah understood, so it will depend on someone's specific configuration what will work. Maybe its worth mentioning, that this laptop probably uses Nvidia Optimus technology to spread the load between the two graphic cards. The Nvidia Optimus uses the iGpu as a proxy though to reach the dGpu.

I have noticed something odd again though, could it be that the dGPU gets reactivated after the laptop goes to sleep? I did another 'battery_test' after waking the laptop from sleep and the discharge percentage seems to have gone up again, back to around what it first was ~+2.2%. After rebooting the machine and doing another 'battery_test', it seems to have dropped back again to around 1%.

Update: I did a double test, just to be sure. And I can confirm that the battery discharge percentage is indeed back to the same value as when not giving the 'blacklist_module=nouveau' kernel parameter. Waking up from sleep somehow triggers the dGpu to consume power again. Is there a way to completely disable the dGpu, so also when waking up from sleep?

[sebanc]

Indeed, it is totally possible that the dgpu is put back to D0 after resume. Maybe this could be fixed by setting the "power/control" sysfs attribute to auto (which could be automated in a udev rule).

Could you use "sudo lspci" to identify your nvidia gpu bus number and then post the output of "udevadm info /sys/bus/pci/devices/" ?

[harun911]

Here you go @sebanc , thanks again.

[sebanc]

Well, the udev rule that I included (in /lib/udev/rules.d/99-nvidia_pm.rules) already applies to your device so that's not it.

Could you try to remove "module_blacklist=nouveau" and add "nouveau.runpm=1" to the kernel command line instead ?

Also, try "nouveau.modeset=0" without "module_blacklist=nouveau" if it does not work.

[harun911]

I double tested both arguments, and they both show the same behaviour as the 'blacklist_module=nouveau' argument. On first boot the dGpu is succesfully turned off but when resuming from sleep, the dGpu starts to consume power, cutting the remaining battery time in nearly half.

Is the

Maybe this could be fixed by setting the "power/control" sysfs attribute to auto

still a thing to try?

[sebanc]

Could you try to run "echo 1 | sudo tee /sys/bus/pci/devices/0000:01:00.0/remove" after initial boot ? and see if after suspend it still powers back on.

[harun911]

I ran that command after the initial boot and put the laptop to sleep. Unfortunately, it still powers up the dGpu when resuming from sleep. The discharge percentage is still around ~2.1%. :(

[sebanc]

Actually even though that's not intuitive for me, it seems the correct use of runpm parameter to disable the dgpu is "nouveau.runpm=0" and not "nouveau.runpm=1" as I mentioned previously. Could you try it ?

Also could you try to add both "nouveau.modeset=0 nouveau.runpm=0"

[harun911]

Unfortunately :( exactly the same behaviour for both arguments. Initial boot dGpu is powered off. Resume from sleep it somehow is back on.

[sebanc]

Ok, I wanted to avoid it but I am out of ideas, could you try this ? https://wiki.archlinux.org/index.php/Hybrid_graphics

Do you need help to build the dkms from https://github.com/mkottman/acpi_call ?

[harun911]

I can definitely try it. Just tell me the correct order of instructions to follow. You're saying I need to build a dkms first? How do I do that? And after building the dkms, I perform the sh script which attempts to find a Gpu bus and send an off signal to it?

[sebanc]

1) Install chromebrew 2) Download the code from https://github.com/mkottman/acpi_call 3) "cd" into the acpi_call source directory and run "make" 4) copy the generated acpi_call.ko to /lib/modules 5) run "insmod /lib/modules/acpi_call.ko 6) Download and run the script with "sudo": "https://raw.githubusercontent.com/mkottman/acpi_call/master/examples/turn_off_gpu.sh" 7) run "echo '' > /proc/acpi/call", suspend and see if worked.

Tell me if you are stuck somewhere

[harun911]

Alright, thank you Sebanc. I'll grab a quick bite and dive right into it straight after.

Update: @sebanc

I get an error when running the 'make' command.

Update 2:

I found a fork of the acpi_call repo by biji. I downloaded that code and executed 'make', so far it seems no errors.

This is a screenshot of the result of the 'make' command with the fork of biji:

Update 3: Insmod command not found :/

Update 4: Okay, with sudo the command got recognized, but now I get the message:

insmod: ERROR: could not insert module /lib/modules/acpi_call.ko: Unknown symbol in module

I'm stuck :(

[sebanc]

Indeed the repo in the arch wiki is really outdated and the warning you get on the other one you tried is more an error than a warning.

Could you try this repo : "https://github.com/nix-community/acpi_call" ? It seems up-to-date

If it does not work, I will try to find one that compiles correctly against kernel headers tomorrow.

[harun911]

Same error with the nix-community repo:

chronos@localhost / $ sudo insmod /lib/modules/acpi_call.ko insmod: ERROR: could not insert module /lib/modules/acpi_call.ko: Unknown symbol in module

Thanks again, sebanc. Your help is more then greatly appreciated.

Edit: I came across a thread of a couple of other people discussing the same subject but for CloudReady. Is there any info mentioned here that could be of any use? https://neverware.zendesk.com/hc/en-us/community/posts/360037962254-Reducing-Discrete-graphics-wastage-adding-acpi-call-as-kernel-module-or-other-workaround

[sebanc]

I had a look at the cloudready thread but they generally tried the same thing as us and they don't exactly say how the issue was fixed but I would guess through cloudready nvidia userspace drivers (which are not present in chromeos).

So let's continue this, to build "https://github.com/nix-community/acpi_call", you will need to add the below line in the Makefile just after the line "obj-m := acpi_call.o".

CFLAGS_acpi_call.o := -fno-stack-protector

[harun911]

Heya Sebanc, with that added line I was able to build the acpi_call.ko file and use the insmod command to insert it in the kernel module. When I tried the gpu_turn_off.sh script however, all of them return back 'failed'...

Edit: I found out that my laptop is listed on the arch wiki: https://wiki.archlinux.org/index.php/Xiaomi_Mi_Notebook_Air_13.3_(2016)

They talk about using bbswitch to permanently disable the dGpu. Is it possible to use bbswitch in someway with brunch? Would it be possible with chromebrew?

[sebanc]

Yes, the bbswitch module should work exactly the same as the acpi_call module:

• Download the source
• run make
• copy the module to /lib/modules/
• run "insmod /lib/modules/bbswitch.ko load_state=0 unload_state=0" (according to the arch wiki)

[harun911]

I have managed to build the source, insert the module and run the command for bbswitch. But unfortunately it does not make any difference. It feels like the commands are not reaching the dGpu or something. :(

Would it work to load PowerTOP (https://github.com/fenrus75/powertop) as a module and insert it in the same way as the other modules..? just to debug some more

Because I don't fully understand, bbswitch reports that the dGpu is off even after sleep. But after sleep the laptop starts consuming more battery as opposed to before it went to sleep. I can literally see the remaining battery drop to half. The last line in the dmesg reports: "pci 0000:01:00.0: Refused to change power state, currently in D3"

Is it possible, that something else then the dGpu is starting to consume lots of power after waking up from sleep?

[sebanc]

You can try to build powertop (it's a program not a kernel module but the process is more or less the same). However, i am not sure chromebrew has the right dependencies, I will try to build it and see if it is possible.

For now, I still think that the issue is related to the dgpu as it's normal for all other devices to be powered on. Could you post the output of: "udevadm info /sys/bus/pci/devices/000:00:1c.0" ?

[harun911]

Of course. I'm guessing you missed a 0 there right?

Thanks for the PowerTop part though, I tried to build it with chromebrew, but it could not find a makefile. And because of my lack of knowledge on that part, I gave up trying to build it.

[sebanc]

Indeed I forgot a 0, that's exactly the info i was looking for. Could you try replacing the content of /lib/udev/rules.d/99-nvidia_pm.rules with:

ACTION=="add|change", SUBSYSTEM=="pci", ENV{PCI_CLASS}=="30200", ATTR{vendor}=="0x10de", ATTR{power/control}="auto"
ACTION=="add|change", SUBSYSTEM=="pci", ENV{PCI_CLASS}=="60400", ATTR{power/control}="auto"

[harun911]

I've replaced them and rebooted. Then did a battery test after cold boot and one after resuming from sleep. Unfortunately no success. Battery discharge after sleep is even a tad bit higher then before the edit ~2.25 / 2.3%

@sebanc Do you have any other ideas? Did you perhaps get a chance to look at powertop? I think it might be useful for debugging more issues listed on here.

[jhsrennie]

If this is still of interest I used Brunch r83 k4.19 testing 20200528 on a Dell Inspiron with an Nvidia MX150 and I also got poor battery life. I added "module_blacklist=nouveau" in the grub config and this fixed the problem so the battery life is now as good as on Windows.

I found the same happened on Mint 19.3. If I used the Nouveau drivers I got poor battery life on Mint. I had to install the Nvidia proprietary drivers and disable the MX150 to get battery life as good as on Windows. I suspect the Nouveau drivers automatically use the Nvidia GPU without giving you an option to use the Intel GPU instead.

I will test what happens after sleep ...

[jhsrennie]

Further to the above, suspending does not cause the power usage to change. I tried suspending for a minute then suspending for half an hour in case the duration made a difference, and the power drain remained about 10% an hour. This matches what I get in Windows and Linux.

[sebanc]

In the end, this issue became very specific so I replaced it with #357.