The first thing is to find out what the origin of the problem is. Then, we can check if and how we can solve it (this does not necessarily mean deactivate it permanently; the acpitool deactivation of devices is just temporarily and intended to identify the origin). So, if your bluetooth is in the acpi list, try to deactivate it with acpitool as mentioned above and check out if the freeze still appears. If this is the problem, we might find alternatives to make it work in a way not causing freezes (… if the bluetooth proves to be the origin…). If it is not the bluetooth device, activate it again and try out the remaining devices one by one.
I just saw that I have not mentioned above how to use acpitool for that: -w (lowercase w) outputs information including the device numbers, -W (uppercase W) enables/disables devices with the device number, (e.g., sudo acpitool -W 3)
@paltis If I understood you right, you already verified that everything is fine when bluetooth remains off? You have tested this several times? In that case, let us know the output of acpitool -w about the bluetooth controller, and the output of lsusb or lspci , depending on which bus the bluetooth is attached. Also, uname -r
Btw, have you already updated the kernel? You started with 5.15.16-200. Does the problem remain with 5.15.17-200, 5.15.18-200, and 5.16.5-200 ? Especially the latter would be interesting: if it remains in the 5.16 kernel, it maybe makes even sense to file a bug.
Additionally, I assume you use the default GNOME GUI tools to control your bluetooth?
I’m on version 5.16.
Yes, I just decided to check if something changes by turning off the bluetooth in the GNOME GUI.
I’ll watch for some more time, but so far I have not managed to get the laptop to freeze.
You may also check if the kernel 5.16 itself makes a difference. So, also try to use your bluetooth and such as usual, and check out if freezing keeps happening despite the new kernel.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 10a5:9200 FPC FPC Sensor Controller
Bus 003 Device 003: ID 05c8:03ec Cheng Uei Precision Industry Co., Ltd (Foxlink) XiaoMi USB 2.0 Webcam
Bus 003 Device 002: ID 046d:c247 Logitech, Inc. G100S Optical Gaming Mouse
Bus 003 Device 005: ID 8087:0026 Intel Corp. AX201 Bluetooth
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I assume your bluetooth controller was disabled while running acpitool -w?
But no problem, we now know your controller:
However, that one should work fine out of the box (at least now). I could only find two reports in Ubuntu with some problems (related to this controller) in 5.15 but solved in 5.16.
I suggest to test if the Bluetooth now (with kernel 5.16) works properly when enabled, without causing freezes or such. If this is not the case, file a bug at the bugzilla.
Contain:
clear description of the issue (what happens when and in which conditions, etc.)
all kernels you have tested (incl. current uname -r)
freeze-related journalctl logs
the information related to intel_iommu=igfx_off , iommu=pt , intel_iommu=on , intel_iommu=off (what you described above)
the information related to Bluetooth (no freeze possible when disabled, acpitool tests, lsusb output, etc.)
After a long observation, it turned out that if you charge the laptop through the second usb-c, this also causes it to freeze after suspension, apparently, is a bluetooth morbidity.
Workaround: Use hibernate instead of sleep mode. It takes a few more seconds for the computer to turn off and on because it has to save everything to disk, but it works, you can save the state without having to restart all your programs all the time. Plus, if you have a fast SSD, it’ll be almost as fast as putting the computer to sleep.
Again, this is a workaround and not a solution, but hopefully this hint is still useful for someone out there. I’ve seen a desktop computer that freezes after suspend (not a laptop), but that doesn’t mean you have to fully shutdown every evening, you just have to have a swap partition or file big enough to fit your ram.
While your solution may work, putting a system into hibernation requires a physical swap and failure to note that requirement and how to do so when making this type suggestion can cause users to try your suggestion and fail due to not having a physical swap space enabled.
Also, such suggestions on a necro thread that has not seen activity for over 8 months is also very bad form since there have been many many changes in software as well as at least 1 complete release version upgrade in that time period.
While your solution may work, putting a system into hibernation requires a physical swap and failure to note that requirement and how to do so when making this type suggestion can cause users to try your suggestion and fail due to not having a physical swap space enabled.
Yes, hibernation requires swap, I’ve mentioned that in my previous comment. If you run systemctl hibernate and your ram does not fit into your swap space, systemd will simply report an error: “Not enough swap space for hibernation”
Also, such suggestions on a necro thread that has not seen activity for over 8 months is also very bad form since there have been many many changes in software as well as at least 1 complete release version upgrade in that time period.
Well, this thread is about a bug in Fedora 35, which is apparently still not fixed for everyone (using an up-to-date Fedora 35). Yes, there’s Fedora 36 but what’s wrong commenting on a thread about Fedora 35 (as mentioned in the original post), for an unsolved issue.
However, using hibernate as a workaround may not be useful if the bug also causes your system to freeze when resuming after hibernation.
Since this is a top search hit on DuckDuckGo, I’ll add that on one computer running Fedora 35, an upgrade to Fedora 36 using gnome-software fixed the issue, so the system can be put to sleep again (onboard Intel GPU on ASUS C246 Pro board, no additional PCIe graphics card). There are reports that unloading the nouveau driver might help but probably not if you have an Intel GPU as mentioned in this thread.
Ideally, if one has found a solution that works for them there should be an update showing the solution and that post marked as the solution so others can see how the issue was resolved. Without a marked solution the thread is simply abandoned.
In this case the “solution” was buy new hardware. Do we really want that marked as a solution? I think it would be more accurate to say it went unsolved and no longer needs a solution.
Had the same problem (Dell Inc. Precision 7520) after updating to Fedora36 when I close the lid. If instead I suspend before from the PowerOff/Logout menu option, then it works fine so that is a simple solution for me.
@chemadiegor This topic refers to an older release of Fedora: this is unlikely to be related to your issue, even if the symptoms are comparable. Please open a new topic for your issue! Also, when opening a new topic, please add more information, especially logs from the previous boot which ended with the freeze (e.g., sudo journalctl --boot=-1 → feel free to anonymize what you consider private; e.g., MAC address, user name, and so on).
