You are not logged in.
Recently I have experienced a problem where i am working on my computer and all if fine and suddenly the screen blanks and shows low battery sign. After plunging in charge and investigating kde energy shows that power consumption rose (almost) linearly to above 10 W and the shut down and after a while declines (almost) linearly then back to normal. First I thought it was a faulty suspend and did a lot to enable s2ram (deep) and on the process broke my arch install. I installed arch clean and the problem persisted this time i successfully enabled deep suspend and doubt this is the problem now. I have installed TLP and Powertop but the problem persists.
I think but an not to sure the sudden drop in the power consumption on the decline side was when i suspend with command 'sudo s2ram'. I have no clue how to proceed and have searched online a lot without success. If anyone can help me figure out what is going on i would be very grateful. If more info is needed i am more than happy to provide.
Last edited by mavericus (2023-05-12 16:43:53)
Offline
I don't know what the solution is, but if it's happening on a clean install it seems like it's a hardware issue - some driver is doing some dumb stuff like getting stuck in a loop and it's eating up processing power, which in turn drains the battery. If you figure out which driver, you can search online and see if other people found a workaround.
It could also be due to some program you're running. If you can catch it during high usage, trying closing your own programs and seeing if any background processes are using a high amount of CPU/RAM/disk IO/network IO with a tool like htop. If you can't catch it, you'll have to somehow log cpu usage etc. to a file, and examine it afterwards.
Offline
Ftr, KDE seems to trigger high Xorg process CPU load, https://bbs.archlinux.org/viewtopic.php?id=278890
The behavior seems to fit "power consumption rose (almost) linearly to above 10 W" and sudpending/restarting the compositor (SHIFT+alt+F12) would have some impact on it.
Offline
after another clean install and some poking around using powertop i found these processes take a lot of the power and are around after or sometimes before the event happens:
Interrupt [39] mmc1
Interrupt [126] i915
Interrupt [31] idma64.4
kWork intel_atomic_commit_work
Timer tick_sched_timer
Timer tick_sched_timer is the service which is the only one i could find information about. apparently this is a sign something like ifitzgerald said.
With further inspection the linear thing is probably because kde detects 2W at lets say 14:30 and nothing for 30 mins and then 10+W at 15:00 then it draws a straight line . This is most likely the case as when it complete random battery drain happens i am at lets say 80% and then a min later boom 0%, when you look at the graph later there is a download sloping line showing linear decline for about 30 mins even when there wasn't.
I have had a look around these processes but found nothing will be glad for any more help. tick_sched_timer and the mmc1 interrupt are consistently present
p.s there are also a lot of interrupts,i don't know if that is normal or not so putting it in just in case.
Offline
i am at lets say 80% and then a min later boom 0%
Your battery is dying.
Offline
Is there any way to help or fix this. Or does this mean I should replace it?
Offline
If your battery (check "acpi" and /sys/class/power_supply/BAT0/ - don't rely on GUI indicators and maybe try a live distro and at least the LTS kernel to rule out any kernel bugs) drops almost its entire charge in 60 seconds and isn't short circuited (eg. bad seating) you need a replacement.
You could also boot the multi-user.target and poll the battery level eg. "while true; do (date; acpi) | tee ~/bat.stats; sleep 30; done" and let it sit and see how long it lasts (and how the charge develops) to rule out some userspace process going wild, but the hardware should not be able to drain the battery within a minute, so I don't think that's the issue.
Offline
If your battery (check "acpi" and /sys/class/power_supply/BAT0/ - don't rely on GUI indicators and maybe try a live distro and at least the LTS kernel to rule out any kernel bugs) drops almost its entire charge in 60 seconds and isn't short circuited (eg. bad seating) you need a replacement.
You could also boot the multi-user.target and poll the battery level eg. "while true; do (date; acpi) | tee ~/bat.stats; sleep 30; done" and let it sit and see how long it lasts (and how the charge develops) to rule out some userspace process going wild, but the hardware should not be able to drain the battery within a minute, so I don't think that's the issue.
I tried you advice with the "while ..." Command and the battery lasted 3.5 hours from 100 to 81 percent after which it shut off and once I put in the plug and waited said battery was 1% the output of the command is here:
It lasted decent time and before shut down said there was 11 hours left which on non Gui mode is what I normally get. I normally get 7 to 8 hours with Gui. Does this confirm something or should I give more info. It's not the first time it reached 81 and shut down from 100 last two times I remember have been at 81 and 83. Not the only numbers but too frequent to ignore. also seems to me like bad battery but when it ran power consumption and battery decline was very normal.
Offline
also seems to me like bad battery
Check the levels in /sys/class/power_supply/BAT0/, notably charge* and voltage* and how much capacity you can charge and how close the voltage is to voltage_min_design when you're approaching 81% charge.
Offline
also seems to me like bad battery
Check the levels in /sys/class/power_supply/BAT0/, notably charge* and voltage* and how much capacity you can charge and how close the voltage is to voltage_min_design when you're approaching 81% charge.
I tweaked you command a bit to:
While true: do (date; acpi; cat /sys/.../BAT0/uevent) | tee -a ~\bat.stats; sleep 30; done
Hopefully the output of this command shows everything you wanted.
I don't have a charge file but do have capacity if they are the same thing. The battery stats at the time of shutdown are shown by the uevent output. Unfortunately I don't know how to find the voltage_min_design because catting the file shows "No such Device".
The output is here: https://pastebin.com/baPwaQS6
The voltage seemed to be the same throughout. The last output before the computer shut down shows the energy left was still high. The output shows more details.
Also I assumed that you ment do these test from 100 dischargeing and not from below 81 charging. If I am wrong I'll do them again.
Offline
How old is the battery? Unless it is almost new, it seems suspicious that it would still have its design capacity?
CLI Paste | How To Ask Questions
Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L
Offline
It is only 1 year old. Also I kept it in good shape and don't overcharge or do heavy stuff that causes too much over heating. I can't say the same for bumps. I have droped it once or twice but not too damaging. It's a geobook 1e if that info helps.
Offline
There're no signs of the battery failing (though the capacity seemed suspicious to me as well)
My next best guess would be to try the behavior on a different SW stack (live distro like grml) - if it shows the same behavior, it's likely the HW. Otherwise there might be some weird kernel regression.
Offline
I forgot to add that I have dual booted this laptop and today I went on windows which I almost never do and the same thing happened from full charge at around 83 percent it shut off again.
I know this is an arch Linux forum but if it is hardware do you have any tips to solve this or should I replace battery/laptop
Offline
3rd link below (no, that's not the BIOS option and also windows keeps re-enabling it, so make sure it's disabled)
Reboot both systems (linux and windows) twice afterwards.
Running two OS in parallel (what happens when you boot linux while windows is hibernating) as a long standing track record of fucking with the ACPI
Battery would I think be a first, but not surprise me - so we should check that.
Offline
3rd link below (no, that's not the BIOS option and also windows keeps re-enabling it, so make sure it's disabled)
Reboot both systems (linux and windows) twice afterwards.Running two OS in parallel (what happens when you boot linux while windows is hibernating) as a long standing track record of fucking with the ACPI
Battery would I think be a first, but not surprise me - so we should check that.
I have done this. Is there anything else I need to do. I am currently charging the laptop to 100 to do the test again. If this was the problem should I see a instant improvement or else? Also from the last test is the voltage_min_desgin supposed give error no such Device when opening or "catting"?
Offline
If this was the problem should I see a instant improvement
Yes.
is the voltage_min_desgin supposed give error
No, but I'd expect an abrupt (or steady) drop in POWER_SUPPLY_VOLTAGE_NOW - if the battery cannot keep up the voltage, the system ends up undervolted and powers down.
Offline
If this was the problem should I see a instant improvement
Yes.
is the voltage_min_desgin supposed give error
No, but I'd expect an abrupt (or steady) drop in POWER_SUPPLY_VOLTAGE_NOW - if the battery cannot keep up the voltage, the system ends up undervolted and powers down.
I've done what you said and given it 2 days, one with no use and one with moderate use. I have also unplugged the battery and re plugged it and nothing changed. your suggestions did fix a problem i was having with windows going to blue screen and auto fixing itself. I never thought of this much because i barley used windows anyway. i have replaced the laptop with another one now because i am pretty sure that it is the battery and if it wasn't it would be too complicated to fix. Just installed arch and windows now (with hibernation and fast startup disabled already) and everything is well so far. Thanks for your help. Hopefully someone also having my problem because of the things you said have some guidance in the future.
Offline