Sdcard becomes read-only after waking up from suspend

Hardware Librem 5
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
25

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…

1 Like
26

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.

4 Likes
27

Thanks a lot for so detailed explanation! I also have another idea about this issue - i2c bus can be locked by some random spikes… I’ve found one confirmation for that. In fact, imx-i2c driver has a workaround, but it does not work in our case as soon as it not configured in the dts file. I’ve try to fix it and my four-hours test is very positive! I will look further and write more detailed description of my investigations :slight_smile:

2 Likes
28

spikes don’t sound wrong, the interrupts have to come from somewhere when the TDDIs are asleep right?
Or are there other participants on the I2C?

1 Like
29

I meant random spikes from environment caused by electrostatic discharges which can be considered as start/stop conditions of an I2C bus. This link reveals the problem for another circuit, but it looks like it is also valid for Librem5.

1 Like
30

I have an IMX9 here. I pulled the I2C to ground and the recovery seems to work. Does anyone know where a test point is located on the LM5?
Then I can test the recovery.
But spikes shouldn’t occur anyway. Do you have access to an oscilloscope?

2 Likes
31

Software I2C recovery is definitely disabled in Librem5 as far as the related GPIO pins are not configured. This is my patch to activate it. I believe @dos could examine and push it to upstream.

This is dmesg output after applying the patch:

$ sudo dmesg | grep i2c | grep sda
[    1.259563] imx-i2c 30a20000.i2c: using DT '/soc@0/bus@30800000/i2c@30a20000' for 'sda' GPIO lookup
[    1.259605] of_get_named_gpiod_flags: parsed 'sda-gpios' property of node '/soc@0/bus@30800000/i2c@30a20000[0]' - status (0)
[    1.276907] imx-i2c 30a30000.i2c: using DT '/soc@0/bus@30800000/i2c@30a30000' for 'sda' GPIO lookup
[    1.276956] of_get_named_gpiod_flags: parsed 'sda-gpios' property of node '/soc@0/bus@30800000/i2c@30a30000[0]' - status (0)
[    1.279998] imx-i2c 30a40000.i2c: using DT '/soc@0/bus@30800000/i2c@30a40000' for 'sda' GPIO lookup
[    1.280039] of_get_named_gpiod_flags: parsed 'sda-gpios' property of node '/soc@0/bus@30800000/i2c@30a40000[0]' - status (0)
[    1.283571] imx-i2c 30a50000.i2c: using DT '/soc@0/bus@30800000/i2c@30a50000' for 'sda' GPIO lookup
[    1.283615] of_get_named_gpiod_flags: parsed 'sda-gpios' property of node '/soc@0/bus@30800000/i2c@30a50000[0]' - status (0)

Finally, it is some kind of ESD protection. I have an oscilloscope but it wont help as far the issue occurs unpredictably during a day. But that is more interesting - I do not observed the display hangup anymore throughout the last three days! I’ve checked the logs. Sometimes a few messages about edt_ft5x06 error occurred in a row, but the phone remains fully functional.

2 Likes
32

I don’t know why your device appears to be particularly prone to such conditions, but enabling i2c recovery is a sensible thing to do. Your patch has missed some details though. I’ve posted an MR and credited you in its Suggested-by tag - thanks!

4 Likes
33

Thanks a lot! :pray:
Unfortunately, two weeks later I can conclude that it does not solve my problem completely, but now it appears much less frequently, only two or three times during the period I observed broken display while the phone is fully functional (volume keys, ssh, etc). Also I’ve checked the connector - it looks good. In addition, my charging issue still exists despite I replaced usb-c board to the new one. So, I’m waiting a chance to replace the main board, ideally, with a better spec. :slight_smile:

2 Likes