It’s been a while, there were quite a few charge cycles without issue somehow. It happened again last night but given the earlier rate I’d expected a crash sooner. I have updated to 5.2.0.18 at some point in between, but since the uneventful charges started before that, I don’t think the update changed anything.
@mal, replying to your questions properly now:
Is the battery indicator always wrong?
No, not always. What I was getting at is that when a crash occurs, then the indicator is off (so in that sense, yes, after a crash the indicator is always wrong). That makes it ~difficult~ impossible to tell the charge level starting at the next cycle. If the indicator stays at e.g. 11% all the time for that cycle, then I just have to guess when it’s time to plug in to charge again. After a succesful recharge the battery indicator seems to recover, and then I can tell when to plug in normally again. So that also means that it’s possible some session started charging from a much lower point than I’d normally do, simply because I cannot tell. I’m going on the fact that the phone can seemingly run for the normal duration (whole day of normal usage) even when in the morning it’s only at 11% to conclude that it’s just the indicator that is not updating correctly.
ls -l + cat */uevent + UI value
All in the zip I’m emailing you separately (see power_supply_uevent_all.txt, battery_vs_ui.txt and charge_state.txt). For this crash the UI read 9% at charge-start, matching the kernel’s 9%.
“Low charge <10%”
This session started at exactly 9%, so it qualifies. Looking back at the charge attempts since the last message, it’s the only captured session that started that low:
┌───────────────────┬───────────────────────────┬─────────────────────┬──────────────────┐
│session │start kernel/UI │snapshots │outcome │
├───────────────────┼───────────────────────────┼─────────────────────┼──────────────────┤
│Sep 23 │32 / 32 │8/8 │ok │
├───────────────────┼───────────────────────────┼─────────────────────┼──────────────────┤
│Sep 26 │37 / 37 │8/8 │ok │
├───────────────────┼───────────────────────────┼─────────────────────┼──────────────────┤
│Sep 27 │59 / 59 │8/8 │ok │
├───────────────────┼───────────────────────────┼─────────────────────┼──────────────────┤
│Sep 29 │47 / 47 │8/8 │ok │
├───────────────────┼───────────────────────────┼─────────────────────┼──────────────────┤
│Sep 30 │36 / 36 │8/8 │ok │
├───────────────────┼───────────────────────────┼─────────────────────┼──────────────────┤
│Oct 4 │9 / 9 │2/8 │crash │
└───────────────────┴───────────────────────────┴─────────────────────┴──────────────────┘
Same charger (Xiaomi MDY-11-EZ) every time, so that’s controlled for. One crash is only a
correlation, but the thing to watch is whether the next sub-10% charge crashes too.
Did charging actually start / journal after half an hour
Charging verifiably started; status flipped Discharging→Charging ~1 min after plug-in, current went −58 mA → +2.0 A, voltage climbing, 9% → 11%, and snap_01’s dmesg shows the TCPC/PD negotiation happening. But I can’t give you the half-hour journal: the phone died ~4 minutes after plug-in (last curve point 01:17:44, last journal line 01:18:07), which is also why there are only two snapshots.
The most informative part: with persistent journals on and pstore cleared beforehand, the previous-boot journal ends at 01:18:07 with the charger driver still enabled and charging, then PM: suspend entry (s2idle) — and nothing after. The pstore ramoops likewise ends in routine modem chatter with no panic or oops. So from the logs’ perspective the phone charged normally, suspended, and never woke up. Post-reboot the battery still read 11%.
Helper script for capturing logs
Since doing all these captures by hand was going to be tedious and error prone, I had an LLM write a shell script to automate the process. I used it for the capture I’m sharing, so it’s tested and seems to be working well. You run it in Fingerterm before plugging in, it asks for the charger model and then automaticallly records the baseline battery/UI state, waits for plug-in, and then takes snapshots every 5 min for half an hour plus a 30s charge curve. Everything is stored all into a sub-directory charge_crash_investigation/<timestamp>/ next to the script. After a crash + reboot, you run ./charge-capture.sh --after-crash to collect the pstore and previous-boot journal. It also has a --journal-persistent on|off toggle for the Storage setting. This is what I used to take the capture in the .zip I’ve emailed you.
I hope this script will make it easier for people to provide all the information you’re requesting.
Please let us know what you find and what next steps you’d like to take.
. Let us know what you find.