Hi. I recently installed Fedora 35 after having recently used Fedora 34 but having wiped that install and tried something else. From what I remember, wake from suspend worked fine in Fedora 34 even with my encrypted disk and dual boot with Windows and it worked when I was using Arch Linux recently (I can’t remember which exact kernel version but it was in the 5.x.x line). However, with Fedora 35, when I try to wake from suspend my power light lights up but the screen is completely black. I even tried using caps lock to see if the caps light illuminated and it didn’t. I chose to encrypt the install when I was going through the install and I’m dual booting with Windows 10. I’m on a HP Envy X360 with a Ryzen 7 4700u.
I remembered having this problem on Fedora 34 with kernel 5.12.x with integrated AMD GPU on my laptop. But this problem already fixed on 5.14.x.
Since Fedora 35 shipped with 5.14.10 this should not problem anymore.
In the past when I facing this problem, I found that the blank screen only happen on my laptop display and not on second monitor (TV).
From that my workaround was to plug second monitor (TV) on HDMI port and set it as the primary display. The other workaround by disabling the suspend.
This workaround of course not solving the problem but at least avoiding me to force to turn off or reboot the system ungracefully.
One more thing, if this problem come after you are upgrading the system which should be upgrade your kernel too to the newer than 5.14.10, maybe you could try by choosing one of kernel version listed on boot list menu when we first time booting the system and find which one are work.
If you could find which one are work, you should always boot to that kernel version each time you want to upgrade the software to prevent this working kernel from deleted by the system until you found how to fix it.
I have tried other kernels listed in the boot menu (all 5.14.x) and none have worked. I also don’t have a second monitor so having a laptop that can’t suspend is pretty annoying.
As for the kernel I’m using right now (on which resume from suspend doesn’t work):
Its broken (again) in FC35.
I am on a Dell Inspiron 5515 with a Ryzen 7 5700u and when i close the lid on my laptop, it does go into suspend, but if I open it again a few hours later, battery completely drained.
I had suspend issues in FC34 intially and resolved them through “patches” and using copr repo latest kernel builds. I’m actually doing the same right now after upgrading to FC35, in fact my kernel is 5.16.0-0.rc0.20211105gitd4439a1189f9.4.fc35.x86_64 #1 SMP PREEMPT Sat Nov 6 03:00:59 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux as I’m rebuilding my own copr repo every other day, but still encountering the suspend battery drain issue.
I saw some work being done to resolve it elsewhere, but don’t think it’s made it to master just yet. I’m sure it will be worked out soon though.
These new hybrid power states (since no longer S3) have been finicky for AMD and the kernel. Beleive they are actively working on resolving as well.
Tried installing from kernel-vanilla-mainline-wo-mergew and still no dice . This is pretty annoying and tbh making me think of moving to another distro. Suspend is a very like, basic and necessary feature for me and its ridiculous that a new version of Fedora would completely break something like this tbh.
Believe I accidentally found something that might improve it.
I noticed since upgradting to 35 that my laptop battery was draining battery faster than it was on FC34. Seem’s they’ve included “power-profiles-daemon” by default in F35. It didn’t matter what I had set it to… balanced or powersaver in gnome power options, it still drained it the same speed.
So I ran the cli tool for it, "
powerprofilesctl and used the option to check the current profile and status… and it appears it doesn’t support AMD-renoir model laptops (or at least not yet) as I only saw “placeholder” in the output for each mode.
So i decided to uninstall it (sudo dnf remove power-profiles-daemon) and sure enough, my battery life doubled/tripled (though i do not get any options in gnome power settings anymore for the different modes). Rather, I just installed tuned (and the tuned-gui tool) to switch between power modes.
Since I’ve removed the power-profiles-daemon, suspend is now working more often than not.
Might want to give that a try.
How about when you first time installing Fedora 35? I believe the fresh install comes with kernel 5.14.10. Are this version also have the trouble with wake up from suspend? If not you could download it manual here. Find x86_64 and download at least
Place it on the same folder and install it all
sudo dnf localinstall kernel-*.
I am having the same issue on a HP Pavillion cl123-15- something.
The screen is staying blank, and the keys, trackpad, touchscreen are all non-responsive and the screen is black, and fans are running at max… I suspect it has something to do with kernel device access.
It works if I enable ‘software control of intel sgx’ in bios. It was originally disabled, I enabled it, and no go, but allowing software control fixed it. It is a workaround, but it is better then crossing my fingers hoping btrfs will behave properly without being shutdown properly.
That does not sound like a ‘work-around’. Instead it sounds like a necessary setting. I do not understand why you would ever consider a setting within bios to be a ‘work-around’.
Since the bios controls at the lowest hardware levels those settings are expected / necessary for the OS to function properly. YES, bios settings can and do control how the OS interacts with the hardware.
It is definitely a work around. It isn’t a necessary thing. It is a bios option, and the fact that it needs to be enabled with ‘software control’ and it is intel’s own hardware instructions, makes it a work around.
Second, because gnome is either expecting the optional setting to be enabled, or changing the setting via software, might mean it is actually a security issue because a non-privileged user can actually crash the machine.
I just want to give my though. Most of manufactures when creating bios firmware, they created to use with Windows since Windows are where the driver will comes. The other side not all driver comes to GNU/Linux and most likely the community need to reverse engineer the driver. Some successfully get some of degree of bios setting and some of them failed and need user to adjust the bios setting.
From kernel doc:
SGX must both be supported in the processor and enabled by the BIOS. If SGX appears to be unsupported on a system which has hardware support, ensure support is enabled in the BIOS. If a BIOS presents a choice between “Enabled” and “Software Enabled” modes for SGX, choose “Enabled”.
SGX must both be supported in the processor and enabled by the BIOS. tells me that even the kernel developers are aware of the bios interaction and that it is a necessary setting and not a ‘work-around’.
To me a ‘work-around’ is a means of making a temporary setting that enables an app to function that otherwise would not, but this seems a permanent, known, and documented configuration that is necessary for SGX to function.
You are saying a userspace application operated by a non-priviliged user should be able to modify bios settings and render a system useless by design?
Or Everyone needs an intel processor with their security extensions enabled in order for Fedora to function properly?
Very easily, I can recompile the kernel and compile out the SGX code, it is allowed by kernel developers. The what? Fedora won’t function by design?
I am failing to see your logic.
What does the userspace app have to do with changing bios settings?
Yes the bios setting must support that app, but the app has no affect on the bios settings. Those are independent functions. If the bios is configured to support that function it works, if not it fails.
The bios setting is done within bios, pre-boot, to enable use of that app with kernel support. The userspace app runs in userspace after the OS is active. Those are totally different environments and independent of each other.
I will give you -time- to think about this.
yes, it is failing, and that is a bug, that is why the original post is from november and no one could answer it along with a myriad group of other users who got frustrated and switched distros. I was being kind to the community and posting a workaround for the bug along with my basic triage.
I don’t like to play games. If you wish to argue the semantics of ‘it’s a feature’ vs ‘it’s a bug’ I would be happy to discuss that with you in another forum like dev null. But you are far from being helpful to the community.