1. Please describe the problem:

In order to test if I can reproduce AMD issue #4141 [1] with 6.16.0-0.rc3.31.fc43, I installed kernel-6.16.0-0.rc3.31.fc43 through dnf from koji [2]. While it is the first kernel in which I cannot reproduce #4141 actively/intentionally (unlike 6.15.3, in which I still can do so), I booted 6.16.0-0.rc3.31.fc43 twice: the first time, I could shutdown properly. The second time of 6.16.0-0.rc3.31.fc43, I could boot properly, but the screen froze when I clicked on shutdown (it already jumped to the terminal when it froze, but just three lines shown, I unfortunately did not save them).

However, after I did hard reset, I always ended up in the emergency mode, whatever kernel I was booting (6.14.*, 6.15.*): the first two times I reset I had a HDMI screen attached, the outcome was the emergency screen "Emergency-mode-after-boot-of-6.16rc3-with-external-hdmi-monitor.jpg", though I do not believe the warning on the emergency screen is related to the problem. In subsequent attempts (including the same kernels of the first two attempts but also other kernels too), I removed the HDMI screen and then had the emergency screen "Emergency-mode-after-boot-of-6.16rc3-without-external-hdmi-monitor.jpg".

Unfortunately, in the emergency mode, it was not possible to mount anything, including USB devices, so I could not save the massively long rdsosreport file but only make some screenshots of the journalctl of the emergency mode's boots: see the files journalctl-emergency-boot-* attached. In order to provide all possible information: I later booted a live system (f42 kde live) and tried to manually mount the btrfs root file system some times -> the mount attempts led to errors, and I also attached the very dmesg lines of a mount attempt in the live system (dmesg-log-after-mount-attempt-in-livesystem.txt), although I think this is only data about the broken btrfs and not relevant for the 6.16 evaluation.

The emergency mode had a kernel taint value of 128.

I CANNOT say for sure that the kernel broke btrfs, as theoretically this can happen at each hard reset. But I have had a lot of hard resets especially in the recent months due to AMD bugs and also in the recent years: given that the broken btrfs occurred when testing a 6.16.0-0.rc3.31.fc43 (I usually avoid rc on production systems for obvious reasons but I am maybe the only one who can currently intentionally reproduce the #4141 bug, so its worth it), and given that this impact is very high, I assume it is worth to be forwarded for your consideration: feel free to close the report if you think this occurred just on coincident or if the data does not suffice reproduction.

Important to note: the btrfs root fs is encrypted (dmcrypt). Beyond the btrfs, my system also has an XFS file system (not a system partition, only for data), but the XFS was not affected.

Hardware AMD Ryzen 7 PRO 6850U with Radeon Graphics, only internal graphics.

I am aware that this kernel is experimental, I had my backups in place.


2. What is the Version-Release number of the kernel:
6.16.0-0.rc3.31.fc43 running on a F42 KDE Spin (only stable repos), up to date as of today at the time of the occurrence. My system uses SELinux confined user accounts.

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
See above. I could once boot 6.16rc3 normally, and at the second time, btrfs root fs broke. Earlier, all kernels worked. After, none, given that btrfs was damaged.

4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
Not sure: I installed it using dnf (`dnf update <https links of koji packages>`), booted it, and then I tried to reproduce the AMD #4141 issue by adjusting the brightness with the mouse by putting brightness up and down in an analogue way. Then I shutdown.


6. Are you running any modules that not shipped with directly Fedora's kernel?:
If there are no kernel warnings or errors, my taint level is 0. Except the mesa drivers from rpmfusion, I use only software from the default repos of Fedora (I ensure to only contain the mesa packages and their dependencies from rpmfusion using the "includepkgs" option of dnf). I limit this system to what is installed through dnf. I use only stable repos (except I manually install and test a kernel using the koji packages, which I install through dnf). At the time of the incident, my system was up to date as of today based on dnf.

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.

[1] https://gitlab.freedesktop.org/drm/amd/-/issues/4141
[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=2737973


Reproducible: Always