Fedora 39 on the Framework Laptop 13

Looking into the original post now. Vanilla kernel 5.6.5, Debian unstable. Okay, not seeing Fedora listed or the current kernel that comes with.

I am running Steam games (nothing AAA), but using Proton and whatnot. Using the Steam client provided in the Software Store (via rpm-fusion - flatpak also worked fine) set up during install, all looks good there. Touch pad was also super responsive.

Toggling this over to iGPU Mode to Game Optimized. I honestly did not see any difference. That may be me, it may be something with your specific laptop. Not sure.

What also strikes me is that you indicated you see visual artifacts on resume, I do not.

  • Updates today, always update as it’s a pre-release and updates are fast and furious right now.
  • I’m on kernel 6.5.6-300.fc39 which is current at the time I am writing this.
  • I am on Wayland.

Can you compare with what I have above?

EDIT: Just to clarify that this testing is on battery vs plugged in. Am noticing now that there is a difference.

So I have been messing around with it myself. The perceived cursor choppiness seems to be more related to using Power Saver mode vs Balanced. Probably has something to do with the GPU clocks not ramping up fast enough. I tried installing a dynamic triple buffering patched mutter via COPR repo which seems to have made it better. Went back to stock to continue testing with the same setup as you.

Also the choppiness is only on Wayland, I noticed with X11 the cursor feels smoother closer to what you’d get on Windows. Currently I set up a dual boot to test back and forth.

The iGPU Auto vs Game Optimized seems to have been placebo affect or unrelated.

Here are some of the error messages I am getting with journalctl -f:

