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.
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
.
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.
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.
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.
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
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.
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
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?