Remember the old style of Notebook batteries that had to be cycled before first use? Do that with a brand new Lithium-ion battery and watch it die! This happened when the service I worked for purchased new batteries for a Toshiba notebook.
Chris Titus Tech has done a great YouTube video on how to prolong battery life on a GNU/Linux notebook for up to 12 hours!
Sorry for the delayed reply and thanks everyone for your input!
So this method doesn't seem to work with my model, unfortunately. There must be something deeper here but I have no idea how I would go about fixing this. Entering the suggested command returns:
# echo deep >/sys/power/mem_sleep
bash: echo: write error: Invalid argument
I'm relatively new to Linux, but I assume this is my computer's way of telling me it doesn't know what I'm asking. After spending an hour reading about the new "modern standby" technology (which I guess isn't actually "suspend" so that the computer continues to drain battery as if it were in use) it boggles my mind why Lenovo or anyone else would implement this, or at least why they would make it involuntary.
Any idea how I might go about reversing this, enabling the "deep" or S3 function?
Thanks again!
I came across this guide trying to find more information that may be helpful:
It is comprehensive and detailed. And unsurprising... I already knew that Lenovo dislikes Linux...
Oh nice find, thanks! Gonna dive in right now...
I followed the instructions, rebooted, and it didn't work. Not sure where I went wrong. Most of the commands seem to have gone through (or so I assume since there was no error or even any output in most cases).
The only exception might be the very last step at the end (the "Overriding the DSDT" section). The command sudo update-initramfs -k all -u returned the following:
update-initramfs: Generating /boot/initrd.img-6.0.9-060009-generic
W: Possible missing firmware /lib/firmware/i915/tgl_guc_69.0.3.bin for module i915
W: Possible missing firmware /lib/firmware/i915/adlp_guc_69.0.3.bin for module i915
W: Possible missing firmware /lib/firmware/i915/skl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/glk_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/cml_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/icl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/ehl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/dg1_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/tgl_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/adlp_guc_70.1.1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/dg2_guc_70.1.2.bin for module i915
W: Possible missing firmware /lib/firmware/i915/adlp_dmc_ver2_16.bin for module i915
W: Possible missing firmware /lib/firmware/i915/dg2_dmc_ver2_06.bin for module i915
update-initramfs: Generating /boot/initrd.img-5.15.0-58-generic
update-initramfs: Generating /boot/initrd.img-5.15.0-56-generic
Edit: I should note I also didn't complete the last part
"patching the kernel" since I don't think I use one?
This is a normal warning and only means that there is a "placeholder" in the kernel for firmware additions for the future. Since they are not yet actually present, the system concludes that it is possible that some firmware is missing. Please see here:
There is no need ; you are not using a manually patched kernel.
Hmmm... I am stumped. Let's keep looking...
It is not really on purpose lol. But Lenovo is pure aiming for the Asian market, China mostly. So that means like other brands such as, Acer, Packard Bell and some exotic Brands from Taiwan are not really aiming at all for being compatible with Linux on the Western market (such as Europe and America/ Canada).
So besides the Golden Standard Lenovo has with the Thinkpads everything else is actually Windows, Microsoft only. Consumer series of Lenovo are much away from the industrial standards IBM has set up years ago.
You know the drill: cheaper, exclusiveness, and so on ......
Sadly they prompt these computers as well in the West, but the real intentions behind it is aiming for the Chinese, Taiwan, ...., market.
I've heard that the most recent Thinkpads are now as well off industrial standard.
But this is a rumour.
The link suggests that 5.8 kernel works while 5.11 does not. It does not mention 5.15... so, just in case:
sudo apt install linux-headers-5.8.0-63-generic linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic linux-image-5.8.0-63-generic
Reboot > Advanced Options > Select to boot from the 5.8 Kernel
The 5.8 kernel can be tested to see if you get better results on it.
Strangely, my trackpad/mouse is completely unresponsive when I boot into 5.8, and there's also no way to connect to WiFi. (Not that I would be able to click on it anyway, but the network settings icon disappears from the taskbar.) Unfortunately I don't have a way to try connecting via cable, so I can't run any upgrades or even install net-tools from terminal.
Seems like my only route would be to try the unlock BIOS method. Or is this a bad idea?
Perhaps a safer option would be this tool which apparently allows you to boot an alternative BIOS from a flash drive. It was suggested here in the "issues" section of the yoga-bios-unlock github linked to in the post above.
Edit: Just realized both these methods (the BIOS unlocking you linked to and the boot-from-USB method) are specified for the Yoga AMD models. My model is Intel Evo. Not sure if that matters?
Edit #2: Okay, tried the boot-from-USB method. I was able to boot the main BIOS menu, but the "Device Manager" screen doesn't show any devices. Makes sense, I suppose... there are no AMD devices here to be found, after all. Should I assume the other unlock BIOS method you linked to would also not work for Intel?
i agree with this. I was actually not even looking at the BIOS unlock method, but rather:
Re execute the command, there is a typo.
Put a space after > or it won't work, after you correct the typo reboot, you'll solve that.
At least with my cousin's laptop it did.
Well spotted, eagle eye.
Did you know that I see only with an eye?
You're the kindest person ever! Have a nice day/night! (Here it's night.)
I suffered this behavior with ThinkPad which consists of two parts actually,
As of now, the last issue has been completely solved while the first one has been partially solved i.e. unexpected drain while in shutdown state!! (still observing anyway)
Give it a try with Yoga and see.
add-apt-repository ppa:linrunner/tlp
apt update && apt upgrade -y
apt install tlp tlp-rdw
as per developer READ MORE the below package available on 20.04 repo causes errors and it is advised to download it manually from 22.04 repo and install it,
dpkg -i acpi-call-dkms_1.2.2-1_all.deb
After finish, proceed with,
tlp-stat -s
tlp recalibrate BAT0
Let me know, if working well with modern Lenovo models, I test it and it works good with old models.
Thanks everyone foe the input!
@Aravisian: I guess the DSDT method only works on 5.8. Unfortunately since 5.8 is unusable on my laptop I think I'm out of luck here 
. It's getting pretty out of hand, too. Yesterday I put my laptop i suspend and put in my backback. Couple of minutes later it heated up to the point where I could hardly touch it--apparently carrying out some intensive process!
Thank you @ Nicolaco_08 for the suggestion, and good catch! Unfortunately, even after adding the space, the same error is returned:
echo deep > /sys/power/mem_sleep
bash: echo: write error: Invalid argument
Still not sure what that means...
vCentre Thank you for the suggestion! tlp recalibrate BAT0 fails for some reason, returning:
Setting temporary charge threshold for all batteries:
conservation mode = 0 (no change)
Error: battery discharge/recalibrate not available.
That looks like an acpi_call issue.
Possible solutions are to patch acpi_call or not use acpi_call, at all.
Here is how to patch it:
This should work on Zorin OS 16.
To disable it- just stop at the portion where you remove the acpi_call package.
please check out using tlp status
I assume that you're using Zorin v16.2 Core having kernel 5.15 with acpi-call-dkms_1.2.2 package.
The above working fine on my side.
root@ThinkPad:~# tlp-stat -s
The output of the above command is,
--- TLP 1.5.0 --------------------------------------------
+++ System Info
System = LENOVO ThinkPad T420s 41717FU
BIOS = 8CET66WW (1.46 )
OS Release = Zorin OS 16.2
Kernel = 5.15.0-60-generic #66~20.04.1-Ubuntu SMP Wed Jan 25 09:41:30 UTC 2023 x86_64
/proc/cmdline = BOOT_IMAGE=/boot/vmlinuz-5.15.0-60-generic root=UUID=a43123ae-aeb2-4ce8-b45d-afac270f0572 ro quiet splash mce=off loglevel=3 vt.handoff=7
Init system = systemd v245 (245.4-4ubuntu3.19)
Boot mode = UEFI
+++ TLP Status
State = enabled
RDW state = enabled
Last run = 07:52:31 PM, 300 sec(s) ago
Mode = AC (manual)
Power source = AC
also check out the below,
root@ThinkPad:~# tlp-stat -b
The output of the above command is,
--- TLP 1.5.0 --------------------------------------------
+++ Battery Care
Plugin: thinkpad
Supported features: charge thresholds, recalibration
Driver usage:
* natacpi (thinkpad_acpi) = active (charge thresholds)
* tpacpi-bat (acpi_call) = active (recalibration)
* tp-smapi (tp_smapi) = inactive (kernel module 'tp_smapi' not installed)
Parameter value ranges:
* START_CHARGE_THRESH_BAT0/1: 0(off)..96(default)..99
* STOP_CHARGE_THRESH_BAT0/1: 1..100(default)
+++ ThinkPad Battery Status: BAT0 (Main / Internal)
/sys/class/power_supply/BAT0/manufacturer = SANYO
/sys/class/power_supply/BAT0/model_name = 42T4817
/sys/class/power_supply/BAT0/cycle_count = 0 (or not supported)
/sys/class/power_supply/BAT0/energy_full_design = 43290 [mWh]
/sys/class/power_supply/BAT0/energy_full = 50330 [mWh]
/sys/class/power_supply/BAT0/energy_now = 50330 [mWh]
/sys/class/power_supply/BAT0/power_now = 0 [mW]
/sys/class/power_supply/BAT0/status = Full
/sys/class/power_supply/BAT0/charge_control_start_threshold = 96 [%]
/sys/class/power_supply/BAT0/charge_control_end_threshold = 100 [%]
tpacpi-bat.BAT0.forceDischarge = 0
Charge = 100.0 [%]
Capacity = 116.3 [%]
+++ Recommendations
* Install tp-smapi kernel modules for extended battery status (e.g. the cycle count)
Observe BAT0 or BAT1 etc in case of you replace battery or having multiple batteries.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.