Oct 11 18:14:07 framework-13 kernel: [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* wait_for_completion_timeout timeout!
Oct 11 18:14:17 framework-13 kernel: [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* wait_for_completion_timeout timeout!
Oct 11 18:14:27 framework-13 kernel: [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* wait_for_completion_timeout timeout!

Also I noticed some intermittent hard crashes / issues seemingly GPU related. One time trying to launch Obsidian and the other trying to launch Telegram (both installed via flatpak):

Oct 11 20:48:38 framework-13 md.obsidian.Obsidian.desktop[8041]: [67:1011/204838.575775:ERROR:shared_context_state.cc(898)] SharedContextState context lost via ARB/EXT_robustness. Reset status = GL_INNOCENT_CONTEXT_RESET_KHR
Oct 11 20:48:38 framework-13 md.obsidian.Obsidian.desktop[8041]: [67:1011/204838.576044:ERROR:gpu_service_impl.cc(1010)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly.
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 md.obsidian.Obsidian.desktop[8041]: [13:1011/204838.595552:ERROR:gpu_process_host.cc(954)] GPU process exited unexpectedly: exit_code=8704
Oct 11 20:48:38 framework-13 flatpak[8249]: amdgpu: The CS has been rejected (-125). Recreate the context.
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 flatpak[8249]: amdgpu: The CS has been rejected (-125). Recreate the context.
Oct 11 20:48:38 framework-13 flatpak[8249]: amdgpu: The CS has been rejected (-125). Recreate the context.
Oct 11 20:48:38 framework-13 flatpak[8249]: amdgpu: The CS has been rejected (-125). Recreate the context.
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 flatpak[8249]: amdgpu: The CS has been rejected (-125), but the context isn't robust.
Oct 11 20:48:38 framework-13 flatpak[8249]: amdgpu: The process will be terminated.
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 kernel: [drm] Skip scheduling IBs!
Oct 11 20:48:38 framework-13 systemd[2609]: dbus-:1.1-org.telegram.desktop@0.service: Main process exited, code=exited, status=1/FAILURE
Oct 11 20:48:38 framework-13 systemd[2609]: dbus-:1.1-org.telegram.desktop@0.service: Failed with result 'exit-code'.
Oct 11 20:48:38 framework-13 systemd[2609]: app-flatpak-org.telegram.desktop-8235.scope: Consumed 3.068s CPU time.
Oct 11 20:48:39 framework-13 systemd[2609]: Starting tracker-extract-3.service - Tracker metadata extractor...
Oct 11 20:48:39 framework-13 systemd[2609]: Started tracker-extract-3.service - Tracker metadata extractor.
Oct 11 20:49:23 framework-13 kernel: i2c_designware AMDI0010:00: i2c_dw_handle_tx_abort: lost arbitration
1 Like

Just to clarify your update status as I did not catch the kernel or how up to date you were?

Additionally, sounds like we ventured outside of vanilla installation which will be difficult reproduce. Let’s start off making sure you’re on the latest and greatest updates/kernel.

Guys who was able to reproduce this issue on Framework Laptop 13 AMD, if you have spare time, I hope you create your account on Fedora Bugzilla, and then file the bug to the Fedora Bugzilla, and please let us know the bug ticket URL in this thread.

https://bugzilla.redhat.com/ - Click New or File a Bug, then select Product: Fedora. If you don’t know the component, you can add the most possible component such as kernel and etc, then someone may change the component to a proper one.

I also had this issue, but on Fedora 38 (haven’t upgraded yet). I was able to slow it down with libinput-config (I had to set the factor to 0.2 to be comfortable) but that took a while to find, would be nice to have a Framework guide on this at least

Not sure if I did this properly, but here you go:
https://bugzilla.redhat.com/show_bug.cgi?id=2244221

1 Like

Thanks for your leadership!

No worries! So I have been experiencing some intermittent application crashes / GPU resets. Do you want me to file bugs for those too, or would I have to file them on the amdgpu gitlab?

1 Like

Yes, I want you to do.

If you can specify the upstream project (amdgpu gitlab), in my opinion, filing the bug on the upstream (amdgpu gitlab) first, then filing the bug on the Fedora Bugzilla referring to the filed upstream amdgpu bug ticket link is the best way. But I hope that you follow your intuition to decide what the best way is!

Thank you!

What’s very odd to me is other than the x11 → logout → wayland issue, I’m now not seeing anything like what I was having problems with to reproduce and report. Even the fwupdmgr issue resolved it self…no amdgpu issues…I didn’t update anything either… I’ll be filing bugs as I see them, though.

1 Like

i am also experiencing this. very choppy and weird.

i’m also experiencing an issue with youtube. some videos play fine in firefox, but others give me this error "An error occurred. Please try again later. (Playback ID:xxxxxxxxxxx). this is my first time using fedora, and linux in general outside of my steamdeck, any help with this youtube issue would be great.

If you are using flatpak version of firefox you need ffmpeg to support all the codecs. It is annoying that firefox dont prompt you about this.

flatpak install org.freedesktop.Platform.ffmpeg-full

https://www.reddit.com/r/firefox/comments/tejbru/solution_for_the_flatpak_version_of_firefox/

1 Like

@Cheng thanks for that. i popped that into terminal and installed the latest version, but it still doesn’t work. i closed and reopened firefox and restarted the laptop but it still wont play the videos.
sorry to be a total noob, but am i missing something? is there something else you need to do?

@demounit Do you mind checking in app store (by right-click on the app and select “app detail”, or go directly to the app store and search Firefox), whether you installed the flathub version or fedora version of firefox.

If you use the fedora version, do you mind installing and trying the flathub version? You don’t need to remove the fedora version if you don’t want to, just select flathub from the drop-down and click install. If you don’t see flathub as an installation source, you will need to run

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

However, if you follow the default installation recommendation for F39, it should include flathub as a source.


Fedora is very cautious to let their software even connect to proprietary software/codecs. Fedora version of firefox won’t connect to ffmpeg, since it supports proprietary codecs IIRC, even when ffmpeg is open-source.

In the guide, it says that the preferred method of installation is backing up the home directory and doing a clean install of Fedora 39 - why is this? It seems like getting things set up again, installing my extensions, logging into my apps, getting hardware acceleration and HEVC working, etc. with a clean install will probably take me a while, so I’d just like to know why this is the recommended procedure.

I can answer this - because it just works.

Now, will it work if you make absolutely sure you’ve fully updated F38, following upgrade to new release procedures? Should, yes. But guess what happens if it doesn’t - you end up doing a clean install anyway.

On any OS, I’ve always advocated for clean installs as they remove any little surprises that come along. That said, I have never had a problem with upgrading Fedora to new releases in recent years, but I have with other distros multiple times.

Tltr: Upgrade however best suits you, but, do have a backup of your data ahead of time. That’s just a good practice. If the update fails for some reason, you will be glad you have this in place.

1 Like

Confirmed Fedora 39 Workstation, updated, no longer defaults to X11 - it defaults to Wayland.

I still have to do the X, logout, login to wayland dance with the latest updates.

I also still have the issue. Fully Stock Fedora 39 and fully updated. Are you on the newer BIOS 3.03 whereas all of us are still stuck on 3.02?

Mario from AMD commented on my bug saying the updated BIOS would potentially fix the issue:
https://bugzilla.redhat.com/show_bug.cgi?id=2244221

Ah ha! Yes, Mario is indeed from AMD. I have another unit with the other BIOS on it. Will test it tomorrow and comment on the Bugzilla issue.