Hello everyone. I apologize in advance if these kinds of posts are not allowed here. After updating to kernel v6.7.5, I’ve been experiencing the following problems:
my dGPU (AMD Radeon RX 6600) is no longer available to me (even though it appears on the System Details panel, as seen below) / as a result, my iGPU is constantly working
my computer will no longer suspend; suspending the computer once will wake itself up after 5’’ and doing it twice will disable all I/O (USB devices, screen etc) but the computer will still be running
Has anyone else experienced similar issues after updating to 6.7.5? Any advice would be really appreciated, thank you.
First, This is the right place for your problem. And even if it would be different, ask.fedora is the place to ask for if you don’t know where to go. At the worst, people here can help you finding out where to go. In either case you do not need to apologize
Second, before going into much elaboration, I suggest to check out if your problem was already solved in the next kernel (6.7.6). Please update your system with the following command [1]: sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-d16d94b00d
This command leads to the update to kernel 6.7.6, which is still in testing but was already successfully tested by several people. So it should be already fine to try it at this point given the issues you have with 6.7.5. However, keep in mind that this kernel is formally not yet released into the stable updates.
IF 6.7.6 does solve your issue, feel free to let us know and mark a solution here so that others know what to try when they experience the same or a comparable problem.
IF 6.7.6 does not solve your issue: Does the problem always occur when you boot 6.7.5 and 6.7.6? Does it also occur (always, sometimes or never) when you try again to boot the older 6.7.4?
Supplement: kernel 6.7.6 contains several fixes about AMD graphics (changelog 6.7.6). So there is a good chance that the dnf upgrade command above will solve the issue.
I just ran the command you posted above and rebooted my machine, but unfortunately the problem persists; the AMD dGPU is still not available to me and the computer still won’t suspend as intended.
IF 6.7.6 does not solve your issue: Does the problem always occur when you boot 6.7.5 and 6.7.6? Does it also occur (always, sometimes or never) when you try again to boot the older 6.7.4?
The problem always occur while on 6.7.5 and 6.7.6, so I suppose it would be better if I downgraded to 6.7.4 where the AMD GPU and suspend always worked, but I don’t quite know how. When I perform dnf list kernel --showduplicates, it shows I already have 6.7.4 downloaded and installed, so I don’t understand how to roll back to it.
The question is if 6.7.4 still works. E.g., sometimes many updates are
installed at once, and maybe it was another update that caused the
issue. If that would be the case, 6.7.4 would no longer work as well.
That’s why it is important to see if 6.7.4 still works properly.
I think for now, the easiest way is to boot your Fedora and immediately
reboot. If the boot takes less than (I think it was) 2 minutes, it will
ask you the next time you boot which kernel to boot. This is the easiest
way to switch kernels without much elaboration, just to find out how
different kernels behave.
Once you can choose the kernel at startup, there should be the recent
three kernels you can then choose from: 6.7.4, 6.7.5, 6.7.6. Try all
multiple times and check. Most important for now is if 6.7.4 still works
always (please test multiple times) properly while both later kernels
always fail.
IF your new test reveals that 6.7.4 still works always fine while the
later kernels always fail, then please provide the information as I
elaborated here:
I think for now, the easiest way is to boot your Fedora and immediately
reboot. If the boot takes less than (I think it was) 2 minutes, it will
ask you the next time you boot which kernel to boot.
Unless I’m doing something wrong, this method didn’t work for me… Rebooting takes less than 2 minutes, but I didn’t get anything after multiple restarts. I also tried pressing both Shift and Esc while booting to Fedora, but that also didn’t bring me to a kernel menu. I don’t mind using the Terminal, if there’s a better way of approaching this.
Do you use disk encryption by chance? If so, just kill the machine at the point when it asks for the password. Nothing is mounted with rw at this time so this is no problem. That should achieve the same goal.
If not, maybe someone else has time to give you a short elaboration how to enable the grub menu temporarily. Otherwise I will find some time tomorrow or the day after tomorrow.
However, you can also check in ask.fedora because I think we had that topic before: how to enable grub menu at boot (there should be some elaborations of that around; I’m quite sure I wrote some myself). The best way in these circumstances might be to change a config file within /boot/ manually because this will not be a permanent change but become undone next time you update the kernel.
you can also check in ask.fedora because I think we had that topic before:
I did in fact searched a little bit before responding, therefore having a little more confidence in using the Terminal. I ran sudo grub2-editenv - unset menu_auto_hide, got into the GRUB menu, chose 6.7.4 and the problem is now solved; my AMD dGPU appears as intended and I am able to properly suspend my machine.
Since 6.7.6 won’t be solving this issue, should I temporarily exclude kernel updates via sudo dnf update --exclude=kernel*? Thank you for all your help!
If 6.7.4 always works and both later kernels always fail, there is likely a kernel bug that needs to be solved. So in order to ensure that it gets solved soon, I suggest to file a bug. Please read my post here about how and where to file a bug: Fedora hangs on boot after upgrading to kernel 6.3.4 - #9 by py0xc3
Once you entered the product and component (see my post), a template will appear. Read it carefully and provide all related information. Also, add the information that the 6.7.6 from bodhi does not solve the issue as well.
Ask here if you have questions.
Keep watching the bug report because it is possible that developers will ask you questions and also that they provide suggestions about how to mitigate the problem.
Also, please link the bug report here! You might also link this topic in the bug report.
Be aware that sticking with 6.7.4 is not a long term solution. Thus the report.
You may be able to provide useful details of the problem for a bug report using journalctl in a terminal. You can compare error messages from previous boots using different kernels using the -b <N> option and priority (-p <N>) or search `-g . The easier you make it for developers to understand the issue and the reponsible component, the sooner you will get a solution or at least a workaround.
That’s indeed relevant, but already asked for in the template. I asked to carefully read and provide everything for the template because not providing the journal can cause the report to be not considered.
Thanks. I added a comment on both. In future, in such a situation, you should link the two reports. It’s relevant that both problems always occur together.
Let’s hope the issue is solved soon. In case your problem gets solved (may it solve itself or through help from the people at bugzilla), please let us know. Don’t forget to keep watching the two bug tickets.
I just skimmed your log and there is unintended behavior at amdgpu, which I expect to be the origin. That could be indeed a bug.
I assume this is a failed suspend:
Feb 26 15:49:17 kernel: [drm] PCIE GART of 512M enabled (table at 0x00000081FEB00000).
Feb 26 15:49:17 kernel: [drm] PSP is resuming...
Feb 26 15:49:17 kernel: [drm] reserve 0xa00000 from 0x81fd000000 for PSP TMR
Feb 26 15:49:17 kernel: amdgpu 0000:03:00.0: amdgpu: RAS: optional ras ta ucode is not available
Feb 26 15:49:17 kernel: amdgpu 0000:03:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
Feb 26 15:49:17 kernel: amdgpu 0000:03:00.0: amdgpu: SMU is resuming...
Feb 26 15:49:17 kernel: amdgpu 0000:03:00.0: amdgpu: smu driver if version = 0x0000000f, smu fw if version = 0x00000013, smu fw program = 0, version = 0x003b3100 (59.49.0)
Feb 26 15:49:17 kernel: amdgpu 0000:03:00.0: amdgpu: SMU driver if version not matched
Feb 26 15:49:20 kernel: amdgpu 0000:03:00.0: amdgpu: SMU: I'm not done with your previous command: SMN_C2PMSG_66:0x00000006 SMN_C2PMSG_82:0x00000000
Feb 26 15:49:20 kernel: amdgpu 0000:03:00.0: amdgpu: Failed to enable requested dpm features!
Feb 26 15:49:20 kernel: amdgpu 0000:03:00.0: amdgpu: Failed to setup smc hw!
Feb 26 15:49:20 kernel: [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block <smu> failed -62
Feb 26 15:49:20 kernel: amdgpu 0000:03:00.0: amdgpu: amdgpu_device_ip_resume failed (-62).
Feb 26 15:49:21 kernel: Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7
This is good in terms of there is indication the people at bugzilla can start with.
Thank you for commenting on the bug! And sorry for the poorly formatted bug report, it’s my first time doing so and I know some devs take issue with multiple inquiries on the same post, so I decided to separate them for the sake of brevity.
I hope they eventually address this bug! I had to do a fresh install of Fedora this morning, due to experimenting a little bit too much with testing kernels and scripts on my main work machine, so I’ll just stick with 6.7.5 for the moment, even though I cannot suspend my PC nor use my AMD dGPU.
Since this seems to be a kernel bug and not a configuration issue per se, should I just declare this issue as Solved in this thread?
No worries. I just want to help you to evolve/improve Everyone has started at some point. Your report is good for the first time because you indeed answered all questions and added the proper logs (I saw many reports where especially the latter was forgotten/ignored). So no need to sorry.
No. I am quite sure this is a kernel bug. But we have no evidence at this point. Also, whatever solves the issue (or at least mitigates it until a permanent fix is released) should be documented here for other people who may experience the same problem. So as long as the issue is not solved, leave it open but let us know if anything solves the issue (and if so, what).
However, be aware that the kernel maintainers have a lot of work and there are always many open bug reports. You can be lucky and someone makes it priority if it is assumed to be a wider phenomenon. But be aware that it might also take some time.
Very important is at this point to always keep your kernel updated and see if any new kernel solves the issue. So do not just stick with 6.7.4. E.g., it may happen that the issue is solved at another Linux distribution and thus gets solved in future kernels even if the bug report here has not yet been touched.
In order to ensure that your kernel 6.7.4 does not get deleted (usually, Fedora keeps only the recent 3 kernels), you should adjust the related config file and increase the numbers of kernels that are to be kept. Please read from this post to find out how to do that:
I suggest to do this immediately and always keep the number sufficiently high to keep 6.7.4 installed. Once a new kernel solves your issue, you can reduce the number back to 3, which then will at the next update remove the old kernels at once.
I assume here that you have a few GB of storage left on your device.
No worries. I just want to help you to evolve/improve Everyone has started at some point. Your report is good for the first time because you indeed answered all questions and added the proper logs (I saw many reports where especially the latter was forgotten/ignored). So no need to sorry.
Thank you so much for the encouraging words! I want to help Fedora and the Linux community as much as possible.
Yes of course, I’m currently up to date with 6.7.5 and will update to whatever comes next.
In order to ensure that your kernel 6.7.4 does not get deleted (usually, Fedora keeps only the recent 3 kernels), you should adjust the related config file and increase the numbers of kernels that are to be kept.
Unfortunately, since I did a fresh install this morning, my recent 3 kernels are gone and only have 6.7.5 in my machine. It’s okay, I will keep updating regularly and hope for this bug to be fixed.
Well, it should be possible to re-install 6.7.4 even if a later kernel is already installed, but it is indeed a compromise because both 6.7.5 and 6.7.6 are marked as security critical (I haven’t the time to check the exact background of that in terms of how far the security issues affect average users).
If you can sufficiently work with 6.7.5 and 6.7.6, I suggest to indeed stick with the newest kernels and keep responding to the bug reports if something comes up. Otherwise, let us know, maybe someone knows off the cuff how to install an older kernel since I wasn’t doing this for along time. But I can check the next days if necessary
This is not entirely true. Yes, Fedora keeps 3 kernels on the system by default, but one of those is the running kernel that you have when doing the update. This specifically keeps it from removing a known good kernel. So assuming you have 6.7.4, 6.7.5, and 6.7.6 installed, but you stay booted into 6.7.4 because the other 2 are broken, when you update to install 6.7.7 it will remove 6.7.5
Thanks for the information! I didn’t know that behavior. Now that you say it, it seems obvious since I cannot remove the kernel, which I am running, manually. But I never linked the two issues.
