Sdcard becomes read-only after waking up from suspend

Hardware Librem 5
5

This read-only problem is very annoying. I also try to use my librem5 as a daily driver. As I drove with my car and Pure Maps and OSM Scout Server yesterday, the read-only problem happened as I stopped for 15 minutes. Maybe the plugged power to to the car socket did not get power in this time and a suspend happened. The librem5 display did not change any more while moving the car. After rebooting it worked again. I think this means, if you use the librem5 for navigating you must not enable suspend. (I will try that next time)

I wonder, that there are only so few comments to this topic. Because this topic is so annoying. Are there people, that do not face this read-only problem while using a sd-card and suspend enabled ? If so, which sd-card do you use ?

6

I use suspend for some weeks now as default. My SDcard remains writable after coming back from suspend:

purism@pureos:~$ mount | grep media
/dev/sda1 on /media/purism/6464-6631 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)
purism@pureos:~$ touch /media/purism/6464-6631/ttt
purism@pureos:~$ ls -l /media/purism/6464-6631/ttt
-rw-r--r-- 1 purism purism 0 Jul 24 09:39 /media/purism/6464-6631/ttt
7

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 ?

8

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.

9

I can confirm that it happens occasionally with the unencrypted ext4 partition too.

10

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.

2 Likes
11

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 :stuck_out_tongue_winking_eye:

3 Likes
12

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?

1 Like
13

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 :frowning:

1 Like
14

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.

8 Likes
15

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.

4 Likes
16

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

7 Likes
17

That’s great news!

1 Like
18

@dos @nerd7473

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…

2 Likes
19

No. It will likely be merged the next time Martin updates the kernel tree.

5 Likes
20

Perfect! I am looking forward to it! Thank you!

1 Like
21

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
3 Likes
22

This should be printed once every time the screen blanks and is harmless. I’d only worry if it happened in other situations.

1 Like
23

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. :frowning:

1 Like
24

OK, that’s not something I’ve ever seen. Did it start after some update? May be a hardware issue.

1 Like