Fedora freezes after suspend

Hi, i have a problem on a Fedora Workstation.
I have been looking for the cause of freezing problems for several weeks now, however I am not an experienced Linux user, maybe someone has come across a similar one.

After I suspend my laptop and wake it up, the screen remains black and system not response.
I tried to use KDE, then the system freeze on the login screen and not response.
I found out that setting the parameter intel_iommu=igfx_off partially fixes the problem, but still there is a chance of hanging.

Reproduce Steps:

  1. Suspend the system and quickly restore
  2. Restore after long time
  • Distro: Fedora release 35
  • kernel: 5.15.16-200.fc35.x86_64
  • product: RedmiBook Pro 14 pro
  • cpu model: 11th Gen Intel Core i5-11300H
  • gpu model: Intel TigerLake-LP GT2 [Iris Xe Graphics]
1 Like

Unfortunately, we had several freezing issues recently, including freezing after suspend the way you describe it.

Maybe one of the recent solutions help you: https://discussion.fedoraproject.org/search?q=freeze%2035%20suspend%20after%3A2021-11-01

I already made a summary of threads with the same issue that may be not included in the search page above (older, but still Fedo 35):
https://discussion.fedoraproject.org/t/fedora-34-freeze-at-boot/69800/14

1 Like

hi there,

yes this issue is ongoing and I am working on figuring this out on some of our desktops too.

Often I find the older hardware it is much more prevalent however this system is very new so surprised to see this issue on new motherboards.

Switching between proprietary and open source drivers is a great first step if possible as this often can be the issue too from my experience.

can you elaborate on acpitool @py0xc3 ?

@bennyisaiah This is not the same issue but the related functions are much the same:
https://discussion.fedoraproject.org/t/suspend-exits-immediately-after-installation-of-m2-ssd-nvme/75621/4
with some elaboration from the user:
https://discussion.fedoraproject.org/t/suspend-exits-immediately-after-installation-of-m2-ssd-nvme/75621/7

ACPI is related to power management:
https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface

Given that fact, it is strongly involved in suspending, and has to work properly:
https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Global_states

2 Likes

As I found out, there are no problems on the configuration with the nvidia graphics card of the same device, is it possible that it is connected with an error with the Intel graphics?

@paltis of course you can ignore the solutions with nvidia. These are related to drivers you don’t have. Assuming that you use the default driver of Fedora for your Intel gpu, I don’t think the driver is the origin (… unless we find explicit indication that tells the opposite).

Feel free to show us your logs: as soon as the problem happens again, you restart your computer and then go to a terminal and let us know the output of the following two commands:

journalctl --boot=-1
journalctl --boot=0

The first command shows us the system logs of the last boot (thus, the boot that ended up with the freeze), the latter command of the current boot. It would be also good if you note and tell us the time when you suspended and when you tried to wake it up.

1 Like

Btw, what was the original value in this place? How does it work if intel_iommu=on and how if you remove the option at all? How is it with iommu=pt (without intel_ in the beginning)? The latter bypasses DMA translation (unlikely to be the origin, but worth a try).

Some background:
https://www.kernel.org/doc/html/latest/x86/intel-iommu.html
Intel already states that a bug shall be filed if its related to igfx_off while the option itself does not solve the problem. But let’s have a look on the logs first.

https://github.com/Paltis96/boot_logs
boot_freeze - boot log before freezing
boot_susccess - boot log after freezing with successful wake up at 14:05

@paltis additionally to the tests in https://discussion.fedoraproject.org/t/fedora-freezes-after-suspend/72765/7, can you provoke the freeze if you disable wpa_supplicant with sytemctl stop wpa_supplicant.service before suspending? stop will turn it off within this boot, but it will be automatically started again in the next boot. This will disable your wifi for the time it is stopped. Just to exclude this as potential origin…

Seems like it is a new issue in the kernel newer can anyone confirme is it the case if yes does it already on bugzilla. About this issue.

if i set iommu=pt I can still get a freeze just like when i set intel_iommu=on.
If i set intel_iommu=off I cannot provoke a freeze, however, during operation with a long sleep, it can happen.
Another strange thing when i turn it on laptop in grub strange artifact is running from the top of the screen to the bottom, preventing me from interacting with the menu before it ends, this did not occur in ubuntu 20.04 lts distros from which I switched.
I accumulate, save logs, but for now I switched to kde spin, because it causes itself to be folded in planetary hibernation. and I basically use kde for work.

Can you show a photo/picture of that?

Sounds indeed like a bug so far. My guess is that it is related to ACPI (which is the “backbone” of suspending tasks): iommu (which is also acpi-related) seems to have an influence on the freeze occurrence, but even when turned off, it does not exclude the freeze to occur (so I assume the bug, or whatever, is not iommu itself). We would need the logs to find out more:

wpa_sytemctl stop wpa_sytemctl.service has no changes for me, I didn’t quite understand how to attach the file, so I’ll leave a link to the logs. boot log on hibernation is updated on suspend.
https://github.com/Paltis96/boot_logs.git

@paltis With regards to my guess above, let’s check out the acpi related things.

Install the acpitool (you can remove it when we solved the issue):
sudo dnf install acpitool

Then, check the output of sudo acpitool -w (with a lowercase -w) → this outputs information of the acpi devices with wakeup capability. Let us know the output.

I will compare it to the logs and then we will try to disable some devices’ acpi capabilities to identify the device that causes the error (assuming that this the problem is related to acpi). This will be also done with the acpitool.

okay, i add log on previous link

Here is such a strange artifact in the menu




Indeed strange. I am not a grub expert, but if you don’t have comparable issues in grub, I don’t think it is related.

To me that appears as a scan issue with the grub menu terminal stage. It is only an issue if something similar continues after the boot has completed

1 Like

I also have this issue (about moving underscore on boot menu) in the past when still using F34. At that time the problem gone after recreating grubenv and boot.cfg. Not sure if it will work now.

And also recently with F35, I also have same experience (and I ignore it) but it was gone it self after several update.

If you want to try it:

# backup current grubenv
sudo cp /boot/grub2/grubenv /boot/grub2/grubenv.bak

# recreate grubenv
# there <space> - <space> to auto create to default directory
sudo grub2-edit - create

# recreate grub.conf for efi system
sudo grub2-mkconfig -o /etc/grub2-efi.cfg
1 Like

Your comment made me think that it might be worth checking the bluetooth, when I turn it off in the settings, I can’t provoke freezes, but I still need bluetooth…