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 
1 Like
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
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
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
That’s great news!
1 Like
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
No. It will likely be merged the next time Martin updates the kernel tree.
5 Likes
Perfect! I am looking forward to it! Thank you!
1 Like
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
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
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.
1 Like
OK, that’s not something I’ve ever seen. Did it start after some update? May be a hardware issue.
1 Like
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
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
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 
2 Likes
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
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
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?
1 Like
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.
1 Like