Not in Garuda, in an easy way (with Garuda utilities).
The card is even before Fermi models (that used nvidia-390 drivers).
Garuda supports only latest proprietary nvidia drivers.
2 Likes
I remember some time ago in Ubuntu, the PC only worked well when I switched to nvidia-340 driver. But this is now unavailable. Can you recommend a distro where I could still do something like this? Or at least to escape from nouveau? Manjaro, probably? Or Endeavor OS?
for your info i have added support for nvidia-390xx driver support in garuda linux
upgrade your system fully
sudo pacman -Syu
sudo mhwd -a pci nonfree 0300
and you wiil have the driver installed
if your card uses 390xx
else you are stuck with nouveau
2 Likes
sudo mhwd -a pci nonfree 0300
> Skipping already installed config 'video-linux' for device: 0000:01:00.0 (0300:10de:0a65) Display controller nVidia Corporation GT218 [GeForce 210]
Now what?
OP card is even older.
nouveau
Maybe irrelevant to your Topic. It is not proven that GPU breaks suspension.
Have you checked for watchdogs?
Have you disabled system services/daemons that might prevent sleeping? (VPN, cloud sync, network connections, etc).
Edit: On second thought, the system uses the modsetting driver, which includes nouveau. It is not uncommon that sometimes, using the separate driver package may change behavior. Also, loading early may help. IMHO, itâs worth trying.
In Garuda device manager, install and use video-linux option.
Or install xf86-video-nouveau package.
Add nouveau in âMODULES=â array, in /etc/mkinitcpio.conf and
rebuild kernel images.
sudo mkinitcpio -P
sudo grub-mkconfig -o /boot/grub/grub.cfg
Reboot afterwards.
3 Likes
nouveau was already added to the modules array.
I went through all the steps and finished with a restart.
Still after Suspend, the PC would not shut. 
1 Like
OK, I decided to go further back with kernel versions. I installed kernel LTS 4.19.
I put it to sleep. I waited for a few minutes to see if PC would shut down. It didnât.
I pressed the power button once â immediately the screen went on and I was at the lock screen.
I got the journalctl -b output. You can see when I put it to sleep at 13:06 and when I pressed the power button at 13:09.
Previously the last line of a sleep process was (before I cold resetted):
kernel: PM: suspend entry (s2idle)
Now, there is one more line after it:
pc kscreenlocker_greet[18206]: qt.virtualkeyboard.hunspell: Hunspell dictionary is missing for âen_USâ . Search paths (â/usr/share/qt/qtvirtualkeyboard/hunspellâ, â/usr/share/hunspellâ, â/usr/share/myspell/dictsâ)
I really hope, this serves anyone to identify the problem.
1 Like
After a suspension attempt, post:
systemctl status --no-pager -l systemd-journald
systemctl status --no-pager -l dbus*
systemctl status --no-pager -l systemd-logind
pacman -Qs "nouveau|nvidia"
Also, you might try testing disabling network before suspend.
Important Note: I assume you know that when suspending to RAM, the PC is still on Power (power leds are ON). Only hibernation leads to a complete Power Down (power leds OFF).
3 Likes
This is the result after a suspension attempt. This time I left it for hours. After a single press of the power button I was presented with the login screen.
systemctl status --no-pager -l systemd-journaldsystemctl status --no-pager -l dbus*systemctl status --no-pager -l systemd-logindpacman -Qs "nouveau|nvidia"
And, yes, I am pretty aware of how Hybernation and Suspension/Sleep work. Also on my PC I have an LED on the power button. When hibernated, everything is off. When asleep, PC is off, but the Power LED is slowly blinking.
It seems sleep succeeds, technically for the system. Logging stops for that time.
I don't know what signs should convince you, you insist it's not sleeping for the LED. AFAIK LEDs may be SW and HW affected.
Is any fan spinning? Slight low speed is expected from power unit.
Starting to log screen on wake is a good sign.
If you still can't sleep, maybe use a power consumption meter, but don't ask me. 
2 Likes
My own personal opinion is that the most likely solutions lie with either a different kernel or with grub kernel boot parameters.
If you haven't tested them already, test the "linux" and "linux-mainline" kernels. We really need to know exactly which kernels you have you tested so far. You can have more than one kernel installed at the same time, so there's no need to install, test, remove, It's actually better to always have at least 2 kernels installed at all times. It is always best to have at least one falllback kernel in case you have a full meltdown on your main kernel
There's a ton of kernel boot parameters you could test. Time consuming to search and apply, but one of your best chances for a solution. I would concentrate way more effort in this area.
One thing I'm still curious about is if you actually implemented my suggestion to configure the hibernation feature. This may not be what you want, but it is helpful as an indicator of how likely it may be to get suspension working. On some systems where hibernation works at least it's a positive indicator that suspension may be possible to get working.
Is hibernation working on your system with Garuda?
I earlier made suggestions to disable services that are installed by Garuda's performance-tweaks package (as I felt there was a possibility they could interfere with your suspend process). You did not post any output confirmatins of disabling the services. As an experienced troubleshooter who has experienced this all too frequently, I have to assume these suggestions might not have been done correctly (or perhaps incompletely) without corroborating outputs.
I would ask you instead to simply uninstall the performance-tweaks package so that I may be sure this is not part of your problem. Please uninstall the performance-tweaks package via the terminal and post confirmation that this has taken place. Reboot after uninstalling the package and the test suspension again. If you don't wish to waste your time doing double the troubleshooting procedures, then you need to start getting in the habit of posting the terminal outputs of any procedure you've done while troubleshooting this issue.
Without outputs being posted during remote troubleshooting assistants on the forum can not know if something has been done correctly. I can't stress this enough.
Another possibility is to test the powertop program to see if it helps with suspension.
I would also try to examine the Distro's that worked correctly with your system in detail to find what differences there may be with Garuda. The first thing I'd look at is which kernels they used, to see if you can replicate them on your system. @jonathon may be able to help you there as I think he may be hosting a repository of older kernels. Also take note of the version of the linux-firmware package and graphics driver in use on these other distros where suspension worked correctly.
As this post gets longer I can not possibly remember every step you have taken. I assume that I suggested that you be sure your bios is up to date. You need to test these other distros again that you used in the past where suspension worked properly. If suspension no longer works on those distros then it's possible the kernel has changed on these other distros as well. Another possibility if suspension no longer works where it did before, is the linux-firmware package or graphics driver has changed and it is affecting suspension. If these other distros no longer work, is there a possibility you performed a bios update that has a bug with suspension. The only way to know this for sure is to roll back any bios update you have performed recently.
The main problem with trying to replicate the differences on the other distros, is that some big commercial distros have the financial resources and developers on staff to create custom patches to kernels and drivers. Obviously small independent distros can't afford this luxury, so that's not really an option here. It is also a huge task for the average user to track down any custom kernel or driver patches or special configuration files they use.
Not an easy task, but good luck trying to track all these things down.
2 Likes
I have some good news 
I agree with your personal opinion - I also think this might be a kernel issue with versions 5.x.
I actually made it work perfectly with kernel 4.19. Both Suspend and Hibernate do work.
Now a bit more on what I did:
So I started looking at the logs I was posting here. Note the latest ones were when I went with the oldest available kernel version - 4.19. I was looking at the last kernel message: PM: suspend entry (s2idle).
So I went to kernel.org and started reading about the power management, specifically the mem_sleep file. I noticed there should be other options - shallow and deep. And found out it is this last kernel message, before Sleep is handed over to the BIOS. Then I rememberd you (tbg) had asked me to try all possible Power options from my BIOS. There are only 2: S1 and S3. Then I read about ACPI and learned what those mean. So my DELL had S3 as default and during different trials I had left it to S1 - which means exactly shallow. I switched it to S3 (conserves more power) - the deep state. Because this is what I have experienced before (with Fedora and Solus) - the Suspend mode turned off everything and only the power button was blinking.
Then I checked again the value of /sys/power/mem_sleep and this time it was s2idle shallow [deep]. For those, not familiar - this means now the suspend entry will use the deep option (instead of S2 - Idle, or S1 - shallow).
And it all worked. I tested Hybernate - everything was as expected. I tested Sleep - again, all fine.
Now I am going to switch back to Kernel 5.x and investigate what happens, because I also found this and I wonder if I should try the resolution from that answer.
I hope all of the above points you also in the right direction. Thanks for wishing me luck - it got me
Update: I was also thinking of installing Fedora 33 and dual booting with Garuda. Then I could possibly investigate according to your directions, to find differences between the two. But let's first see what kernel 5 will show.
4 Likes
OMG, guys, even better news.
So I switched to kernel 5. This time decided to go berserk and installed the latest of the latest experimental 5.10 rc, in the hopes that this kernel bug (as I have read across the net) has been fixed. I tried the Sleep and it failed - left my PC running with just monitor and keyboard+mouse off.
So in the meantime I found this.
It was just the quickest thing to try. I just restarted and in Grub I added init_on_alloc=0. I started a few programs just to be sure I would recognize the system would be waking to my current session.
And, yes, it fell asleep within a couple of second. Everything was off, except the blinking power button. I pushed it and I was at the lock screen. I logged in to my session and it was as I have left it.
So happy
OK, now, I am leaving you to you (the pros) to decide if anything should be modified among the Garuda parameters or not. I have my fix now and I am off to reporting other issues 
P.S. I am available if more logs are needed for you to make Garuda even greater.
6 Likes
Well that's very good news. Usually persistence is rewarded, so you were certainly due.
Congrats.
6 Likes
Kernel 5.12 broke it again. Sleep works fine, but when I push the Power button to wake it, the screen lits up with plenty of snowflakes and sometimes distorted forms (like triangles). Sometimes when I move the mouse, i can see some activity on the screen, but nothing happens and nothing is recognizable.
For now what I can do is hit CTRL+ALT+F2 and login to this TTY.
killall startplasma-X11 and I am back in.
Did anyone else hit this? Are there any clues how to fix?
Try other kernel or wait for kernel fix, best is you check if problem is known by kernel developer and post an issue if they donât know it yet.
As @SGS has mentioned there are many other kernels you can test. I would start by testing:
linux
linux-mainline
linux-lts
linux-next-git
linux-hardened
Create a keyboard shortcut for kwin restart (search how) and use it with the flakes.
Or create a service file to do this. There are examples at Archwiki.
1 Like
Who do you refer to when you say "the kernel developer"? I am particularly following Garuda's advice to stick to ZEN kernel. Is there a link or anything?
Yes, as a workaround I switched to LTS (5.10) just to see everything works. And it does. Still when I have more free time I will experiment with others to see how they behave.
1 Like