High battery drain (s0ix, Ryzen 5650U)

As suggested by @superm1 I am coming from #2248 (closed) and opening up an new issue.

My status: battery drain continues on s0ix (T14 AMD Gen 2, Ryzen 5 PRO 5650u), Ubuntu on kernel 6.1 finale release.

My power profile is always set to "Performance".

On #2248 (closed) there has been discussed debug steps in detail including acpi dumps, closed / opened lid while sleeping, plugin and off the power etc. Since I am suspecting this has something to do a BIOS / EC bug I have tried following and uploaded the logs to begin with:

kernel parameter: amd_pstate=passive pm_debug_messages amd_pmc.dyndbg

1. 120 seconds sleep with lid opened and power plugged in all the time:

   dmesg -C && turbostat -o ts.out rtcwake -m freeze -s 120 && dmesg -H > dmesg.out

   log files are: dmesg.out, ts.out, journal.out

dmesg.out

journal.out

ts.out

2. 5 hours sleep with lid closed. Battery dropped from around 99% to 80%. log file: journal-5.hours.out

journal-5.hours.out

@superm1 I will have more time after tomorrow and I am more than happy to do more debug / test steps if needed. I also have a additional L14 Gen 1 with intel i7 10610U available if it is useful in any case.

Side note: the battery drain issue was also present under S3 just like under s0ix (did not check with 6.1 final but I doubt it will be gone), but of course this is another discussion. I do suspect that they are both connected to the BIOS / EC bug with IRQ9 triggering wakeup.

Thank you Eric

changed the description

I don't see any evidence that the SOC is stuck in a high power consumption state over s2idle for an inordinate period of time from your logs. I would hypothesize the following possible problems:

1. The EC notification path for s2idle entry is broken. This is evident by your logs with the ACPI failures. Any devices that the EC manages the power rails for won't turn off this means, which translates to higher power consumption.

2. Your battery is worn down. Everything is getting to the right state but because of the battery health you're still draining (relatively) fast.

I would start out with flashing the latest firmware if you haven't already. If you're already on the latest firmware, then you'll need to work with Lenovo on getting the ACPI entries fixed.

There isn't anything more to do here from the kernel side that I can tell if the SOC is spending all it's time in the hardware sleep state.

closed

added s0ix label

Thank you very much Mario to confirm that it is not soc that is the cause since I myself don't know how to read the logs correctly to understand that. Now I know for sure where to work on from here.

I am on latest firmware of the EC and according to upower I have only 12 charge cycles with almost full design capacity, so I will continue this issue with lenovo side.

Again thanks a lot.

Eric

Hi @superm1

Mark Pearson from Lenovo is helping me with regard to this issue since we close it here. However we run into something interesting that I will like to hear your thoughts on.

So I run your amd_s2idle.py without modifying any of the default values. With kernel 5.19 and 6.1.9. Both time it catches the EC error of course, but the result from 5.19 says "Spent 0 seconds in a hardware sleep state" while the result from 6.1.9 says "Spent 8.531097 seconds in a hardware sleep state".

I will like to ask you about how reliable that statement / information is. Because I did a turbostat on 120s sleep and it doesn't look right to me, and I did a sleep on 10 hours, the battery goes from 95% to 59%. So for me the problem is still present. Besides that, to me it really indicates it is a problem from Lenovo side but not something just fixed from AMD's commits to the kernel.

While Mark is looking into this, I will try the hypothesis of a faulty battery, by doing a test on it today (by disable auto suspend and let it just stay turned on), but again I doubt it is the battery.

(I look into the python script and see how you catch the lines of kernel log and calculated the result, so I need to rule out the possibility of a faulty battery first.)

Thanks Eric

but the result from 5.19 says "Spent 0 seconds in a hardware sleep state" while the result from 6.1.9 says "Spent 8.531097 seconds in a hardware sleep state".

There are sleep related patches past 5.19 going EOL that improve the efficacy of specific circumstances.

I will like to ask you about how reliable that statement / information is.

It's a hardware register deep in a power management microcontroller. It truly reflects time in that state.

and I did a sleep on 10 hours, the battery goes from 95% to 59%

It sounds to me that AMD APU is in deep sleep state but other devices in the system might be burning battery.

Some other speculative guesses; It could be anything with rails driven by the EC, or if you have DASH enabled or WWAN in the system.

Another idea is perhaps run your long suspend cycle under the context of the script using the arguments. See if APU spent the whole cycle in that hardware sleep state.

turbostat on 120s sleep

Turbostat I don't believe is as useful on AMD APUs as it is on Intel CPUs.

One more thing comes to mind. Please update to the newer version of the script. There are some extra checks that have been added that look for other bugs.

mentioned in issue #2393 (closed)