Fedora 34 on the Framework Laptop

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 :sweat_smile:, 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

Liking F34 on my DIY version so far. Anyone know how to change the login screen resolution to match the desktop resolution upon login?

1 Like

@uhhmeeyell I’m running GNOME, and running this command set the login screen’s resolution, zoom, etc. to exactly what I see after login.

sudo cp ~/.config/monitors.xml /var/lib/gdm/.config/monitors.xml

1 Like

@gjason I just ran your command, but this only set the scaling to 100% (I’m running 125% scaling).

@Jerry I was running 100% and it worked for me, but I just tested it with the fractional scaling like you’re using and sure enough it didn’t work for me either. I verified that the file copied over correctly, so it must have something to do with the fractional scaling - it is, after all, an “experimental” feature. If I figure anything else out, I’ll let you know.

1 Like

Great news! I am happy to try it with Fedora.

Firefox 91.0.1 installed by the latest 20210831 respin was loading websites extremely slowly. Eventually I was offered an upgrade to 91.0.2 which fixed the problem.

EDIT: nope, still having this problem.

Ubuntu doesn’t, so it appears to be some kind of Fedora problem (as opposed to WiFi, router, DNS, etc)

@gjason @Jerry I believe in addition to copying the monitors.xml you will need to enable fractional scaling for the gdm user as well.

sudo su -
su - gdm -s /bin/bash
dbus-launch --exit-with-session dconf write /org/gnome/mutter/experimental-features "['scale-monitor-framebuffer']"

Then restart and verify gdm is scaled as expected.

1 Like

I have issues with external displays.
Disconnecting a display appears to break all of my USB ports until I restart the computer.

e.g.

  1. I can hotplug a regular USB device
  2. I connect a display. Works fine.
  3. I disconnect the display.
  4. The USB port is no longer functional.
    udevadm monitor reports no kernel events.
    xrandr also does nothing.
    dmesg doesn’t report any USB events.

The camera and microphone can disconnect and reconnect just fine though.

Audio over HDMI works on all displays I’ve tried except for one–a 4K Roku TV at my friend’s house.
Doesn’t matter what I do, enabling/disabling audio sources, increasing volume (both on laptop and on the TV)
The Roku TV doesn’t appear to receive an audio signal at all.