Ok, 6.6.32, it must be the most recent. Will waiting for the next one :).
By the way, do you have some stuff on sdcard?
Yes I set up a swap partition on SD card, and a storage partition where I store big files (downloaded videos)
Second day without crash, it seems promising
But the phone becomes unusable for me without suspend as you have to keep it connected to a powerbank all day.
I’ve found at least four issues connected to he suspend/resume bug:
- mobile data stop working - may be fixed by preventing modem goes to sleep as it has been done in pmos.
- sdcard stop working like in this thread - may be fixed by patching the kernel.
- wifi does not go to sleep properly - may be fixed by using kill switches before suspend.
- something strange happens during resume - sudo stop working, network connection lost and so on… I have no idea how to debug and about possible workaround :(.
Also I believe that it is much better to keep swap file on the root (mmc) partition as soon as it about ten times faster and free from issue 2.
For me too, it’s okay when I stay at home but if when I leave it’s unusable. Altough I’m surprised that the battery life isn’t as hugely different as I thought, maybe because suspend is not very efficient yet.
I have issue 1 when suspend is enabled, I don’t think I had other issues you listed.
Swap might be faster on eMMC but will burn it, I prefer to burn a sdcard
In fact your issue can be related to the swap on sdcard as soon as if the last one was missed on resume you are not able to work further without a part of your memory (previosly swapped).
Thanks for the link, but it looks like different issue as it happens after reboot. All my issues related to suspend/resume procces.
So I should disable the swap to see
At least to check the issue and report here about the result 
It"s done for a couple of hours, no crashes yet and about the sdcard issue you told I sometimes create/delete an empty file on the sdcard to check it is read-write and not read only
Argh ! It crashed ! Touchscreen remains black and buttons are unresponsive but LED still blinks in blue.
I can’t ping it over LAN
So it is not related to a sdcard issue.
Is it safer to wait for the battery to empty than force shutdown ?
Why the led blinks blue? Are you receive a sms? So was the phone resumed by the modem?
It was either a mail or a XMPP message, but not a SMS (I removed my SIM card from my L5 until the issue is solved). I let the battery empty and then plugged the L5. Susped disabled
Ok, lets try to read the logs :D.
Could you run journalctl -r and search something related to etnaviv and cut here marker?
It could be a real crash of the gpu driver…
Disabling suspend doesn’t make the problem with random instability on older kernels go away, it just makes it much less likely to trigger (but there are other possible triggers as well, such as USB-C data role swapping).
The new kernel is now in byzantium-updates-proposed and should arrive in byzantium-updates in a matter of hours.
That’s very likely to cause troubles when resuming from suspend because of SD card is unwritable after resume from suspend (#484) · Issues · Librem5 / linux · GitLab. For this one, disabling suspend will actually prevent it from ever happening.
Do you have a real need for swap partition on your phone? I’m using mine (3GB version) with zram as configured by default and I find it sufficient for regular usage. The only time it wasn’t was when trying to compile squeekboard on the phone.
This means the kernel didn’t crash. You should be able to gather logs from when it happened from system journal.
I found it:
Thank you ! So you think it will solve my issue ?
Ironically I did this to prevent crashes… As I’ve previously experienced this crashing situation on my Pinephones and read on this forum that saturation of RAM may cause crashes I decided to create swap partition. But now I know this was a different issue on my Pinephones becauses crashes occured during active use and there was at least 2 different issues: sometimes it was a Phosh crash and I could recover either by plugging a keyboard, or through ssh and run systemctl restart phosh.service and an other one which was more similar to the one I’m experiencing now but I don’t remember if it occured only during resume from suspend or also during active use.
It’s hard to tell as the problem the new kernel is fixing was a use-after-free causing all sorts of random issues afterwards, so this etnaviv trace may actually not be related to any issue in etnaviv at all but rather caused by memory corruption… but there’s also a possibility that you actually hit an actual etnaviv bug. I think there’s a good chance it will, but we’ll know for sure once you actually test it.
I found it:
Yes, it is! I have this issue one time per day or two even despite relatively recent mesa version (22.3.6).