Can't get hibernate or resume to work. I've got a relatively new install with swap with hibernate selected at install. I checked arch wiki and garuda wiki, but couldn't find any help from there.
I have the following settings in KDE power management under "On Battery":
Dim screen after 2 min
Screen energy saving: switch off after 5 min
Suspend session: automatically lock screen after 10 min
While asleep, hibernate after a period of inactivity
When laptop lid closed, hibernate
But when I leave the system to idle, or close the lid, I cannot resume from hibernation. I don't know if this is a hibernation or resume problem.
Common issues with Linux. I am currently fighting a build on a machine that takes 34sec to wake up, whether it's Garuda or Manjaro, no difference. However if using Garuda from 210225 ISO (yes 11 months ago), it works fine! Then I upgrade to today's specs from that ISO and bam, 34sec wake up. No log data for the 1st 30sec, so I hope you get luckier than me...
I highly doubt your issue is Garuda-specific related, though. What I'd do is try out at least another Arch-based distro (cuz Debian doesn't act the same way) and see if I'm right.
What does journalctl -r say? Try to pinpoint the 10sec before and 10sec after you try to wake it up and I guess then hard power it down.
Does your computer suspend/hibernates completely or are the fans, lights still on with heat coming out of the box even long after the suspend/hibernation?
Secondly, what do you do to try to take it out of sleep? Do you press a key on the kbd, move the mouse, press the power button or something awkward like hammering on the box? (hey we never know )
It could also be something super simple like your USB devices not allowed to wake up the computer.
grep . /sys/bus/usb/devices/*/product will give you a list of devices, one of those is the right one when you press a key or move the mouse. Take note of the numbers between DEVICES and POWER.
Then take those numbers and grep . /sys/bus/usb/devices/*/power/wakeup will tell you if it's disabled or not.
I closed the lid (causing the system to hibernate) and tried to wake it back up. Touchpad or keyboard didn't have any effect. I short-pressed power, which caused the computer to boot. I pasted journalctl -r output here.
Some things that may be interesting in that output:
Ok, as Cooter mentioned it's a good thing to try a different kernel or kernel version. And sometimes you have to try a lot of them. For exemple it may break before 5.5 but from 5.5 up to 5.12 it works and above 5.12 it's broken again. I am facing this situation on my suspend issue, I am trying to narrow down which kernel versions work and which don't.
So try a few versions, including whichever version LTS is. 5.15 I think.
I assume here you already know how to easily try different kernel versions, am I wrong?
When you boot into Garuda's GRUB screen, use your keyboard's Down arrow to move your cursor to Advanced, as SGS suggests, hit Enter, move your cursor to the LTS kernel, then once again hit enter.
Do you want to futz around with this forever, or just perform one simple task or two, so we can then move on?
Your's was the first post I addressed early this morning, the last one for tonight, and the last on this topic.
Yeah, I thought the "boot options" would set the option that is used to boot.
But even with LTS, the hibernate isn't working. It's weird, this exact same laptop has hibernated with Garuda previously just fine, and I haven't messed around the BIOS in between.
I would really prefer not to futz around this forever, but I just don't know how to solve this. I suggest not answering if it causes undue stress. I understand that I am not entitled to anything here. I'm just using the support channel for the distro I like using.
I would recommend updating your bios. There has been a number of bios releases since the date of your bios listed as urgent and stating on the website "Dell Technologies highly recommends applying this important update as soon as possible. The update contains critical bug fixes and changes to improve functionality, reliability, and stability of your Dell system. It may also include security fixes and other feature enhancements." https://www.dell.com/support/home/en-us/drivers/driversdetails?driverid=1wm16&oscode=biosa&productcode=xps-13-9370-laptop
Thank you very much for eliminating a possible kernel change solution. It is one of the early steps of troubleshooting.
Your BIOS date didn't concern me at first because it was 2021. But @Kayo may very well be correct, so please do so. Looking for a manufacturer's BIOS update is also one of the next logical steps, and one that is heartly advised. Heck, my BIOS had a Nov. 2021 update, but had another just about a week ago. Please check. And cross your fingers.
I wanted to draw your attention to my prior post because you had ignored changing kernels, advise that could have easily and quickly provided you a solution. I am glad you have done so, but unhappy that did not solve your problem. But please add that to your computer bag o' tricks, as it may help you in the future.
Your bios date indicates relatively new hardware. As others have already commented, updating to the newest bios is very important in cases such as this.
With newer hardware the linux-mainline kernel is you're most likely bet for a fix. Also be sure to install and test the linux-firmware-git package (then reboot).
Trying different settings in your bios relating to sleep states is also a good idea. Unfortunately, Windows has their dirty fingers into people's bios again and it's messing with Linux's ability to suspend on some newer systems. Check carefully for a setting with Linux compatibility in your bios.
Failing a bios fix, you may find some kernel parameters that may help. Search the Archwiki for your computer model and the internet in general for any special parameters that may help with suspend issues.
Good luck, and if you can't find a fix for this you've likely got Microsoft to thank for it.
I installed the new bios and other firmware with linux-firmware. I tried disabling something called C-state from the BIOS, and with different kernels (lts, zen, mainline). Still no luck.
Hmm... just to be 100% sure, you did try the linux-firmware-git right? Just that something new is needed for this hardware. I'm not sure if the support for the hardware is quite there yet if you have indeed tried all the latest firmware packages, kernels (you even tried LTS, good on you), and even the C-state options in BIOS (I wish my other computer's motherboard with a first gen Ryzen CPU had that option.. lol). Edit: forgot to mention that C-states set to off make it take longer to get out of sleep-like states. Just something to note for others that might look at this thread via a search later on.
At this rate, given the frequency of urgent bios updates Dell is pumping out, there might be another bios update in the works that will fix this issue, or linux-firmware-git might even still have to play some catch-up too. I'll try to investigate on the linux firmware front to at least see if there is a work-in-progress fix in the pipeline. If I come up with nothing, the ball might be in Dell's court after all.
Seems I overlooked this before, the SSD firmware has issues. "The stock firmware version AADA4102 has severe problems when the ssd enters the lowest power state". Thing is, the only reliable way to update this is through Windows. There is a way to do it with Linux, but only "at your own risk" Dell XPS 13 (9370) - ArchWiki
)
