So maybe the problem is only with an encrypted sd-card. (/dev/mapper/crypt_home /home ext4 nofail 0 2) and with ext4 (you are using vfat).
Also if nothing is running I can suspend (most of the time) without problems. So maybe the problem only happens while writing to the sd-card.
Maybe I have to test when this problem occurs, and how I can provoke it.
Also I wonder why this never happens with the internal disk of the librem5. What is the difference ?
I haven’t come across this issue and I also use a LUKS encrypted SD card with ext4 format. I don’t use automatic suspend, but I do suspend it manually when I am going to be away from a power source for awhile.
I can confirm that it happens occasionally with the unencrypted ext4 partition too.
I’m facing with the same problem. A small investigation shows that the problem is quite old. Unfortunately, there is no CONFIG_MMC_UNSAFE_RESUME in the modern kernel. But, in fact, another solution has been found - adding the “expecting_media_change” flag. Moreover, the code was merged, but it disappears in the last kernel version. Why? I tried to revert it back and it looks like everything works! There is only one drawback - you must not remove sdcard during suspend, and this limitation is ok for me.
That’s not the same problem, what used to be UNSAFE_RESUME is the default behavior now.
Because it was not a correct fix and the problem it was attempting to resolve (which was related to runtime PM) has been solved differently.
It’s still a useful thing to note if it does actually workaround the suspend problem. Reading the code, I’m confused how could that happen though - but that may just as well mean that my understanding is incomplete 
In fact some additional investigating is needed… This is my patch and I can not find the exact commit that I used. But I can confirm that now my sdcard works well during suspend/resume cycles. What drawbacks can be expected by this patch?
You are right, it looks like the problem with sdcard exists despite the “fix”. I’ve got sdcard io error after a week of successful usage 
It looks like I’ve found a workaround for this issue.
Some context first: I use ext4 fs over LUKS encrypted partition located on sd-card as soon as I keep my personal files here and I’d like to be protected if I lose the phone.
Solution: LUKS has suspend option when all io operation stopped. So, I’ve created luks-suspend-resume.service with the next content:
[Unit]
Before=sleep.target
StopWhenUnneeded=yes
[Service]
Type=oneshot
RemainAfterExit=yes
# before suspend
ExecStart=/usr/sbin/cryptsetup luksSuspend <storage_name>
# after resume
ExecStop=/usr/sbin/cryptsetup luksResume <storage_name> --key-file=<path/to/your/keyfile>
[Install]
WantedBy=sleep.target
Do not forget to enable the unit. After that I have no issue with my sdcard. Another issues happened some times, but it is another history.
Necro, but I think it is important to point out when things work.
I started having issues with the SD disappearing after suspend, which is a problem because I could not even open firefox afterwards.
Your solution worked for me. and I am now only one step to go to seeing my Librem 5 reach days and days of uption.
For the record, you should be able to drop that LUKS workaround with scsi: sd: Move ignore_media_change handling to sd_resume_common (!788) · Merge requests · Librem5 / linux · GitLab
That’s great news!
Is this already up, meaning that I can already disable the workaround on a fully updated standard byzantium install?
I had a look on the repository, but I am such a git n00b that I couldn’t tell based on merges and pipelines and etc…
No. It will likely be merged the next time Martin updates the kernel tree.
Perfect! I am looking forward to it! Thank you!
I’ve just tested the recent kernel update and it looks like this bug is really fixed! My test case is Waydroid with user data on sd-card. Previously, without my workaround, I got an i/o error after the first suspend. Now I’m able to suspend/resume several times without any issue! Thank you very much for so delicate work!
In fact, another issue with the display happen one time. Did you familiar with that? I mean the repeated messages like this:
March 23 10:11:34 pureos kernel: edt_ft5x06 2-0038: Unable to fetch data, error: -6
This should be printed once every time the screen blanks and is harmless. I’d only worry if it happened in other situations.
It floods my logs and the screen stays black. Sometime it is trying to on, I see a picture for a second or less, but finally it fails. Complete reboot fix the issue for a day or two.
OK, that’s not something I’ve ever seen. Did it start after some update? May be a hardware issue.
As far as I remember I observed it all time and reported here previously. And I can not recognize how the display bug may be connected with the touchscreen debug message…
The message means that the driver attempted to read the data from the touchscreen after receiving an interrupt, but couldn’t do so.
Since the touchscreen’s and the display’s power is shared, whenever the display is turned off, the touchscreen goes off too. However, currently the touchscreen driver isn’t aware of the display being turned off, so it gets an interrupt and tries to read from now turned off touchscreen. This obviously fails - and that’s why it’s currently expected to see such message when turning the screen off.
In your case, it would seem like your display module may experience some kind of power issues. You see a flood of messages because the interrupt from the touchscreen keeps firing - perhaps its power keeps browning out when in this state.
I’m afraid that this really smells like a hardware issue, you may want to replace your display, or at least check its connector.