@mal, it happened again, two times in a row now.
The previous boot log in that new log set seems to be from charging-only mode. And a normal shutdown when not charging so it doesn’t tell much.
Yes, this is because as I pointed out previously, following a crash it’s rather difficult to judge when to next charge the phone since after the restart the battery percentage indicator is stuck way below the actual charge level, making it impossible to tell how full the battery really is. This time I either misjudged or phone shutdown itself erroneously believing it was more empty than it actually was.
have you done the tests with display on or off?
Just wondering if you have checked what happens if you keep display on all the time during charging?
Suspend while charging / “lights off”. My test conditions are: phone on the nightstand, screen off, untouched, charging overnight. So suspending is exactly what I’d expect and want. I prefer to sleep with the lights off, and a glowing screen on the nightstand isn’t that. Perhaps instead you can try charging with the phone purposely suspended?
Note that the suspend cycling itself isn’t the bug; the bug is that is suspendeds and never resumes (the journal’s last line is PM: suspend entry (s2idle) with no matching exit, in both the disk journal and the ramoops).
New crash: Oct 21, ~00:00.
OS 5.2.0.20 (updated since the last report). Started at 5% (kernel/UI agreed, 5/5), Xiaomi MDY-11-EZ, plugged in at 00:00:05. But this is an instance where I don’t think the 5% is accurate, being after a crash the battery indicator was still wrong. Charging started (~2A) but died about a minute later, with only 4 charge-curve points (5→6%). Same pattern as the other two crashes. This time pstore wasn’t empty: console-ramoops-0 (2 MB) survived and ends in routine modem chatter with no panic/oops — consistent with the phone charging normally, suspending, and never waking.
Let me know if there is anything else you’d like to include in the captures.