I set such things in ~/.phoshdebug. Idk if the version in PureOS is recent enough for that though.
Make sure to export G_MESSAGES_DEBUG too. See https://git.sigxcpu.org/cgit/talks/2023-08-froscon-logs-and-backtraces/plain/talk.pdf?h=main for some more details on how to debug such issues.
Ohh shiit. I forgot that you need to add export also (I have it on my device xD)
so everyone place this:
export G_MESSAGES_DEBUG=phosh-lockscreen,phosh-calls-manager,phosh-call-notification
to ~/.profile
Thanks Guido and sorry all :S
I am having this problem.
I will turn on the logging if that will help, after getting an event what do you want, sent to where so people can look at it.
Any though on creating some kind of short term fix?
Maybe a button on the long hold of the power button, that allows for restating the phone module?
Or maybe causing a restart if a specific USB device in stalled?
I have not found any (reasonable) workarounds. Or maybe the verbose logging is the key because after enabling that I have not seen this 
To escape this jam easily you have two options:
Sure we could create some hack what triggers Phosh or Calls reboot when doing something (like pressing key or swiping somewhere) and in fact it might be even quite easy if we use for example lisgd or something. But I think this will be solved after we get even one logs why the call gets stuck.
There is a similar problem, just as annoying.
I experienced it again today.
I accidentally hung up on a call. (Which happens because the L5 is terribly erratic when it comes to switching off the screen when the phone is near your ear - you see it flashing constantly from the corner of your eye.)
As I tried to call back, the call came in from the other party, beating me to it.
At that moment the L5 goes bezerk: it rings and vibrates like mad, but there is no way to hang up or pick up. It is completely unresponsive.
This all feels so shoddy. Specially because Purism had a lot of time to correct basic mistakes like this. Are they even trying?
Hello,
It happened again. Same pattern, my phone was sleeping, I received a call, answer it, everything OK, but I am stuck on the call screen.
It happens the 28/3/2024 at 14h44:58. I was able to connect it with USB right after the problem, so it is seen as a network card by my computer, which shares the LTE connection.
This time, no kernel issue, dmesg shows nothing special, no hardware issue:
[Thu Mar 28 14:36:42 2024] CPU1 is up
[Thu Mar 28 14:36:42 2024] Detected VIPT I-cache on CPU2
[Thu Mar 28 14:36:42 2024] GICv3: CPU2: found redistributor 2 region 0:0x00000000388c0000
[Thu Mar 28 14:36:42 2024] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[Thu Mar 28 14:36:42 2024] CPU2 is up
[Thu Mar 28 14:36:42 2024] Detected VIPT I-cache on CPU3
[Thu Mar 28 14:36:42 2024] GICv3: CPU3: found redistributor 3 region 0:0x00000000388e0000
[Thu Mar 28 14:36:42 2024] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[Thu Mar 28 14:36:42 2024] CPU3 is up
[Thu Mar 28 14:36:42 2024] caam 30900000.crypto: registering rng-caam
[Thu Mar 28 14:36:43 2024] OOM killer enabled.
[Thu Mar 28 14:36:43 2024] Restarting tasks ... done.
[Thu Mar 28 14:36:43 2024] random: crng reseeded on system resumption
[Thu Mar 28 14:36:43 2024] thermal thermal_zone3: failed to read out thermal zone (-61)
[Thu Mar 28 14:36:43 2024] PM: suspend exit
[Thu Mar 28 14:45:11 2024] bq25890-charger 3-006a: Upstream supply changed: 1.
[Thu Mar 28 14:45:11 2024] bq25890-charger 3-006a: Disabling OTG_EN pin
[Thu Mar 28 14:45:11 2024] bq25890-charger 3-006a: Upstream supply changed: 1.
[Thu Mar 28 14:45:11 2024] bq25890-charger 3-006a: Disabling OTG_EN pin
Here is the full log ( journalctl --no-pager --since "1 hours ago" > hangOnCallScreen.log with logging activated, aka export G_MESSAGES_DEBUG=all in ~/.profile )
I removed the caller name and phone number at 14:36:51
The end of the call is visible: Mar 28 14:44:58 pureos ModemManager[776]: <info> [modem0/call12] call state changed: active -> terminated (unknown)
I don’t know why there is some french in the logs… bad idea to localize logs. Here are the translation:
Interesting thing:
I asked a contact to call me : Phosh came back on the home screen, with a notification “incoming call”. By clicking on the notification, I was able to take the call. While calling the interface was the normal one. There was no problem at the end of the call…
Workaround is to be called by someone to unfreeze phosh !
Here is the log of the next call.
Thank you! Finally we have something to debug 
I will open issue to Phosh later and post the proggress here
I do not have issues with the proximity sensor.
In the logs, you also see it, it you search for “Proximity”, so you can also activate all logs on your phone to prove the problem.
It is quite reliable for clear skin, no hairs on the ears… I use the screen protection from Purism which has an empty zone between front speaker and front camera.
You can also test it in “mobile settings/sensors”.
The worst case test is a black fabric… But it also a problem on other phones. Maybe combining luminosity + proximity is a way to solve the hardware problem.
I think the issue is that the stuck call is somehow only partially terminated. Call 13 is still active when Call 14 arrives and it only gets killed when the Call 14 arrives.
If this really annoys you and you wan’t something fast you could try my workaround:
Or you could just copy some ideas of those scripts.
Why it should help? It will double check that all calls are terminated when the call ends.
But this is just a quick look so don’t take it as fact.
Do we know if call 13 is still exposed by calls on DBus at this point ? (I wouldn’t ever rule out the problem is in phosh but to me it looks way more likely it’s in calls as we’re seeing errors there and phosh actually only listens for changes on exported call objects).
Dear all,
If this happens again and I can log in on the device, what should I look for on dbus ?