This has also helped with a friend of mine who took a Fedora 38 drive and upgraded it to Fedora 39 in their FW13 going from Intel to AMD.
1 Like
Hmm, running through the multimedia steps mentioned by rpmfusion seems to disable HDMI output via my expansion card in Slot 1 though…
Odd, should not affect this. Try running journalctl -f while plugging and unplugging in your HDMI cable. I suspect this could be a bug somewhere.
Copy the latter output here.
It seems that it’s not even showing up in journalctl when I unplug and plugin my new HDMI cable to my monitor now. Odd…
Nov 29 18:41:32 fw13amd jottad[2544]: pid:2544 2023/11/29 18:41:32 Starting download of 1 files
Nov 29 18:41:43 fw13amd systemd[1]: systemd-timedated.service: Deactivated successfully.
Nov 29 18:41:43 fw13amd audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-timedated comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 29 18:41:43 fw13amd audit: BPF prog-id=90 op=UNLOAD
Nov 29 18:41:43 fw13amd audit: BPF prog-id=89 op=UNLOAD
Nov 29 18:41:43 fw13amd audit: BPF prog-id=88 op=UNLOAD
Nov 29 18:41:56 fw13amd geoclue[2229]: Service not used for 60 seconds. Shutting down..
Nov 29 18:41:56 fw13amd systemd[1]: geoclue.service: Deactivated successfully.
Nov 29 18:41:56 fw13amd audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=geoclue comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 29 18:41:58 fw13amd realmd[2351]: quitting realmd service after timeout
Nov 29 18:41:58 fw13amd realmd[2351]: stopping service
Nov 29 18:41:58 fw13amd systemd[1]: realmd.service: Deactivated successfully.
Nov 29 18:41:58 fw13amd audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=realmd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Nov 29 18:42:01 fw13amd systemd[2514]: Starting gvfs-metadata.service - Virtual filesystem metadata service...
Nov 29 18:42:01 fw13amd systemd[2514]: Started gvfs-metadata.service - Virtual filesystem metadata service.
Nov 29 18:42:02 fw13amd systemd[1]: pcscd.service: Deactivated successfully.
Nov 29 18:42:02 fw13amd audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=pcscd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
This is definitely odd. Even if it shows a blank screen, you would absolutely see some sort of activity of some sort in the journal unless the cable or card is bad. For example, I have seen failures where it shows the expansion card and indicates something like mtp-probe[10166]: bus: 1, device: 14 was not an MTP device which leads to [drm] enabling link 4 failed: 15 - these would be failures I might expect. But seeing nothing in the journal at all tells me it’s not sending or receiving somewhere.
The last time I have seen this (different machine, a PC tower), I resolved this with a different cable.
The other thing I’d try is to verify the expansion card is being seen (as I feel like this is either expansion card or cable at this point).
lsusb
And if this was a confirmed good cable from the other computer, this may be a bad HDMI expansion card.
Quick note, the test video en/decode firmware posted in the upstream bug thread has so far resolved the video playback stutter/dmesg error problem for me.
Looking forward to it being released officially and eventually rolling out as an update to amd-gpu-firmware.
1 Like
Using the test VCN firmware as noted by Dimitris, this has resolved the freezing for me as well.
I suspect there could be some relation here as, good stuff by Dimitris - appreciate this. Always difficult when we cannot replicate in-house, so the help is appreciated.
Ideally, we want to wait until it rolls out officially in the updates, however if you are FULLY UPDATED/rebooted and still seeing the issue, this may be worth trying:
Remember, this is super not official and try at your own risk in terms of stability.
framework 13 AMD Ryzen 5 7640U
fedora 39 - Wayland - Kernel 6.6.9-200 - RPM Firefox 121.0
I solved this issue by adding amd_iommu=off to kernel via grubby.
1 Like
Had to recently sudo dnf distro-sync -y && sudo dnf upgrade --skip-broken but then after a reboot sudo dnf upgrade replaced the previously broken freeworld packages as it was supposed to.
Am now on 6.6.11 with no issues with any sort of display oddness.
1 Like
Once you have a video you can reproduce you can use about:config to modify “media.mediasource.vp9.enabled” to false. Note: this may change the available resolutions in playback.
Thank you for this noob (me) friendly solution for the default installed RPM Firefox, I did struggle to see this on the thread and it’s the only thing that worked for me.
3.03, fresh install Fedora 39, followed both Howto/Multimedia - RPM Fusion and Installing plugins for playing movies and music :: Fedora Docs & 3rd party repo’s enabled.
I was having the same problem on the RPM Firefox with giltchy video playback which also caused a crash. Flatpak Firefox was able to play VP9 encoded video without issue however not AVC1. Thanks all.
2 Likes
For me I am currently doing:
To fix the white screen / white block issue:
amdgpu.sg_display=0
Codecs (probably distro specific):
RemovedBasePackages: libavfilter-free libavformat-free libpostproc-free libswresample-free libavutil-free libswscale-free libavcodec-free 6.0.1-2.fc39 mesa-va-drivers 23.3.6-1.fc39
LayeredPackages: ffmpeg ffmpeg-libs libva-utils mesa-va-drivers-freeworld rpmfusion-free-release rpmfusion-nonfree-release
VP9 (disable in firefox):
about:config
media.mediasource.vp9.enabled = false
1 Like
Yep! The actual mesa issue was linked above here:
But it’ll still take time to trickle down.
The white screen / white flashes issue isn’t related to the vp9 issue though so amdgpu.sg_display=0 would still be needed for those of us affected.
1 Like
Quick note, AMD firmware update with VP9 playback stutter fix incoming on Fedora.
Edit: don’t be like me - after updating the firmware packages (pretty much *-firmware-*, or at least amd-gpu-firmware), remember to run dracut --force to update the boot image before rebooting, otherwise the new firmware will only be begin being used with a new kernel install.
That little oversight aside, this fixes the video stuttering problems 
1 Like
The update has also just dropped in the Arch repos and videos in Firefox now play perfectly on my machine!
I’m running a fully up-to-date Fedora 39 with Firefox on my AMD Framework 13. No kernel parameters set. I have set up RPMFusion and enabled hardware acceleration (see here and here. Next to that I updated the BIOS 3.05.
Both before and after the BIOS update, it happens that my whole machine freezes. journalctl gives the following output:
Apr 19 19:52:30 framework kernel: gmc_v11_0_process_interrupt: 63 callbacks suppressed
Apr 19 19:52:30 framework kernel: amdgpu 0000:c1:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:24 vmid:2 pasid:32775, for process firefox pid 4145 thread firefox:cs0 pid 4252)
Apr 19 19:52:30 framework kernel: amdgpu 0000:c1:00.0: amdgpu: in page starting at address 0x0000000000000000 from client 10
Apr 19 19:52:30 framework kernel: amdgpu 0000:c1:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00201430
Apr 19 19:52:30 framework kernel: amdgpu 0000:c1:00.0: amdgpu: Faulty UTCL2 client ID: SQC (data) (0xa)
Apr 19 19:52:30 framework kernel: amdgpu 0000:c1:00.0: amdgpu: MORE_FAULTS: 0x0
Apr 19 19:52:30 framework kernel: amdgpu 0000:c1:00.0: amdgpu: WALKER_ERROR: 0x0
Apr 19 19:52:30 framework kernel: amdgpu 0000:c1:00.0: amdgpu: PERMISSION_FAULTS: 0x3
Apr 19 19:52:30 framework kernel: amdgpu 0000:c1:00.0: amdgpu: MAPPING_ERROR: 0x0
Apr 19 19:52:30 framework kernel: amdgpu 0000:c1:00.0: amdgpu: RW: 0x0
Apr 19 19:52:41 framework kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, but soft recovered
Apr 19 19:52:41 framework firefox.desktop[4145]: [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate
Apr 19 19:52:41 framework gnome-shell[2785]: meta_wayland_buffer_process_damage: assertion 'buffer->resource' failed
It is not hard to reproduce: I simply have OpenStreetMap open and toy around a bit, especially zooming in and out seems to trigger the error. The error and behaviour seems very similar to the initial error reported in this thread. Is there anything I can do to debug?
