OK, I’ll ditch auto-cpufreq for tlpui.
Are you also suggesting a change to the Liquorix kernel?
I will not do all of these things in 1 step. I’ll also await petsam’s and jake99’s feedbacks before I decide on a course of action.
OK, I’ll ditch auto-cpufreq for tlpui.
Are you also suggesting a change to the Liquorix kernel?
I will not do all of these things in 1 step. I’ll also await petsam’s and jake99’s feedbacks before I decide on a course of action.
Not for now.
Try it with your current kernel(s) first.
What is by the way your CPU?
inxi -aC
Also you could use
sudo tlp-stat -p
to see what cpu governors and frequencies are available for your CPU.
OK, I admit I am a Linux philosopher and promote philosophy on Arch .
Answering, would provide us a better overview of the situation we are trying to help with, while we have no direct access on your system .
The system. This would give an as clean as possible system to work with.
If reinstalling is not possible/worth it, go for the next part.
I believe that answering the questions would help you decide if reinstallation is worth the effort. Anyway, keep us informed.
Yes, dude. Boot into Live EOS environement (USB from your original install) and send logs from there. You can use the Welcome app, or the same command from terminal
journalctl -b -0 | eos-sendlog
I am interested if intel_pstate and/or power management is working there on the “clean” system.
Sorry to interject. I think it’s important to keep in mind that the laptop draws quite a significant amount of power when it starts up. My Samsung 6 amp during startup. During normal operation, the current value varies between 2-3.5 amps. The battery, which is permanently connected to the power supply, unfortunately, after a while loses its capacity, and the protection circuit itself can recalibrate. Check the bios circuit to see if there is a calibration option. Also, I think sleep is better than hibernation although I could be wrong. Sleeping without applying voltage, naturally consumes the power of the battery, causing it to work, which is healthier for it than continuous charging
CPU:
Info: model: Intel Core i7-8750H bits: 64 type: MT MCP arch: Coffee Lake
gen: core 8 level: v3 note: check built: 2018 process: Intel 14nm family: 6
model-id: 0x9E (158) stepping: 0xA (10) microcode: 0xF0
Topology: cpus: 1x cores: 6 tpc: 2 threads: 12 smt: enabled cache:
L1: 384 KiB desc: d-6x32 KiB; i-6x32 KiB L2: 1.5 MiB desc: 6x256 KiB
L3: 9 MiB desc: 1x9 MiB
Speed (MHz): avg: 2200 min/max: 800/4100 scaling: driver: intel_pstate
governor: performance cores: 1: 2200 2: 2200 3: 2200 4: 2200 5: 2200 6: 2200
7: 2200 8: 2200 9: 2200 10: 2200 11: 2200 12: 2200 bogomips: 52815
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Vulnerabilities:
Type: itlb_multihit status: KVM: VMX disabled
Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT
vulnerable
Type: mds mitigation: Clear CPU buffers; SMT vulnerable
Type: meltdown mitigation: PTI
Type: mmio_stale_data mitigation: Clear CPU buffers; SMT vulnerable
Type: retbleed mitigation: IBRS
Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
prctl
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
sanitization
Type: spectre_v2 mitigation: IBRS, IBPB: conditional, RSB filling,
PBRSB-eIBRS: Not affected
Type: srbds mitigation: Microcode
Type: tsx_async_abort status: Not affected
Computer: 2019
EOS: June 2022
Battery drain from start: I don’t think so.
What changed just before I noticed it: don’t know, I did not make the link immediately. Since the battery on my previous Lenovo was crap too, I initially thought the quality of this one was crap too.
Yes, I think Solus.
Nothing
Nope
When I installed EOS I only did Cinnamon. Over the past 2 weeks I installed and uninstalled (as per the instructions here) Gnome, XFCE. I also installed KDE and have kept using it. So, right now I have Cinnamon and KDE installed.
I installed conky a few months ago, well before I started this thread.
Nope, it is not. I never leave my computer plugged in indefinitely. When it is fully charged, I unplug it and run it on battery.
That is not my experience. I found that in hibernation the battery is run down more slowly. If this is a wrong observation I will not use hibernation anymore.
Here’s the link.
That probably depends on how often you restart your session.
In principal, hibernated machine takes no power, and sleeping machine takes a minimal amount of power. The frequency of restarting session may make the difference.
So if you keep restarting the session soon after hibernating (suspending to disk), it might take more power than restarting the session after suspending to RAM.
But if you restart the session long time after hibernating, in principal the startup “cost” should be negligible.
Edit: could be that modern SSDs make this difference much smaller.
Ok, have much better overview now, thanks. Culprit is buggy Lenovo firmware/BIOS.
The main issue is this
Jan 17 05:53:16 EndeavourOS kernel: irq 9: nobody cared (try booting with the "irqpoll" option)
...
Jan 17 05:53:16 EndeavourOS kernel: RIP: 0010:cpuidle_enter_state+0xda/0x370
...
Jan 17 05:53:16 EndeavourOS kernel: [<00000000e7ec1641>] acpi_irq
Jan 17 05:53:16 EndeavourOS kernel: Disabling IRQ #9
IRQ 9 is the main ACPI interrupt (you can check this with grep acpi /proc/interrupts
) that will get disabled, so nothing will work properly, CPU parking, power management, your keyboard backlight, function keys, etc…
I’ve also found a lot of the similar issues on kernel bugtracker regarding this behaviour on Lenovo laptops (some of them from 2016), for example here. There is also a mention of it on Lenovo support site here (everything is fine according to Lenovo lol, they are investigating )
I am afraid there is not much you can do, we can try to debug ACPI but that would take a lot of time.
For quick “fixes” you can try the following and see if it changes anything:
ideapad
and ideapad_acpi
kernel modules. This platform driver is definitely not working it disables the backlight control tooJan 17 05:53:09 EndeavourOS kernel: ideapad_acpi VPC2004:00: Keyboard backlight control not available
intel_pstate=passive
to kernel command line) and see if ACPI handling gets betterirqpoll
to kernel command line and observe the logs. WARNING: this will slow down everything to a crawlThat’s all I got. Good luck.
Thanks for your input.
So, essentially it is a Lenovo issue. Good to know.
How can I do that? Which commands do I need to do in the terminal?
Am I right when I say I need to open /etc/default/grub
, then add intel pstate condition to GRUB_CMDLINE_LINUX_DEFAULT=
between the start and end quotation marks?
So, why should I do that? I know it might improve the battery life, but increase my frustration.
Would it not be better to do the 1st 2 options above? If so, should I implement them at the same time or one at a time?
In principle I put it on hibernation for the night, then restart it the next day, so from a battery point of view that is better than putting it to sleep.
If during the day, however, I need to step away from my computer for half an hour or so, then it is better to put it to sleep, i.e. suspend it, if I understand you well.
By the way, I just noticed (started to look at my laptop because of this thread ) that wifi (iwlwifi) seems to consume quite much battery. Now I added an ethernet cable to it, and seemingly the battery holds longer than without the cable. Don’t know if there’s much I can do about it, but a useful observation anyway.
Of course, Wifi is part of our daily life so we cannot really do without it.
That aside, I am still puzzled as to why there is that sudden drain when the battery reaches 40% (as explained in my OP) when all the way down to that point battery life degeneration is more normal.
When the battery of my laptop finally died last Summer, it did the about same thing in last months. It dropped to zero percent almost instantly from about 60% while just using it normally (no heavy stuff was running) and (naturally) powered off.
HP laptop. I feel there was something fishy with the battery…
Interesting!! Maybe there is something fishy in that some companies force their computer users to spend money on after sales, and what is easier than batteries?
In other words, even if your power management is not up the creek like mine, your battery will still go quickly.
BTW, still got that HP? Replaced it with another HP or did you change brand?
I replaced that battery to another HP battery. The laptop is about 5 years old, so I couldn’t find a better deal here. I wanted to buy a battery with better capacity, but that wasn’t available for this laptop.
And battery is still draining relatively fast, but now it goes gradually towards 0%, no more in one big step.
And I agree that companies want to sell as much as they possibly can…
For blacklisting you have a couple of options, more info on the ArchWiki here
Yeah, that’s it basically; but don’t remove the already existing content there (you have your resume options set there, too), and don’t forget to regenerate grub config with
sudo grub-mkconfig -o /boot/grub/grub.cfg
when in doubt, check the Arch Wiki again here
Anyway, I think the easiest option for you can be to do blacklisting + setting pstate from the kernel command line in one go
GRUB_CMDLINE_LINUX_DEFAULT="(... previous options) intel_pstate=passive module_blacklist=ideapad,ideapad_acpi"
You would do that to see if the error messages disappear from logs and if irq #9 would work, sorry if I was not clear enough. Check this out for the quick explanation of what irqpoll does.
I added intel_pstate=passive module_blacklist=ideapad,ideapad_acpi
, as well as irqpoll
. I know you said the latter would make it slow down to a crawl, but it seems it got stuck.
The text scrolling by during start up is completely different. The 1st screenful of text is normal with the green OK’s. But then the text changes and it gets stuck on a line that says
7.095247] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---
Also, the little light on the Caps Lock button keeps flashing.
As I write this it has been stuck on this line for 45 mins, which suggests to me it won’t get past this. I’ll leave it for another hour; if it has not moved I’ll force close down the computer.
UPDATE: I force closed down the computer after it was stuck on that line for 1½ hours.
I then tried to fire it up using the 2nd choice in Grub, something about “fallback”, but the exact same thing happened as described above.
Please advise on next step.