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

Framework Laptop 13 Linux
8

Hi. Would like to remark that I’ve had this issue as well. Here’s my info:

Model: Framework Laptop 13 AMD Ryzen 7040 Series
Operating System: Fedora 39 Workstation Edition
Kernel: Linux 6.5.2-301.fc39.x86_64
Frequency: twice, 10 days apart, in the 16 days I’ve had it
Duration: until shutdown
Description: Debilitatingly bad refresh rate and delay. Starts happening in middle of use with no apparent triggering event.

What does’t fix it:

  • Closing all applications
  • Changing refresh rate or scale in display settings
  • Logging out

What does fix it:

  • Restarting
  • Powering off, and then back on

Quirks:

  • display doesn’t update while continually moving the cursor with the touchpad
  • display is less than 4fps when not moving cursor

I have only used my laptop without an external monitor so I can’t confirm whether it would be affected by the issue in my case. I didn’t have the foresight to run xrandr while it was happening, but here are the current results if it’s any help.

Screen 0: minimum 16 x 16, current 1503 x 1002, maximum 32767 x 32767
eDP-1 connected primary 1503x1002+0+0 (normal left inverted right x axis y axis) 280mm x 190mm
   1503x1002     59.85*+
   1280x960      59.94  
   1152x864      59.96  
   1024x768      59.92  
   800x600       59.86  
   640x480       59.38  
   320x240       59.52  
   1440x900      59.89  
   1280x800      59.81  
   1152x720      59.75  
   960x600       59.63  
   928x580       59.88  
   800x500       59.50  
   768x480       59.90  
   720x480       59.71  
   640x400       59.95  
   320x200       58.96  
   1368x768      59.88  
   1280x720      59.86  
   1024x576      59.90  
   864x486       59.92  
   720x400       59.55  
   640x350       59.77

I don’t know that it’s related, but just in case it is I’ll mention that sometimes when opening the laptop, portions of the screen flash white very quickly, however the cursor shows on top of the flashing area when moved over it. Which area is affected depends on the time, but it’s always a continuous wrapping band like the following (O being the white flashing area). My hunch is that it has something to do with pinched cables, but I don’t have a good understanding of how that would work, or why it wouldn’t affect the cursor.

+--------+    +--------+
|        |    |     OOO|
|  OOOOOO| or |OOOOOOOO|    
|OOOOOOOO|    |OOO     |
+--------+    +--------+

Repeated closing/opening with some gentle percussive maintenance fixes this after a few attempts.

9

Let’s get you up to current, you’re pretty behind. Should be at least 6.5.10-300.fc39.x86_64, but current is 6.5.11-300.fc39.x86_64.

Also, can I get the output from this:

sudo dnf install lshw dmidecode -y && sudo dmidecode | grep -A3 'Vendor:\|Product:' && sudo lshw -C cpu | grep -A3 'product:\|vendor:'`
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.