[RESPONDED] Framework 13th gen DIY Ubuntu - Screen super laggy (1FPS) on occasion

Framework Laptop 13 Linux
10

I’ve seen 6.5.10 Workstation and 6.5.11 Workstation as options when booting up, and selected them a few times to try to stay current, but on next boot it always defaulted back to selecting 6.5.2 Workstation Prerelease. My guess is that it has something to do with having installed the Fedora 39 Beta, as that was the recommended choice before the stable release. I haven’t seen a large “Update” button in the Store like on my Fedora 38 machine, so I’m not sure how to get it to default to the stable.

Here’s my output for the command. Looks like the firmware update I had to do earlier worked as it’s on 03.03

	Vendor: INSYDE Corp.
	Version: 03.03
	Release Date: 10/17/2023
	Address: 0xE0000
       product: AMD Ryzen 5 7640U w/ Radeon 760M Graphics
       vendor: Advanced Micro Devices [AMD]
       physical id: 4
       bus info: cpu@0
       version: 25.116.1
11

This sounds like [RESPONDED] Error waiting for DMUB idle: status=3.

If you can manage to get to a root shell, do you see those “DMUB” messages when you run dmesg?

12

@Max_Pearce_Basman once we have you sorted on the right kernel, please see above. This will be the next step if this is still happening. as Sharp points out.

Let’s get you sorted on the Beta:

13

When trying to run sudo dnf system-upgrade download --releasever=39 I’m getting Error: Need a --releasever greater than the current system version.
Presumably because I’m technically already on 39, just the Beta.

I already see and can boot into the normal Fedora 39 using the 6.5.11 kernel, as it appears as an option in the boot menu. My problem is that it isn’t the default choice.

Here’s /etc/default/grub if it helps

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true

GRUB_DEFAULT=saved might not be coming into effect because there isn’t a GRUB_SAVEDEFAULT=true entry which I saw in some tutorials online (maybe it defaults to false?)
I’m hesitant to touch grub without knowing more though. The simple sudo update-grub isn’t for Fedora and I’d rather not mess up my system by using a command I don’t understand.

14

Always worth backing up grub.

sudo cp /etc/default/grub /etc/default/grub.bak

If it all goes sideways, we can always have you chroot into the install and revert it back.

Also a good time to remind anyone reading this, backups are important.

@Max_Pearce_Basman your grub looks correct. And if you’ve been running sudo dnf update ongoing, you should be current (which should have you with 6.5.12-300.fc39.x86_64

  • Leave GRUB as is. :slight_smile:
  • sudo dnf update
  • Reboot

Give this a try.

15

Good call on the backups.
For context here are my boot options:

Fedora Linux (6.5.12-300.fc39.x86_64) 39 (Workstation Edition)
Fedora Linux (6.5.11-300.fc39.x86_64) 39 (Workstation Edition)
Fedora Linux (6.5.2-301.fc39.x86_64) 39 (Workstation Edition Prerelease)
Fedora Linux (0-rescue-<randomcharacers>) 39 (Workstation Edition Prerelease)

I have been staying up to date, and it still boots to 6.5.2
I’ve selected 6.5.12 manually, and while it works, upon restart or next boot it still defaults back to 6.5.2

16

Odd, should be booting correctly on a vanilla install. may be worth changing GRUB_DEFAULT=saved to GRUB_DEFAULT=0, then sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

Also worth applying this and rebooting:

sudo dnf upgrade --refresh

17

Thanks! That seemed to do the trick and I’m now on the right version. As for the stuttering screen, I ran sudo dmesg when it came up, which ended up just repeating

[drm:dc_dmub_srv_cmd_run_list [amdgpu]] *ERROR* Error queueing DMUB command: status=2

It did this both before and after resolving the update problem.
My ancillary graphical corruption/flashing issue also still occurs.

18

Just confirming, you are now seeing this on 6.5.12 with freezing?

As I re-read this, what is attached to your Framework and how is it attached? So I might try to replicate this.

I’ve seen issues with DMUB in the past, namely Debian.

But I have yet to have the stuttering experience you described. So I’d like to replicate the setup for replication on my end and potencially a bug report.

19

Yes, the two logs I recorded start with

[    0.000000] Linux version 6.5.2-301.fc39.x86_64

and

[    0.000000] Linux version 6.5.12-300.fc39.x86_64

respectively (the latter being one I recorded after resolving the boot selection).

What do you mean by attached? It didn’t happen to occur in the few times I was using an external monitor, and I just use the touchpad, so the laptop wasn’t attached to anything (except the network in an abstract way I suppose). Edit: The laptop might have been charging at the time if that’s relevant.

I’ll add more context, in case it helps.

Two of the times, it happened when I was on a graphically-intensive website (specifically connecting to virtual table-top software that renders lighting client-side).
One of the other times it happened while I was completing a complex equation in desmos. These don’t have much in common, so I don’t know that it’s anything more than a coincidence.

As mentioned I have two dmesg logs I saved. I tried putting them here but it’s beyond the character limit. If there’s a way to attach it let me know; it doesn’t seem to be a supported file type. I’ll also try to screen record if it happens again, as it’s hard to convey the “texture” of lag with just words.

20

Had it again, and took a screen recording as well as filming the screen. Let me know if/how to share them with you.

21

So with an attached display and without, appreciate the clarification.

I have not had success with trying to replicate this - attached display or merely internal display.

  • Try booting from a current ISO of Fedora 39 (latest release copy) on a USB key. It will be an older kernel, but, it will also be a clean environment. Try the problem website there.

  • If you are able to replicate it in the live environment as well, still seeing the DMUB messaging error in the logs, please file a bug report.

22

I was not able to find specific steps that could reproduce this issue, and continued to experience it intermittently for quite a while.

However I just realized I haven’t experienced it for several months now, which probably indicates that some update resolved the problem, and that this is worth posting as an update.

23

I am facing the same issue in my ubuntu 24.10 whenever i watch youtube videos in random occurances the screen goes 1 fps and only by rebooting the system fixes it. My specs are amd 7840u, 32gb ddr5 5600, and 1tb ssd sn850x all my drivers and firmware are up to date.

24

Update : setting automatic dim screen when idle 100% through terminal did the job for me. From what I found out is for some reason whenever any video is playing and during video if the laptop stays idle like no mouse movements or keystrokes sometimes the idle function enable and tries to dim the screen when video is playing which causes some issues followed by laptop being super laggy
terminal command :
gsettings set org.gnome.settings-daemon.plugins.power idle-brightness 100

25

This is drm/amd#3647. To avoid the problem, add amdgpu.dcdebugmask=0x10 to the kernel parameters. This disables PSR (Panel Self-Refresh).

2 Likes
26

Thanks for the actual fix for now the solution which I’ve applied is working good. But if the problem occurs again I will go with your steps and will update here

27

I am using your method now and updated the kernel parameters as my method didn’t work. I will update here if the issue is resolved or not.

28

Whether this is universal or not, I don’t know…

My situation: (DIY 16" with archlinux/kde)
I found my solution in
Settings>Display & Monitor>Adaptive Sync: never
It was set to auto, why it automatically decides to skip frames is probably a question for another thread.

29

your method works 100% after applying it the problem never occurred thanks a lot.