Bug 2184048
| Summary: | System becomes unresponsive on suspend or shutdown | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Douglas <doug.hs> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 43 | CC: | acaringi, adscvr, airlied, alciregi, bskeggs, doug.hs, hdegoede, hpa, jarodwilson, jglisse, josef, kernel-maint, lgoncalv, linville, masami256, mchehab, perfected_deskbound045, ptalbert, steved, voj-tech |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-06-02 15:42:29 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
Douglas
2023-04-03 13:48:03 UTC
Created attachment 1955630 [details]
kernel logs from rawhide kernel
Update: I can reproduce this 100% of the time, even with a manually triggered suspension. The computer being idle or not doesn't matter. Created attachment 1955706 [details]
kernel logs from rawhide kernel after failed suspend
Update: The rawhide kernel is also failing to suspend, although not as often as the current F37 kernel. It shows the same symptoms. I'm sure it's the same bug. Will now try an older kernel version to pinpoint where this started.
Cannot reproduce problem on kernel 6.0.18-300.fc37.x86_64. The problem started in 6.1. Created attachment 1974798 [details]
Boot which first succeeded to suspend and resume but subsequently failed to suspend
Attached logs of boot which first succeeded to suspend and resume but
subsequently failed to suspend. You can see the 'Filesystems sync' log message
is only present for the first suspend but not for the subsequent one, which
might be relevant.
I experience the same issue, although it doesn't happen always, it appears to be random in my case. 1. Please describe the problem: The system doesn't properly suspend and hangs whilst keeping the case fan and power LED on (HDDs are shut down). Only a hard power off and a boot from scratch is possible when it hangs during suspend. 2. What is the Version-Release number of the kernel: 6.3.8-100.fc37.x86_64 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 : Haven't tried older kernels to see at what point this issue started happening but it certainly only started happening in the last year or so. I've had this Fedora installation for 5+ years. 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Yes, but it cannot be reproduced reliably in my case. It only happens sometimes (about 50% of the time). 1. Simply attempt to suspend the system. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Did not try. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No. 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. Attached logs of boot which first succeeded to suspend and resume but subsequently failed to suspend. You can see the 'Filesystems sync' log message is only present for the first suspend but not for the subsequent one, which might be relevant. (In reply to Vojtech Sobota from comment #6) > I experience the same issue, although it doesn't happen always, it appears to > be random in my case. > > 1. Please describe the problem: > > The system doesn't properly suspend and hangs whilst keeping the case fan > and power LED on (HDDs are shut down). Only a hard power off and a boot > from > scratch is possible when it hangs during suspend. > > 2. What is the Version-Release number of the kernel: > > 6.3.8-100.fc37.x86_64 > > 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 : > > Haven't tried older kernels to see at what point this issue started > happening but it certainly only started happening in the last year or so. > I've had this Fedora installation for 5+ years. > > 4. Can you reproduce this issue? If so, please provide the steps to reproduce > the issue below: > > Yes, but it cannot be reproduced reliably in my case. It only happens > sometimes (about 50% of the time). > > 1. Simply attempt to suspend the system. > > 5. Does this problem occur with the latest Rawhide kernel? To install the > Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by > ``sudo dnf update --enablerepo=rawhide kernel``: > > Did not try. > > 6. Are you running any modules that not shipped with directly Fedora's > kernel?: > > No. > > 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. > > Attached logs of boot which first succeeded to suspend and resume but > subsequently failed to suspend. You can see the 'Filesystems sync' log > message is only present for the first suspend but not for the subsequent > one, which might be relevant. Sorry, I don't know why I said I can reproduce it 100% of the time. It is as you said, more like 50% of the time. I can usually suspend successfully 2 times before a failure occurs. It's totally random. I encourage you to test kernel 6.0. From my tests, it doesn't have this problem, but 6.1 does. We need attention from the maintainers to proceed. They will probably ask us to perform a bisect to locate the exact version the bug is introduced. I have been able to reproduce this on shutdown as well, although not as often as on suspension. In this case the system doesn't completely shutdown, and some fans and LEDs remain on. A forced power off is needed to recover from this. I can confirm the issue disappears when I use kernel 6.0. Happy to help with bisecting and/or testing. @voj-tech Are you running an AMD or Intel graphics card? I own an AMD RX 6600. Tired of waiting for a fix, a few days ago I installed FreeBSD 13 and OpenBSD 7.3 on this machine. Suspend to RAM worked okay, but then I was surprised to find that this bug is also reproducible on both of these systems! The one thing I know that Linux and BSDs have in common is the DRM (Direct Rendering Manager) code that enables our graphics cards. See here: https://man.openbsd.org/drm.4 I'm running the integrated Intel graphics. Interesting that it's reproducible on BSD too, oh well... I've actually switched to the kernel 5.15 LTS branch for now. It works fine for me as I'm not missing anything from the newer kernel versions. Hoping the bug gets fixed at some point and if not then getting new HW will "fix" it for me I guess. Reported upstream to AMD DRM: https://gitlab.freedesktop.org/drm/amd/-/issues/2857 I couldn't find a more generic repository (for both Intel and AMD graphics), but I'll mention that this happens with Intel as well. So, it seems a BIOS upgrade I did yesterday fixed it. I went through about 10 suspend cycles with no issues - previously it would fail somewhere around the third suspension. It's a very confusing outcome, since the problem was connected to a specific Linux kernel version. The changelog [1] between F5 and F6 does not say anything relevant. Either they omitted this information or they really don't know they just fixed my issue. It was released in june this year. [1] https://www.gigabyte.com/us/Motherboard/B460M-DS3H-rev-10/support#support-dl-bios @voj-tech Which motherboard do you have? I suggest you check for updates too. That's interesting but good news! I've got GA-B250M-D3H [1]. Sadly for me I've been on the latest version (F10) all along. It's an old motherboard which has been unsupported for a while now. It can't be a coincidence that we both have a Gigabyte DS?3H motherboard :-) [1] https://www.gigabyte.com/Motherboard/GA-B250M-D3H-rev-10 The problem is back after a reboot :( I'm really tired of this, you know. I don't even know for sure what causes this problem. I don't know what hardware to replace in order to avoid the problem. I don't know what to do. Maybe I should avoid Gigabyte motherboards. This message is a reminder that Fedora Linux 37 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 37 on 2023-12-05. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '37'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 37 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. @voj-tech Do you still have this motherboard and this problem? Could you try to disable the BIOS option "Race To Halt (RTH)"? I believe this fixed it for me. Good to know that there is a workaround. I've actually switched hardware since then, partly because of this issue, so I cannot verify on my side. Nevermind. It happened again. This message is a reminder that Fedora Linux 39 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '39'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 39 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. *** Bug 2323869 has been marked as a duplicate of this bug. *** This message is a reminder that Fedora Linux 41 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '41'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 41 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed. The correct upstream issue is https://gitlab.freedesktop.org/mesa/libdrm/-/issues/92 |