Yes, I have. There are 2 options in Bios - S1 and S3. Suspend fails with both.
I am answering last 3 questions in bulk because as a new user I am forced to wait for some time (too many postsā¦).
- I donāt see any errors in dmesg
- I donāt have an MMC reader
- I have tried removing the Wifi card (PCI) and also removing all USB devices but one - this is the keyboard and mouse dongle - because with no mouse and keyboard how do I suspend
1.
Answer
2.
Answer
3.
Answer
4.
Answer:
For answer all this post bulk is better, no extra post is needed.
Mark the text you want to answer and click the popup "Quote
Yes, sorry. I am trying to be as explicit and complete as possible.
I am really tired of distro hopping. I really like Garuda and want to stay with it. I don't want to go back to Fedora and Solus.
I think I answered all.
2 Likes
I was erroneously assuming you were using a laptop, as most people wanting help with this problem are laptop users. Now that you have posted your inxi output I realize you are using a desktop computer.
As you are using a very old desktop you actually could remove the mouse and keyboard from the equation by replacing them with an old school P/S2 mouse and keyboard (if you have them kicking around).
I always keep an old keyboard and mouse around just for this purpose as I own a gigabyte mobo with bad USB support in Linux.
Are you using a power manager such as tlp?
Are the keyboard and mouse wireless or wired to the USB port?
2 Likes
I mention in almost every post, this is a āPCā.
It is not THAT old. It is around 10 year old. It is not old enough to have a PS/2 port
Although I do have a PS/2 keyobard here, there is no way to connect it.
TLP is not installed. I have a fresh Garuda installation.
Both are wireless and using the same dongle. I have a Microsoft Natural 7000 keyboard that comes with its Microsoft mouse.
Anyways, I just did this: āsleep 1m && systemctl suspendā and I removed even the keyboard/mouse usb dongle. Seems this is not the issue because Suspend failed again. So, checking this one out.
To me this is simply semantics, myself and I believe many others use that term as a generic name for most any computer. Regardless, I have better things to do with my time than argue semantics.
I have a computer the same age as yours and mine certainly does have that port.
Firstly, let me say I have considerably more experience than yourself troubleshooting suspend problems. Your above conclusion is incorrect. That is not an accurate method of determining if the mouse or keyboard is causing the problem. Believe me when I say I have performed hundreds and hundreds of these types of tests while writing suspend services to correct precisely these types of issues.
Wireless mice & KBās do cause suspension issues and they can sometimes be very difficult to correct. The easiest way to somewhat eliminate those devices would be to borrow a standard wired USB mouse and KB from someone you know (if possible). Although, even this test is not 100% at eliminating all doubts (a P/S2 mouse and kb does).
It is possible to disable a wireless mouse and KB by unloading them prior to suspending and reloading them again upon resume. You can not perform these actions manually yourself. However, you can write a service to do this automatically before and after suspending.
Itās a difficult process of elimination to find out if any of your devices are causing this. Just to be sure, I would also try rmmoding your Ethernet adapterās e1000e driver prior to suspending.
On the off chance it might make a difference, boot into the fallback kernel image at the grub boot screen and then test your suspend functionality.
As I mentioned earlier, sometimes hibernation will work if suspend will not. As you would need either a swap partition or a suitably sized swap file the easiest method to enable hibernation in your situation would probably be a reinstall. During the installation process you can easily enable hibernation during setup. As you said this is a fresh install, I presume this wouldnāt be that big of a loss at this point. Again, simply an alternative workaround. If this isnāt what you want then disregard this suggestion. However, it is sometimes nice to know if it is possible to at least get this method working on your your computer.
Another troubleshooting step you might want to test is disabling prelockd before suspending:
sudo systemctl disable --now prelockd.service
To enable it again:
sudo systemctl enable --now prelockd.service
Similarly you may want to test disabling the memavaild and auto-cpufreq services via the same method as above.
Profile-sync-daemon may also be worth test disabling as a further troubleshooting step. As it is a user service the method to disable it is slightly different.
Disable PSD:
systemctl --user disable --now psd.service
Enable PSD again:
systemctl --user enable --now psd.service
Search the service name if you have any questions regarding the service, or the Archwiki for questions regarding enabling and disabling services.
The only other troubleshooting method that I havenāt mentioned is testing different grub kernel boot parameters. As I have never installed Linux on a Dell computer I have no first hand knowledge of which kernel boot parameters may be the most beneficial. I performed a cursory search, but I will leave it to you to perform your own in depth research on this method. You will need to search your model specifically and Dell in general to find which kernel boot parameters might be worth testing on your computer.
As I have spent a considerable amount of time already detailing steps to troubleshoot your issue, I will now leave this in your hands to research and work through the required troubleshooting steps to hopefully correct your issue.
Good luck.
6 Likes
Have you checked journal for relevant errors?
After a failed attempt to suspend, use this command to read journal in reverse order (latest messages are at the top/start)
journalctl -b -r
Or search for a relevant word
journalctl -b -g suspend
journalctl -b -g failed
3 Likes
Thanks for the attempt to help @petsam , but I fear this user has departed for greener pastures. I went to great lengths to try to help this user. I wrote almost a full chapter of suggestions to try to help him. Sadly, it is going on two weeks now and the user hasn't even had the courtesy to respond to my attempt to help him.
In cases like this you pretty much have to assume it was simply a drive by Linux lookiloo distro hopper kicking the tires. These types always want a one line terminal command to solve all their problems. If anythingthing more than that is required they're back to Ubuntu.Expecting the user to actually participate in troubleshooting their own issue is simply expecting too much these days it seems. 
Thanks for the attempt to assist though @petsam.
4 Likes
Hi, actually I am still here.
I am sad to see you assume wrong of me and misjudge me badly. I am not a distro hopper and definitely I do not expect from anyone a one-liner fix for my issues. I don't just give up that easily. Especially when I see that this is a distro that has very high potentional and is much ahead than others (like Ubuntu). I rarely write to such forums because I do the best I can to fix issues myself, rather than bother other people. So I am grateful for your help, however your last statement was that no more can be done on your side, so I stopped responding and continued searching for a fix on my own.
Actually I did everything that was requested and suggested. I followed instructions and responded for everything that was asked from me, no? You said you are experienced and have tested hundreds and hundreds of sleep/suspend issues. That is very nice for you, but as long as it has not helped me, it is practically irrelevant. Would you not agree? I don't mean to diss anyone. I welcome all the help. I will also checkout journalctl.
I don't know if topics here are lockable, but if they are, please keep this one open. Whenever I find out something new on the issue I will be sure to contribute, by writing back.
So the latest update is:
After following all instructions and nothing changed anything, I decided to start testing different kernels. I need time, because I want to spend more than a few days with a certain kernel, before going to the next one.
Right now, the only interesting thing is that I tried going to the latest 4.x LTS and trying to suspend. What happened is that the PC behaved as before - monitor shut down, HDD (audibly) shut down, but the PC itself was still running (light and fans running). This time, however, when I pressed on the power button, it woke up and resumed as I left it. The improvement was that I did not have to hold the button for a cold reset. However still, the whole PC did not turn off.
So there you have it. There are more experiments to be made. I also need to read some more about the kernel and debugging, because I prefer to use a more structural approach with this problem, rather than just trial and error.
2 Likes
Someone else recently had an issue with powering off and it was fixed by setting an ACPI option, might be worth trying?
4 Likes
If you would like some company on your troubleshooting, try posting logs, so a more experienced user can have a chance to see something that you miss.
Have you looked for a watchdog?
2 Likes
Tips for getting assistance and a solution for your issue:
I apologize if I misjudged you, but when someone writes an extended list of troubleshooting procedures to test and the user does not respond for over 2 weeks, it seems fairly logical to conclude that after that length of time you are not likely to receive a response.
Generally, when someone does not respond within the normal response time (usually a week or less), I will not bother making further suggestions until they do respond. Making further suggestions in that situation would naturally seem rather pointless (if my last set of suggestions had not been replied to for several weeks). It is simply wasted effort to reply (yet again) with another set of detailed instructions when I have not been given the results of my last list of recommendations. Troubleshooting complicated issues remotely is very difficult and requires a very methodical approach. You often can not proceed to the next step in the troubleshooting process without knowing the results of the prior troubleshooting steps that were recommended.
Users who actually provide proper feedback to suggestions are usually the ones who receive the most assistance and find the solution they are looking for to a complicated issue. Remote troubleshooting is a two way street that requires the user on the other end to be very proactive and responsive, (or they stand very little chance of success).
If you have been continuing to perform further troubleshooting procedures in the time between your last post, then keep very detailed records of everything you have tested as well as any related search information you have uncovered. If no one has posted any further advice on your thread in a weeks time, then post the detailed list of troubleshooting measures you have performed. Also post any new info you have found online since your last post, (be sure to post links).
This step is very important for numerous crucial reasons. Firstly, as time passes your post moves further and further down the list of recent posts until it will be mostly forgotten and unnoticed. Furthermore, if you let your thread go idle for too long without any updates many helpers will likely assume the thread has been abandoned, and not bother replying to it for this reason.
Posting a detailed synopsis also shows helpers that you are not simply performing an empty bump (which most helpers find lazy and presumptuous). This demonstrates that you are being proactive by continuing to research and troubleshoot on your own (even if others arenāt currently offering suggestions). This goes a long ways to getting some good will, as this shows initiative. This is actually a very important factor because helpers on the forum are far more likely to respond to users who demonstrate they are not lazy and donāt require being spoon fed every answer.
There are even more reasons why responding with a detailed list of troubleshooting steps you have performed is important. As your thread gets longer details get muddled and hard to find among many different posts. A synopsis makes it far more likely others may respond to your request with a suggestion or answer that may be your solution. People that may have experience with your type of issue may not want to read though 50 or more posts to get an idea of what steps have already been performed on your thread.
We are already at post 33 on your thread, and the longer the thread becomes the harder it is to deduce what steps have been taken already. Very long threads become very confusing at times and providing a detailed troubleshooting summation is not only helpful, but also more likely to attract someone willing to help with your issue. When your thread gets very long, those that may have been following it before (while it was fresh in their memory) will forget what has happened if the post goes stale for any length of time. A user that needs to reread the entirety of a very lengthy thread to remember the details, is likely to simply move along to another thread that doesnāt require so much reading.
A detailed summation of all your troubleshooting efforts is far more likely to get you assistance and a solution than posting a reply such as this to a lengthy list of troubleshooting suggestions:
This provides next to no information and can not be relied upon to be accurate. This is because users that are vague and provide no details are notorious for being lazy and skipping suggested steps, (or performing steps incorrectly).
If you want what you say youāve done to not be doubted , then you must provide a detailed summation of what youāve done (and the results of each step, not vague generalizations). Command outputs and logs will tell the tale for you and they will confirm if a procedure has been performed correctly (leaving no doubts).
I hope those explanations can bring some clarity as to why concrete confirmations, command outputs and logs are required when troubleshooting remote issues. You will be far more likely to get assistance and find a resolution to your issue if you follow those suggestions.
5 Likes
OK, I'll try to keep it short.
Why I did not answer in 2 weeks? 3 main reasons. 1) I have some personal issues to attend to and I am also busy working. Putting that aside - 2) you mentioned I should complete all of the suggestions. And yes, they were a lot. 3) you mentioned I should reply in a single post.
So there you have it. I was trying to be thorough and go through all suggested steps. The result is the same.
Then, there were 2 more guys, adding suggestions.
- ACPI. I read the post. I added ACPI paramater (for windows xp) and the one for DELL machines, as my desktop is a DELL (btw I found this somewhere esle on the internet). Unfortunately it did not help.
- about "journalctl". I found a problem with the bluetooth driver. Actually I do not have a BT device, so I just disabled the BT service. This also did not help.
What I can do next is to add here the full journactl and/or dmesg, but I am not sure how to attach here. Or should I just paste? I saw a forum post with a collapse/expand arrow. How do I use that?
If it is a lot of text then thereās a link in the forumās top bar to
This will easily let you copy+paste logs and share them.
1 Like
Great. So this time I put it to sleep and waited around 20 minutes. The computer itself did not shut down. Yet I just pressed the power button once and it immediately showed me the unlock screen. After inputting my password, the environment was as I had left it. The problem still stays - that the machine keeps working and does not power off. Anyways, I am adding here:
1 Like
And just now I put it to Sleep again, but waited just a bit longer than what it takes to shut down (whenever it works). Then I forced it off and started it again.
I copied journalctl --boot=-1
I suspect GPU on this (line 290)
Š“ŠµŠŗ 06 03:42:18 pc kernel: [TTM] Buffer eviction failed
Š“ŠµŠŗ 06 03:42:18 pc kernel: nouveau 0000:01:00.0: fb: trapped read at 0000989000 on channel -1 [3fed0000 unknown] engine 06 [BAR] client 08 [PFIFO_READ] subclient 00 [FB] reason 00000002 [PAGE_NOT_PRESENT]
Š“ŠµŠŗ 06 03:42:18 pc kernel: nouveau 0000:01:00.0: fb: trapped read at 0000989000 on channel -1 [3fed0000 unknown] engine 06 [BAR] client 08 [PFIFO_READ] subclient 00 [FB] reason 00000002 [PAGE_NOT_PRESENT]
Also systemd-hostnamed coredumps, but it maybe irrelevant or not.
You said you checked for "failed" in journal, although here it is.
Your nVidia is old and uses nouveau. I hope it's not the issue.
I searched for a nouveau bug, but there are several possibilities. You may want to try.
Also see if archwiki helps.
3 Likes
My card is GeForce 210. I also think it is the nouveau missbehaving, but I can only guess.
Is it possible to switch to Nvidia proprietary drivers?