I am using a laptop with an intel CPU and no dedicated GPU (integrated intel graphics). When I close the lid, I expect my laptop to enter suspend mode (ie. systemctl suspend). On kernel 6.9.12, it does just that. The power status LED indicator on my laptop, controlled by the firmware, begins to flash slowly, letting me know that it is in a suspended state, and the display remains off (when I suspend via the command line without closing the lid).
After upgrading to kernel 6.10.3, however, suspend fails with an error: No such file or directory. The display turns off for a moment, then flashes, then turns back on to the lock screen. At no point does the display successfully turn off. From there until I restart the device, I experience regular display freezes about every 5-10 seconds, lasting for a half second at a time. I can see these quite clearly when I move my mouse because the mouse will appear freeze for a second then jump to its real location. This behavior only occurs after a failed suspend state.
I’m downgrading to kernel 6.9.12 for now. Is there something I can do on my system to get it fixed so that I can run 6.10.3?
If this is a kernel bug, how can I report it?
I am running Fedora 40 with Wayland. My DE is KDE, if that helps.
Here are a few journalctl screenshots. The last two are from systemctl status. They suggest some sort of ethernet hardware issue, despite the fact that i use wi-fi.
Apparently I’m only allowed to post three images per post because I’m new or whatever. Here are the other three
Hello @oirnoir ,
Normally. it is better to put the text C&P from terminal into comment using block quotes (</>) icon in edit window of comment. It’s easier to read, and you won’t run into image upload limits.
I have exactly the same problem ( fail to suspend on 6.10.3, same error message, and random freezes after failed suspend). I am using Gnome with wayland, Fedora 40.
Update: after I disabled the ethernet in bios, I can successfully suspend the system.
It’s great that that works for you as a solution. However, I occasionally use ethernet so I don’t want to disable it within my bios, so this isn’t a valid solution for me.
Apparently, Linux 6.10.4 was released today so maybe that’ll fix the issue (?) None of the changelogs seem to mention this suspend issue so I’m not too hopeful.
If not, I’ll increase the number of kernel versions dnf will keep in grub (via /etc/dnf/dnf.conf) so that I can continue using 6.9.12.
If the kernel devs are unaware of this issue, is there a way I can report this bug?
I had been experiencing the same symptoms as OP on a P14s Gen 5 with Nvidia GPU. Suspend used to work, then stopped working, but after a failed attempt to sleep, the system would start to “stutter”.
Interestingly, disabling ethernet in the BIOS (“internal devices”) did the trick! 
I, too, need ethernet from time to time, but for now this is a viable workaround. Thanks!
Many systems enable ethernet at the BIOS level to support netbooting, but you may still be able to use ethernet in linux. Network issues are not unusual when moving to a newer kernel. I have found it necessary to have a USB ethernet “dongle” (at my former work WiFi was not available outside public areas), as well as USB sound and Bluetooth dongles. The dongles are cheap, but some effort is needed to ensure that they will work with linux so I stick with vendors who document the chipset they use.
Edit: another advantage of dongles is the hot-plug capability so you only connect them when you need the capability they provide.
Indeed I can confirm that even after disabling ethernet in BIOS, I am currently connected to the internet via ethernet (Wifi disabled by software) with my F40 KDE laptop 
And the machine has been through several suspend-wake cycles now without problems. Perfect, and thanks for the explanation!
(OT – I switched to Fedora only recently and I must say the community is extremely welcoming, friendly, and helpful! 
)
I could not find the option to disable ethernet from my specific BIOS (and not for lack of trying, either), so it looks like I’ll be stuck on kernel 6.9.12 for the foreseeable future.
If you don’t use ethernet in Fedora, you should try turning it off. There are some ideas in Disabling and Enabling an Interface on Linux System.
These may be useful to check if disabling the interface fixes your issues, but doesn’t have examples with systemd that could disable the interface at boot time. For systemd, see Network Configuration with Systemd. Fedora provides /usr/lib/systemd/network/89-ethernet.network.example.
Note: this issue is reproduceable in kernel 6.10.4
Thank you for your response. However, I occasionally use ethernet, so disabling it entirely won’t be a viable workaround for me. I have increased the number of kernel versions dnf stores to 10, which might hopefully be enough to see this issue fixed.
I know you wrote above that you tried to find the option in the BIOS, so just to make sure – I found it only after looking in a place that I found unlikely… It’s not under “Networking”, on my machine the option is in the “Internal devices” menu.
I assure you, I checked every single option in my device’s firmware and there is nothing to disable the ethernet. There is no internal devices menu.
Got it, well that’s too bad and I do hope there will be a remedy for this situation soon! 
does the system suspend successfully when connected to ethernet?
see 218940 – e1000e patch in 6.10.0-rc2 breaks S2idle and S3 suspend on 4 of our machines
https://bugzilla.kernel.org/show_bug.cgi?id=218936 and
e1000e regressions reg. suspend and resume (was: Re: [GIT PULL] Networking for v6.10-rc7) - Linux regression tracking (Thorsten Leemhuis)
Look in BIOS for a network boot option (PXE) and disable if available.
You could try what will happen when you disable network before suspend with sudo nmcli n off. Re-enable with sudo nmcli n on.
Otherwise you could also try to rmmod <kernel module> the kernel module after disabling nerwork first. modprobe <kernel module> is the reverse of rmmod.
If this is successful, then you can put this in a pre-suspend /post-suspend script to do this automatically by systemd.
PXE is disabled by default in my BIOS, and was disabled when I checked it.
The system suspends successfully when connected to ethernet.
Disabling the network before suspend with sudo nmcli n off also allows it to suspend successfully, but setting up pre-suspend and post-suspend scripts in systemd seems like a very hacky workaround. It would be great to see this bug fixed for real.
Based on the kernel discussions linked, the bug appears to affect only certain processors. One of the people in those discussions stated that the issue was fixed for them, but it definitely wasn’t for me.
From fastfetch:
CPU: Intel(R) Core™ Ultra 7 155H (22) @ 4.80 GHz
GPU: Intel raphics @ 2.25 GHz [Integrated]
Sorry for my latency, I was away from my usual setup and could not test with an ethernet connection.
There are many different revisions of the controller. And you seem to have a Meteor Lake CPU.
Let’s find out the pciid of the ethernet controller:
please run lscpi | grep Ether followed by the command lspci -nn -vv -s <insert first column of the previous output> and post the output of the second command as preformatted text.
e.g. ( this is a VM )
$ lspci |grep Ether
00:03.0 Ethernet controller: Red Hat, Inc. Virtio network device
$ lspci -nn -vv -s 00:03.0
suspend script:
Of course, the suspend systemd script is a workaround until this is fixed. It’s a more convenient way. There’s no need to run the nmcli commands manually every time.