The output is saying that it’s not set. You want “deep” to be selected. But s2idle is.
1 Like
@Andrew_Gallant Thank you for that information! I saw the word “deep”, and was ignorant of the syntax…
@Adrian_Sanabria I am actually having the same problem. Regardless of what version I use, it seems to (sometimes) pass the first enroll stage but then quit with that same error. Journalctl says fprintd[11235]: Device reported an error during enroll: Finger is too similar to another, try use a different finger. According to fprintd, there are no enrolled fingerprints though…
The weird thing is that Gnome showed the fingerprint option when I first installed Fedora, but after running dnf upgrade it no longer does.
Update: After correctly setting the sleep mode as described in my post above, starting with 100% battery charge and closing the laptop, 10 hours later the charge was reported as 90%. That’s a big improvement over my initial observations.
4 Likes
Good news. The new libinput RPM package 1.18.1 to fix the Framework touchpad issue is available on Fedora 35. On Fedora 34, the libinput 1.18.1 RPM package is currently in testing status. It will be released around 1 week later. To install it earlier on Fedora 34, you can check this testing page. I also updated this thread’s wiki.
2 Likes
@Adrian_Sanabria @waocats I had similar errors after installing Windows to debug the trackpad issue. I was able to work around it by enabling the fingerprint login in Gnome (although I couldn’t enroll a fingerprint), then disabling fingerprint login and then reenabling it again. My guess is that since the fingerprint reader is a match on device chip there might have been some logic that needed to get reset after reinstalling an operating system. You might give that a try and see if that resolves your error.
Can anyone chime in on how long it takes their laptop to resume from S3/deep suspend?
For me on Fedora 34, kernel 5.13.8-200.fc34.x86_64:
Suspend: almost instant
Resume: around 13-15 seconds to resume (from S3/deep). This seems somewhat slow, is this in line with how long it should take?
I looked through some diagnostics with
https://github.com/intel/pm-graph and looked at dmesg/journal, but couldn’t find any culprits (yet), but I may be reading them incorrectly.
Semi side-note:
Fedora’s S2Idle resume is instant, but I think it’s using S1 sleep state. Tested in Windows and it’s instant also, but the modern standby feature I believe uses S0ix, not S1.
Linux should be able to S2Idle using S0ix to achieve discharge rates similar to Windows modern standby, if I’m gathering my info correctly, but support/implementation seems shoddy all around, and doesn’t seem to be working correctly on Framework yet (F34, 5.13), due the seemingly high discharge rates.
Saw that 5.14/5.15 are supposed to help, at least with AMD chips. Further insight would be appreciated!
2 Likes
I don’t have my Framework laptop yet, but resuming from deep suspend should be nearly instant. It might take another few seconds for WiFi to connect, but 13-15 seconds is definitely not normal. Or at least, shouldn’t be considered acceptable.
When I’ve had problems in the past, pm-graph is what has bailed me out. If that isn’t working for you, then I’m not quite sure where to go from there.
Here’s a guide from Intel that talks about debugging steps: http://web.archive.org/web/20210302014224/https://01.org/blogs/rzhang/2015/best-practice-debug-linux-suspend/hibernate-issues
1 Like
After more regular use of Fedora on my laptop, I can safely say that around 80% of battery charge my laptop cpu usage increases to about 30% and the entire experience becomes significantly slower. Has anybody else encountered this issue?
Thanks for the link! I did some more digging/reading, and then realized I overlooked the portion between Kernel Suspend Time and Kernel Resume Time – I ran:
sudo ./sleepgraph.py -m mem -rtcwake 15 -mindev 1 -dev
The -rtcwake 15 option wakes the laptop 15 seconds after suspend.
In the image below, both Kernel Suspend Time and Kernel Resume Time look fine, but I noticed the center mem time is ~26 seconds. Mousing over mem time, it says it’s the time spent in low-power mode with the clock running, of which I assume is just the total time spent suspended in memory.
So 26 seconds spent in memory means that, with the 15 second delay until the rtcwake signal, 11 seconds is spent in, I’m assuming, the firmware? until the kernel resumes.
(26 seconds mem time - 15 seconds until rtcwake = 11 seconds after rtcwake signal)
11 seconds plus the 1.2 seconds in Kernel Resume Time equals 12.2 seconds total to resume from S3/deep suspend. This matches about how long it takes to resume after a suspend, when I press the power button.
Note that when I run analyze-suspend.py, I get
WARNING: /dev/mem is not readable, ignoring DMI data
and
sleep-graph.py/sleepgraph, I get
WARNING: /dev/mem is not readable, ignoring the FPDT data
I did some Googling, and FPDT is the Firmware Performance Data table, and since it can’t be read with pm-graph (or at least I don’t know how), I can’t figure out why exactly it’s spending ~10seconds in the firmware on resume from suspend.
Is there a way to see a breakdown of what’s happening within mem time?
Also, seems some support was added in Kernel 5.12:
With Linux 5.12+ the ACPI FPDT table is being parsed on supported systems and exposed under /sys/firmware/acpi/fpdt/ .
Poking around,
> cat /sys/firmware/acpi/fpdt/resume/resume_avg_ns
> 12643760622
12643760622 nanoseconds ~= 12.649427013 seconds, matching the explanation above.
I’ve also tested:
- 5.14.0-0.rc4 rawhide kernel (same issue, and ran into some other oddities, probably cause rawhide haha)
- the latest Fedora Spin (F34-WORK-x86_64-LIVE-20210802.iso) booted from a USB stick, which resumed slightly slower probably running off USB.
Apologies in advance for the debug dump @Andrew_Gallant 
, but also some info directed to other Fedora/Linux/S3 suspend users/Framework!
Doesn’t happen on my end, have you checked what’s consuming that CPU usage via e.g. top, or perhaps if your clock speeds/frequencies lower (e.g. due to some power saving profile), increasing CPU usage? Difference between plugged in and on battery? Lots of unknowns here
1 Like
@Kevin_Anderson No luck here. I tried installing the Respin instead, which didn’t really help. The option did show up in GNOME again, but errored out each time.
On my second time trying it, it actually didn’t get an error right away and almost got to the end of enrolling, but then it said that it was being used by another process and then errored out again.
I tried rebooting, going into the fingerprint dialog multiple times, and had no luck getting it that close again. Seems to get an error immediately, saying “Failed to enroll new fingerprint” the moment I touch the sensor. Do you know of anything else you might have done?
@waocats so I’m not immediately sure what might be causing your problem but can you try running G_MESSAGES_DEBUG=all /usr/libexec/fprintd -t in a root shell and then try to disable fingerprint authentication, enable it, and try to enroll a fingerprint and provide the output from first shell? That might give us some places to look for problems.
Additionally if you could provide the output of fprintd-list <username> we can see if any of your fingerprints are enrolled.
@Michael_Wu The issue happens while I’m charging my laptop, and this happened before I installed auto-cpufreq. Installing this allowed me to finish my frequency of my computer, and when my laptop gets around 80% my cores decide to go below 2400 mhz (most of the time they go to 400 mhz)
@Jerry that’s odd, I’d recommend trying Fedora off a live usb, clean install, another distro, and/or a Windows installation as an easy way to rule out if it’s your Fedora installation/something you install that’s causing the issue.
Also, does a reboot fix the issue? I’ve seen a similar problem on an XPS 15 getting locked to e.g. 400mhz, at least on Windows 10, and requiring a reboot. Seemed like a bios/firmware issue on that model, but unsure.
@Michael_Wu Well I haven’t necessarilly tried restarting when my laptop gets to around 80%, but I can safely say that this issue is recurring after I shut down my laptop and charge it up as I’m using it. That is to say, every time I am using my laptop while charging it, my cpu freq goes down.
Just upgraded my laptop to kernel 5.13.9 and I got the same fail to switch root error that I had received beforehand. On my 5.13.7 update, it had just fixed itself eventually. Has nobody received this issue before on their laptop? Or in general?
@Kevin_Anderson I wanted to wait to report back, since I was getting a new input cover due to the touchpad issue with the first batch of laptops.
Turns out my fingerprint sensor must have been faulty, because the fingerprint sensor worked flawlessly after replacing the input cover. I had my suspicions about it, considering all of us have the same fingerprint sensor and it didn’t work regardless of what I used.
Now I just have one more problem, which is that my laptop seems to sometimes not wake from suspend. Even though it has battery, I will open the lid and find that the laptop just shuts itself off. Not sure what that’s about, but adding acpi_sleep=nonvs (which was suggested on StackExchange) in the GRUB settings didn’t work. Do you happen to know anything about this?
1 Like
@Jerry Are you on Fedora 34? Running Fedora 34 over here with kernel 5.13.12 as of updates yesterday, and the fingerprint can be easily enrolled under Settings → Users.
What kind of SSD/RAM are you using?
I just updated the original Wiki post to reflect the trackpad lag / vertical screen tearing issue solved here.
1 Like
Another “pro-tip” if you’re using wayland: XWayland apps (electron: slack, spotify, discord if you aren’t overriding with the ozone flag) are blurry (regardless of in-app scale) if you use a default scaling other than 1x due to a bug in Xwayland. It’s not too bad to go through each app individually and scale it up, rather than setting the global fractional scaling, and to change your system font size.
2 Likes