I am using Brave instead.
It behaves much better on Windows 10, but even there the browser gives some problems.
Just now, literally now, it was choking and dying because I was using a YouTube page with queued videos (I also have dozens of pages, but they’re not active, so there’s no reason why they should take up performance at all).
I can now also confirm the issue is still on my system in 6.16.5: I have not had it since 6.16 was introduced (and I use 6.16. since 6.16.1, quite some time). So either 6.16 changed something so that the likelihood of occurrences was drastically reduced, or it was reintroduced in 6.16.5.
I have already updated the ticket around AMD #4141.
@gilbert-fernandes if you allow the question, is your system still free of any such issue since 6.14.9? Without the amdgpu.dcdebugmask=0x10 in place? Keep in mind that if you just removed the amdgpu.dcdebugmask=0x10 from the configuration of the installed kernels, the system might re-introduce it later with the next kernel update if it was not removed from the defaults, without you knowing. If your system is really without amdgpu.dcdebugmask=0x10, did you do anything else in hardware or software or firmware that might made a difference?
In the bug ticket I see you indeed suffered from the error logs of AMD #4141, so I wonder if there might be something else that solved the issue in your case given that others still experience it, something that might help AMD to identify the origin. I am quite satisfied having to experience this atm just once or twice a month or so, but others seem to still have much more occurrences with amdgpu.dcdebugmask=0x10 being no long term solution. Thanks for your contributions again 
I had to switch back to Windows when this started happening. Checking back in now because I wanted to install F43, but according to that AMD #4141 ticket the problem still seems to persist. I assume it’s still on issue even on Fedora 43?
Does amdgpu.dcdebugmask=0x10 fully fix the issue? I thought I remembered reading somewhere that some people were still getting the freezing even after that, but maybe less frequently?
The issue is still not understood and thus can still occur, but it can be mitigated.
All of these cases I have reviewed contained indication, or even evidence, that they had a different issue but thought it was the same. In all cases in which we can say for sure that it was this very issue, dcdebugmask command mitigated. There is no guarantee of course as long as we do not fully understand the issue, but at this time, I feel quite confident given the many tests and feedbacks from different perspectives and different operating systems.
I use amdgpu.dcdebugmask=0x10 most of the time (still testing without occasionally), but I saw also that some people wrote to use amdgpu.dcdebugmask=0x12 . It seems both work.
I saw Arch already added this to the troubleshooting: AMDGPU - ArchWiki (see section 6.11 “Frozen or unresponsive display (flip_done timed out)”)
Given that Linux systems are usually more efficient than Windows in tests/comparisons, my expectation would be that even with PSR disabled (to mitigate the bug) Fedora is likely to be less power consuming than Windows. You might want to compare your Windows and your Fedora without PSR in your case before replacing the latter with the first 
I have reinstalled Fedora KDE 43, on a new SSD, so that the 2tb one is separated from the “OS and software only” new 250gb one.
~$ inxi -Fzxx
System:
Kernel: 6.17.7-300.fc43.x86_64 arch: x86_64 bits: 64 compiler: gcc v: 15.2.1
Desktop: KDE Plasma v: 6.5.2 tk: Qt v: N/A wm: kwin_wayland dm: SDDM
Distro: Fedora Linux 43 (KDE Plasma Desktop Edition)
Machine:
Type: Desktop Mobo: ASUSTeK model: PRIME B450-PLUS v: Rev X.0x
serial: <superuser required> part-nu: SKU BIOS: American Megatrends v: 3211
date: 08/10/2021
CPU:
Info: 6-core model: AMD Ryzen 5 5600X bits: 64 type: MT MCP arch: Zen 3+
rev: 0 cache: L1: 384 KiB L2: 3 MiB L3: 32 MiB
Speed (MHz): avg: 1738 min/max: 561/4654 boost: enabled cores: 1: 1738
2: 1738 3: 1738 4: 1738 5: 1738 6: 1738 7: 1738 8: 1738 9: 1738 10: 1738
11: 1738 12: 1738 bogomips: 88807
Flags-basic: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a
ssse3 svm
Graphics:
Device-1: Advanced Micro Devices [AMD/ATI] Navi 23 [Radeon RX 6650 XT /
6700S 6800S] vendor: ASUSTeK driver: amdgpu v: kernel arch: RDNA-2 pcie:
speed: 16 GT/s lanes: 16 ports: active: DP-2 off: DP-1
empty: DP-3,HDMI-A-1,Writeback-1 bus-ID: 09:00.0 chip-ID: 1002:73ef
Display: wayland server: Xwayland v: 24.1.9 compositor: kwin_wayland
driver: gpu: amdgpu display-ID: 0
Monitor-1: DP-1 model: Philips 27M2N8500 res: 2560x1440 dpi: 110
diag: 678mm (26.7")
Monitor-2: DP-2 model: Philips 27M2N3500AM res: 2560x1440 hz: 180 dpi: 109
diag: 685mm (27")
API: EGL v: 1.5 platforms: device: 0 drv: radeonsi device: 1 drv: swrast
gbm: drv: kms_swrast surfaceless: drv: radeonsi wayland: drv: radeonsi x11:
drv: radeonsi
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 25.2.5 glx-v: 1.4
direct-render: yes renderer: AMD Radeon RX 6650 XT (radeonsi navi23 LLVM
21.1.2 DRM 3.64 6.17.7-300.fc43.x86_64) device-ID: 1002:73ef
display-ID: :0.0
API: Vulkan v: 1.4.321 surfaces: N/A device: 0 type: discrete-gpu
driver: mesa radv device-ID: 1002:73ef device: 1 type: cpu
driver: mesa llvmpipe device-ID: 10005:0000
Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo
de: kscreen-console,kscreen-doctor wl: wayland-info x11: xdriinfo,
xdpyinfo, xprop, xrandr
Audio:
Device-1: Advanced Micro Devices [AMD/ATI] Navi 21/23 HDMI/DP Audio
driver: snd_hda_intel v: kernel pcie: speed: 16 GT/s lanes: 16
bus-ID: 09:00.1 chip-ID: 1002:ab28
Device-2: Advanced Micro Devices [AMD] Starship/Matisse HD Audio
vendor: ASUSTeK driver: snd_hda_intel v: kernel pcie: speed: 16 GT/s
lanes: 16 bus-ID: 0b:00.4 chip-ID: 1022:1487
Device-3: C-Media SADES Locust Plus
driver: hid-generic,snd-usb-audio,usbhid type: USB rev: 1.1 speed: 12 Mb/s
lanes: 1 bus-ID: 1-7:5 chip-ID: 0d8c:0012
API: ALSA v: k6.17.7-300.fc43.x86_64 status: kernel-api
Server-1: PipeWire v: 1.4.9 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin
Network:
Device-1: Realtek RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet
vendor: ASUSTeK RTL8111H driver: r8169 v: kernel pcie: speed: 2.5 GT/s
lanes: 1 port: e000 bus-ID: 04:00.0 chip-ID: 10ec:8168
IF: enp4s0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Drives:
Local Storage: total: 18.9 TiB used: 9.54 TiB (50.5%)
ID-1: /dev/nvme0n1 vendor: Kingston model: SA2000M8500G size: 465.76 GiB
speed: 31.6 Gb/s lanes: 4 serial: <filter> temp: 28.9 C
ID-2: /dev/sda vendor: Seagate model: ST10000NM0046 size: 9.1 TiB
speed: 6.0 Gb/s serial: <filter>
ID-3: /dev/sdb vendor: Mushkin model: MKNSSDEL2TB size: 1.82 TiB
speed: 6.0 Gb/s serial: <filter>
ID-4: /dev/sdc vendor: Kingston model: SA400S37960G size: 894.25 GiB
speed: 6.0 Gb/s serial: <filter>
ID-5: /dev/sdd vendor: Integral Memory model: V Series SATA SSD 250GB
size: 232.89 GiB speed: 6.0 Gb/s serial: <filter>
ID-6: /dev/sde model: SSD 512GB size: 476.94 GiB speed: 6.0 Gb/s
serial: <filter>
ID-7: /dev/sdf vendor: Western Digital model: WD20PURZ-85AKKY0
size: 1.82 TiB speed: 6.0 Gb/s serial: <filter>
ID-8: /dev/sdg vendor: Seagate model: ST4000DM004-2U9104 size: 3.64 TiB
speed: 6.0 Gb/s serial: <filter>
ID-9: /dev/sdh model: SSD 512GB size: 476.94 GiB type: USB rev: 3.1
spd: 5 Gb/s lanes: 1 serial: <filter>
ID-10: /dev/sdi vendor: SanDisk model: Cruzer Glide size: 28.65 GiB
type: USB rev: 2.0 spd: 480 Mb/s lanes: 1 serial: <filter>
Partition:
ID-1: / size: 195.78 GiB used: 78.87 GiB (40.3%) fs: btrfs dev: /dev/sdd2
ID-2: /boot size: 5.68 GiB used: 508.4 MiB (8.7%) fs: ext4 dev: /dev/sdd3
Swap:
ID-1: swap-1 type: zram size: 8 GiB used: 8 KiB (0.0%) priority: 100
dev: /dev/zram0
ID-2: swap-2 type: partition size: 31.25 GiB used: 0 KiB (0.0%)
priority: -2 dev: /dev/sdd1
Sensors:
System Temperatures: cpu: 41.0 C mobo: N/A gpu: amdgpu temp: 30.0 C
mem: 26.0 C
Fan Speeds (rpm): N/A gpu: amdgpu fan: 0
Info:
Memory: total: 16 GiB available: 15.52 GiB used: 7.4 GiB (47.7%)
Processes: 475 Power: uptime: 3h 4m wakeups: 0 Init: systemd v: 258
default: graphical
Packages: pm: rpm pkgs: N/A note: see --rpm pm: flatpak pkgs: 21
Compilers: N/A Shell: Bash v: 5.3.0 running-in: konsole inxi: 3.3.39
Gonna see how it goes.
Since I started using a SWAP partition not only the system never stuttered hard, or froze, again, but it never even rebooted.
It seems that “ZRAM” is not good enough, for whatever reason.
@isaac0clarke I am not sure if you mixed up topics or so This topic is about an issue related to an AMD graphics function in the kernel. While every process/means could be able to trigger the bug in some circumstances, it is itself not related to zram, swap or brave. The only reliable mitigation so far is disabling the PSR function of the kernel, and wait for the AMD upstream ticket to find a solution or the bug to disappear on itself. It proves a tricky one. So please remain focused on the topic
I’ve probably made a mistake.
If so, I’m sorry.
No worries