[1.3.3] High battery drain on amami (and possibly all rhine devices)
Closed this issue · 23 comments
Hi,
I've read many reports about this but haven't found an issue to track this problem: I'm running a Nougat ROM (LineageOS if that is of any importance) and my phone only lasts for one day while I was reaching ~3 days with stock. Additionally, the percentage often drops from around 70% to 0% and the device shuts down.
I've tried to hunt this bug through the kernel. From some debug logs, it looks like last_ocv_uv is completely different after a manual reboot: 4094750 with 72% before and 3770410 afterwards, with 25%. (When looking on how this value is calculated, it looks weird that is only changed in adjust_soc when soc_est is smaller than adjust_soc_low_threshold = 15 - but this works on kernel-copyleft with the stock roms...)
Can anyone give advice on how to approach this issue?
Thanks
Jonas
Please analyze the problem on AOSP built following the guide provided on the Sony Developer World website.
This problem may be appearing only on Lineage OS and CAF based ROMs. If the problem doesn't persist on AOSP, then your LOS build configuration probably needs to be changed.
The first part of the issue (battery lasting less than 24 hours with light usage) is definitely present on "pure" AOSP as well (a modem hack needs to be included to enable deep sleep).
The second issue (battery percentage dropping very suddenly after some threshold) I fixed by buying a new battery, so I'm not sure if that is only related to ageing or if there is also a software component to it.
The first part of the issue (battery lasting less than 24 hours with light usage) is definitely present on "pure" AOSP as well (a modem hack needs to be included to enable deep sleep).
I'm using SuperLamic's solution: https://github.com/hahnjo/android_device_sony_rhine-common/blob/cm-14.1/ril/com/android/internal/telephony/SonyRIL.java
Maybe we have to call the modem anyway because it's doing some initialization in this routine? And then simply ignore the answer?
The second issue (battery percentage dropping very suddenly after some threshold) I fixed by buying a new battery, so I'm not sure if that is only related to ageing or if there is also a software component to it.
I read some reports that this helped, some others that it didn't. It would be a big coincidence anyway that this started to show off right after I switched from stock (~2-3 days) to a custom ROM (less than one day)...
If AOSP 7.1 is also affected, I might try CM 12.1 or even stock to see if it's my battery or something related to software
@ergoen I'm building a 7.1.2 AOSP image with your patches to test on Z3C (aries) and will report back.
Regarding the second issue popping up after switching away from stock: I think this is similar to my experience as well, so you might be right that this is also a software issue.
If it works for you now, maybe the new battery is somewhat different from the software perspective and there is something wrong in the software to handle the "old" batteries?
First report after patching the binary blobs (and not touching anything else in the build):
- discharge rate doesn't seem to have changed, at least nothing noticeable
- overnight I have a large "hole" in the battery graph (will check the battery stats with battery historian later)
- also during the time period of the "hole" mentioned above, the battery was discharging at the same rate
I've also results to report and they might be somewhat better / more interesting:
- I've flashed CM 12.1 by derf elot yesterday evening and let the phone lay around for the night.
- This moring, the battery was at ~80% (which I think is ok) and stayed at that level after a reboot.
- Because I will need my phone today, I restored the backup I took before flashing. Big surprise on reboot: The phone keeps telling me, I'm at 0% and just shuts down immediately!
IMO the easiest explanation is that this kernel does not correctly determine the current level of charge. What do you think?
Going forward, I see two options:
- Try to use / port the "old" kernel to a Nougat ROM to see if that "solves" the problem.
- Try to find out if there is a difference between the CM 12.1 kernel and this one with regard to the level calculation. This might also mean a "fixed bug" that now triggers a corner case with older (?) batteries!
@danielegobbetti The changed blobs did not enable deep sleep for you? Is the wakelock from the telephony component still there? That is interesting. It was not supposed to fix anything else battery related.
@hahnjo Is cm 12.1 using stock (copyleft) kernel or the 1.2.2 aosp version?
- Deep sleep does not really help with the battery life.
- I used @derfelot's build, I think it's this kernel source: https://github.com/derfelot/android_kernel_sony_msm8974
I just had a look again into the logs after the reboot. These lines catched my attention:
[ 6.306054] BMS: read_soc_params_raw: PON_OCV_UV = 4013074, cc = 2518
[ 6.306058] BMS: read_soc_params_raw: OCV is stale or bad, estimating new OCV.
[ 6.306066] BMS: get_battery_status: battery power supply is not registered
[ 6.310528] BMS: estimate_ocv: estimated pon ocv = 3770610, vbat_uv = 3638598 ibat_ua = 1189305 rbatt_mohm = 111
4013074 is sufficiently near to 4094750 as reported before the reboot (see initial issue details). So why does it correct that value with a wrong one?
estimate_ocv uses rbatt_mohm = 111, does anyone know if that's realistic? (in this kernel: default_rbatt_mohm = 100 per DTS, rbatt_capacitive_mohm = 0 per DTS and r_conn_mohm = 0 from bms_read_properties)
You catched all the lines around the one that you didn't notice :P :P :P
[ 6.306066] BMS: get_battery_status: battery power supply is not registered
I don't remember the code, but I would judge that strange.....
You catched all the lines around the one that you didn't notice :P :P :P
I noticed this one :P However, this comes from get_simultaneous_batt_v_and_i() which calls is_battery_full(). Because the battery was not fully charged, this shouldn't really matter and to be honest, the usual answer to reports like "there is a warning in the kernel log" in this repository is "you can safely ignore that" :P
To summarize my latest findings: I have found some wrong and other missing values in dt, see #1288. I've "corrected" them based on kernel-copyleft and this may fix some wrong calculations. The sudden shutdowns still remain and I'm therefore leaving this as WIP.
Regarding the shutdowns: I've found out that get_battery_voltage returns low values which makes clamp_soc_based_on_voltage_with_max_count set the soc to 0. The "error" seems to happen in vadc itself, all static parameters that I checked seemed to be fine and also qpnp_vadc_calib_device resulted in the same calibration as on the working cm-12.1.
Would the following help ?
zachariasmaladroit/android_kernel_sony_msm8994_kitakami_r2@27253bd Set default power supply type as USB
Would the following help ?
Unfortunately, it has not: My phone just shut down after roughly 7 hours as before :-(
qcom,scale-function = <0>;
I don't clearly remember, but this should be referred to the value of an enum in kernel.
If I'm right, then you should check if the value in the current enum is the same of the one in the kernel that worked.
I don't clearly remember, but this should be referred to the value of an enum in kernel.
If I'm right, then you should check if the value in the current enum is the same of the one in the kernel that worked.
I think it's this array: https://github.com/sonyxperiadev/kernel/blob/aosp/LA.BR.1.3.3_rb2.14/drivers/hwmon/qpnp-adc-voltage.c#L164 (SCALE_DEFAULT = 0)
https://github.com/CyanogenMod/android_kernel_sony_msm8974/blob/cm-12.1/drivers/hwmon/qpnp-adc-voltage.c#L125 (SCALE_DEFAULT = 0)
qpnp_adc_scale_default is the same, I already checked that yesterday.
Yesterday, I tested increasing hw-settle-time with no success.
Are there any clocks related to the ADC that I could compare with the working kernel?
Do you have any other ideas how I could debug this problem? Or could anyone else take a look?
@alviteri how did you find the missing clocks for msm8974 last year? By looking at the arrays in code and DT?
@jerpelea the issue is outdated and I think it can be closed