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.
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.
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.
@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…
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.
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.
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
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…