REPRODUCIBILITY: no
OS VERSION: 5.2.0.17
HARDWARE: Jolla Phone (2026)
UI LANGUAGE: German
REGRESSION:-
DESCRIPTION:
I experienced around 5 random shutdowns in the last 2 weeks, all of them while the phone was in my pocket. In 4 of those cases the phone was just shut down and started as if it was shutdown on purpose. Maybe this was the case, could something trigger a shutdown while the phone is in a pocket? In one case the phone was still on and a red LED flashed slowly. The screen would not turn on again and after a long click on the power button the red led stopped flashing and stayed red constantly, the jolla logo appeared, afterwards the phone just restarted normally. The battery level was at around 60% and the phone continued to work as expected after the reboot.
PRECONDITIONS:
All of the shutdowns occurred while the phone was in my pocket.
STEPS TO REPRODUCE:
-
I could not find anything to force the behavior, it happens usually when I’m on the go and without a possibility to SSH into the device to check if its still reachable.
EXPECTED RESULT:
The phone should stay on while inside a pocket.
ACTUAL RESULT:
The phone turns (randomly?) off while inside a pocket.
MODIFICATIONS:
ADDITIONAL INFORMATION:
After the case with the red LED i was able to get some logs out, but nothing directly pointed out an issue, here’s an (AI generated) overview over those logs:
Timeline (journalctl -b -1, 5 Sep 2026)
| Time | Event |
|---|---|
| 21:16:09 | [DISP]after esd check 0xc=0x800b032a 0xc4=0xf073a — panel returns a value differing from the usual 0x800f071a |
| 21:16:10 | [CMDQ]<0>(6)[cmdq] ===== SW timeout Pre-dump 0 =====, thread 6 waiting on event 997 |
| 21:16:10+ | Timeouts repeat at ~3.3/s; sync event changes to 644; packet addresses keep changing (fb5af000 → fb41e000 → fb416000 → fb5e4000), i.e. new frames keep being queued and each hits the same timeout |
| 21:19:02 | Last lipstick entry: sleepDisplay — UI still running at this point |
| 21:24:56 | DSME[]: pwrkeymonitor: Timer triggered, initiating shutdown — manual power-button recovery |
| 21:25:00 | mce[]: mdy_stm_step(): no compositor; going to logical off, preceded by ui stop failed, retrying |
| 21:25:16 / 21:25:19 | mce and composer@3.4-se have to be SIGKILLed |
Total hang before intervention: ~9 minutes, pre-dump counter reached 1748.
Key log lines
Kernel, CMDQ (repeating, thread 6):
[CMDQ]<0>(6)[cmdq] thd:6 timeout:0x3e8 pc:0x00000003fb416010 inst:0x2000028480008001
[CMDQ]<0>(6)[cmdq] curr inst: 0x6010 0x2000028480008001 [Sync ] wait for event 644 become 1 and clear to 0 value:0
[CMDQ]<0>(6)[cmdq][err] timeout for thread:0x0000000016a796dc idx:6 usage:4
Kernel, display:
[DISP]after esd check 0xc=0x800b032a 0xc4=0xf073a (normal: 0x800f071a)
[disp_aal][DISP][disp_aal]disp_aal_wait_hist: interrupted unexpected by signal
mce:
mdy_stm_step(): ui stop failed, retrying
mdy_stm_step(): no compositor; going to logical off
ESD check returned off-nominal values repeatedly, also outside this incident: 0x80080000, 0x80000000, 0x800b030a, 0x800c0710.
Ruled out
-
OOM — no
Out of memory/oom-killer/Killed processentries in-b -1. -
Lipstick crash — no segfault, no core dump; it was blocked, not dead.
-
Thermal — SoC ~36 °C, board NTCs ~32–34 °C, trip points at 85 °C.
-
Kernel panic —
[wdtk] kick watchdogcontinues until the manual shutdown. -
Charging — device was on battery; no
type_c_port0/usb0wakeup sources, charger CV at 4200 mV (not the 4520 mV seen while charging).
Assessment
CMDQ waits indefinitely on a sync signal from the display path. The off-nominal ESD check immediately before the first timeout points at the panel or the DSI link rather than at software. The device was in a pocket, so mechanical stress on the display flex cable is worth considering.
Side observation (possibly unrelated)
I2C to the power IC intermittently fails to answer, on battery as well as while charging:
mt6720-adc ...: mt6720_adc_read_channel, Read vbat_mon TIMEOUT!!
get_charger_zcv: get charger zcv failed: -95
Notes on the attached log
Captured with a persistent journal (/var/log/journal present, Storage=auto). The kernel ring buffer is dominated by conninfra/thermal/pogo-pin debug output at info level, which limits how far back both the journal and the ramoops console buffer reach. Note that ramoops.record_size is not set in the kernel cmdline, so this device produces no dmesg-ramoops on panic — only console-ramoops.