The dock is likely where this is falling down. Checking dmesg and journalctl would tell us for sure. Also, we recommend using the kernel provided in our guide.
Not sure you read my original post completely. The external display is working perfectly. It’s the laptop screen that’s having issues. It has been having this issue more frequently lately, and it happens when not plugged into the dock too.
I installed that custom kernel and it’s working better again, but as it only happens on occasion it’s hard to tell if it’s fixed or not.
1 Like
Understood, appreciate the clarification.
If it happens again, open a terminal and check dmesg for any insights as to what might be happening.
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.
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:'`
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
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?
@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:
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.
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.
sudo dnf update- Reboot
Give this a try.
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
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
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.
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.
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.
Had it again, and took a screen recording as well as filming the screen. Let me know if/how to share them with you.
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.
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.
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.