Oh well I thought time to move onto 13.2 however this now exhibits the same behaviour as 13.1 + 3.18 kernel (13.1 + 3.11 kernel OK) in that it will not resume from S2RAM and is hard locked so only a reset will do. This is a clean install on a brand new SSD drive with home copied so no cruft left over.
I’ve tried both the Nvidia blob from the repos and 346.22 beta the hardway but the problem persists.
Any help on this would be greatly appreciated as I’m a bit stuck for my next step.
Well after using s2ram -f from a terminal resume and suspend to RAM works perfectly. So as far as I understand it looks like a pm-utils (or is it depreciated for systemd?) issue, can someone please correct me if I’m wrong ? I want to get to the bottom of this bug and would appreciate any help into getting the right info so a bug report filed.
Well, try uninstalling pm-utils and see if it works then.
If it is a pm-utils issue, I don’t think it makes sense to report it.
They are to be dropped soon anyway.
In 13.2 they originally weren’t used at all even when installed, but the old 13.1 behaviour (use pm-utils if they are installed) was restored by an update because of 904828 – systemd no longer calls pm-utils's sleep.d scripts on suspend/hibernate/resume .
Scatch that it seems to want to go to resume when it feels like it, it’s unpredictable when it wants to resume. I tried s2ram -f and it worked two times in a row then failed to work the next two times Grrrrr With nouveau it just resumes to a black screen but it is a maxwell card in the system, gtx750. I’ve got an ATI card (HD7770) in an other machine and a GT240 lying around somewhere so I’ll have a play around when I’ve the time to confirm or reject my suspicions that it is the GTX750/Nvidia blob/Kernel not playing nicely together.
If there is anything you could suggest debug wise on the current card setup I’m all ears and a willing pupil
Well, there definitely are problems with the nvidia driver and suspend.
There were long threads here and in the KDE forum about this, with “solutions” even, but none of that did really work. Except restarting kwin after the suspend (via a resume script e.g.), or disabling desktop effects.
There was even a bug report, but not much came out of it (the kernel developers blame the nvidia driver, the nvidia developers blame the kernel, no solution in sight…
What’s irritating is it all worked under 13.1, kernel 3.11 but hey that’s regressions for you. On 364.22 beta release notes it did say better suspend resume for later kernels but I can assure Aarron Plattner it doesn’t, time to drop him a mail and bug report.
Well, those threads I mentioned were about 13.1. But IIRC they even tried the then latest 3.15 and 3.16 kernels without much change.
Who knows? Maybe some “fix” for later kernels broke it for you, where it worked fine before? Wouldn’t be the first time something like this happens…
I cannot really help you more, just one thing: my BIOS has an option “Repost Video on S3 resume”. If you have something similar, try toggling it. That fixed problems for me (with radeon) in earlier versions (12.1?).
That’s effectively the same as the pm-utils options mentioned in that post I pointed to.
Correction - this doesn’t work. What seems to happen is that after reboot it will enter suspend to RAM and the resume only once or twice at best any more attempts than that then resume fails. After a reboot same cycle.
Back to the drawing board.
Trying options nvidia NVreg_EnableMSI=0 in /etc/modprode.d doesn’t work either.
After upgrading to Kernel 3.18.3-1.1.gc3e148f I can now reliably resume from suspend to RAM, tested five time in a row and it works ! This also fixes my problem with OS 13.1 and Kernel 3.18.1
However there is a caveat to this as Nouveau resume from RAM is broken but the Nvida blob works, this is also true for OS 13.1 + K3.18.1 - but I never use Nouveau anyway so I don’t know if this is the case for OS 13.1 + K3.11
So somewhere between K3.18.1 and K3.18.3 there is a Kernel bugfix that corrected the problem.
The bad news is my failure to resume from ram is back now I’ve connected everything together.
The good news is I’ve found the cause. It’s the pair of WD black 2TB drives. If either one of them is in or both then resume from RAM fails.
I’ve taken them out and tried lots of other drives in their place and S3 resume works for everything else but these drives, please note they are NTFS formatted.
I’ve tried both ext 4 and NTFS formatted other drives in their place and they all work perfectly.
These drives are definitely the root cause of my issue, now I need to find out why they worked under Kernel 3.11 but not later.
Any suggestions as to my next step would be appreciated.
The models are:
WD2003FZEX-00Z4SA0
and
WD2002FAEX-0
NB
BIOS is set to legacy boot and not UEFI.
The other drives I tried were all either 1gb or less, don’t know if 2gb size is important.
Hmmmm Don’t have a clue but 2 gig is pushing the limit for MBR (DOS) structured drives. So it is an edge case failure. GPT structured may have a better chance.
I’ve had a look at all the drives I have tested under Windows using Crystaldiskinfo and curiously the pair of WD 2TB don’t show the APM flag while all others do. Any ideas ?
Or some Kernel programmer didn’t know how to send them to sleep properly.
:sarcastic:
Looks like I’m going to have to bisect this one from OS 13.1 + K3.11 onwards, which will be a steep learning experience unless someone can rescue me with a brilliant flash of insight and intuition.
