[…] With that understanding [of the SD card unresponsive on resume bug], Sebastian simply moved the relevant logic from the runtime-suspend path to a common path that applies to both types of suspend. We’re validating this fix and will roll it out to Byzantium and Crimson when we’re confident that there are no side effects.
This brings us one step closer to enabling suspend by default without limitations, which will make the Librem 5 run longer, cooler, and with more responsiveness.
Thank you to Purism and everyone involved for this development and writeup! Your continued dedication to making the Librem 5 better and better is appreciated !
There is a small typo in the “Changing cards” section:
- The phone must off to eject or insert the tray if there is a SIM card installed.
+ The phone must **be** off to eject or insert the tray if there is a SIM card installed.
Although it’s nice that the power consumption issue is looked at, I hope that work on suspend feature doesn’t distract from the main issue of working on Crimson.
The article primarily focused around the technical details of the SD card bug, however, they do mention that they were working on Crimson in parallel. I chose to quote/highlight the primary focus of the article, though I can understand the concern from how I communicated this.
Nah, I was referring to the original article and the work described there - suspend and SD card are related but still extra features. We’ll see how all the 100 issues and various milestones progress…
I’m glad to see the progress on Suspend. It will be nice to get the phone up to Crimson in the future though. My phone is working great for me on Byzantium, but it would be great to get the Librem 5 on Crimson (Debian 12), since Debian 11 will only be supported for so long.
Agreed. And one should note that this was “fixed” with a change to the mainline kernel.
[from the article] With that understanding, Sebastian simply moved the relevant logic from the runtime-suspend path to a common path that applies to both types of suspend. We’re validating this fix and will roll it out to Byzantium and Crimson when we’re confident that there are no side effects.
That, of course, brings up the question of whether that change to the kernel driver ( drivers/scsi/sd.c ) will be upstreamed to the mainline kernel. It’s not 100% clear to me that this “fix” won’t have repercussion in the more general kernel landscape and, so, may not be accepted.
This change for the runtime resume path has been upstreamed by Martin years ago. If it was accepted in runtime resume path, I don’t see why it wouldn’t in system resume path either.
That said, I’m not yet convinced that the way this (already existing in mainline) codepath does things is the best possible way to deal with this issue and I want to try a different approach first before taking this fix upstream.
Thanks to all who worked on the improvements, and also to all who financially contribute to this by having a pure optional PureOS subscription.
I enjoyed reading the update and seeing the continual updates and support for the Librem 5. Also I’m happy to see the steady monthly updates since July 2024. I’m looking forward to the next report!
I saw you mention somewhere that the SD card issue had nothing to do with suspend to RAM.
A while back, suspend stopped working on my phone (my fault) and rather than try and fix it, I kinda just said screw it and turned the Suspend feature off.
I have my SD card mounted and then bind mounted to a few places. One of those bind mounts contains my squeekboard YAMLs.
I used to notice the SD card issue quite frequently by seeing the squeekboard keyboard revert to the default layout. By frequently, I mean every day or so, sometimes 1-2 times per day.
Since I disabled suspend, I have seen this issue exactly zero times, and we are going on 5 months now this way.
I am saying this not because I doubt you saying the issue is unrelated to suspend, but because my anecdotal evidence since otherwise, and I’m kinda curious if you have any other insight on what could/have been my problem.
I found what I was thinking of, it was this comment. I think I misread you - your words were “unrelated to usb suspend”, which I took to mean all of suspend to RAM, not just the USB device.
Thank you for your efforts on this bug, really.
Also noticed a TON of activity in the Gitlab this past weekend, it’s great to see.
Ahah just for smile
I asked DeepSeek to explain it in a simple way like to explain it to a children!
Here:
Imagine your Librem 5 phone is like a superhero that sometimes takes naps to save energy (battery). But when it wakes up, it used to get confused with its SD card (the “memory card” where you save photos and games).
Here’s what used to happen:
The Nap Problem:
When the phone woke up from its nap, the SD card would become invisible for a moment. If you tried to use it right away (within 1.5 seconds), the phone thought: “Oh no, someone swapped the SD card while I was sleeping!” (even though they didn’t).
Result: The SD card stopped working until you restarted the phone.
Why Did This Happen?
The SD card reader (the “slot” where you put the card) is connected to the phone with an invisible USB cable inside the phone.
When the phone sleeps, the SD reader sleeps too. When waking up, it panics: “Maybe there’s a new card!” and freezes for safety.
How They Fixed It:
A smart scientist named Sebastian figured out they just needed to teach the phone to tell the SD reader: “Relax, it’s the same card! You can work again!” right after waking up, instead of waiting.
Now, even if the phone wakes up suddenly, the SD reader doesn’t panic and works right away!
What This Means for You:
The phone can take more naps (save battery) without issues.
It lasts longer, stays cooler, and doesn’t freeze when you use it!
Bonus: They also added magic to make external SD cards (the ones you plug in with an adapter) work better.
Moral of the story: Sometimes the SD reader just needs a little hug to feel safe!
Ahah that’s so great! Honestly I use AI to simplify (with success!!) some difficult text when I need it!
More like 30 issues. I guess most other issues are not that important for Crimson itself, but to improve software in general and so they could be added after Crimson release. Just a guess.
Additional to the work itself, I also want to thank for the monthly transparency and enjoy to read all such posts.