System no longer wakes up properly from suspend to RAM (sleep)

[eugenezastrogin]

My setup: #3 (comment)

After testing for a few weeks, it seems that removing ME caused my computer to stop waking up properly from suspend to RAM (sleep in windows 7). Both my Arch and Win 7 are affected (I dualboot). When I switch back to backup bios with ME, everything works properly (My motherboard has DualBios).

When you wake up the system it powers on, fans start working, etc but monitors do not lit up, only thing that works to resuscitate the system is power cycle. Post-mortem examination of systemd logs shows nothing.

P.S. Also, probably relevant note, one of the first times it didn't woke up properly it went into a nasty reboot loop after powercycle. Only thing that helped was resetting CMOS.

[techge]

Hello,

I am not sure, if it is really the ME. I had the same issue and it was because by newer kernel in ArchLinux. I know you said Win7 as well, but for me the issue stopped when going back to old lts-kernel. Have a look at https://bbs.archlinux.org/viewtopic.php?pid=1697646 .

But maybe it has really something to do with the ME, I do not know. I find it rather difficult to find the reason for misbehaviour now that I am always thinking "maybe it is the ME" ;-) (for example sudden freezing of system I hadn't before and I could not the reason yet; it does not seem to be connected with ME)

Greetings
techge

[eugenezastrogin]

I'm not sure either, didn't wanna cry wolf for a few weeks, but for now it seems to be the culprit. I've had quite a few kernel-specific problems with sleep on linux as well, so thought it might be one of those as well, but Windows proven me otherwise. My observation and conclusion could be a bit tainted - ME free BIOS is F10b, while backup one, which works is a bit older, F7. Unfortunately, I was unable to find a method to rollback BIOS version that worked for me, so possibly could be a GIGABYTE problem.

[persmule]

You could just decompress the GIGABYTE downloadable bios executable, which is actually a 7-zip sfx, and you will get a file whose size is a power of 2, e.g. a 16MiB Z87XUD3H.F7, which is THE firmware image. It could be flashed via flashrom(8) on a GNU/Linux, with ga-specific option, like

flashrom -p internal:dualbiosindex=0

for the main chip, and

flashrom -p internal:dualbiosindex=1

for the backup chip.

There is no lock on ME region with ga's firmware image, in order to allow dual-bios recovery mechanism work.

[eugenezastrogin]

Okay, thanks to persmule advice I was able to turn my observations into a proper scientific experiment, where:

1. MAIN BIOS: ME cleaned F7
2. BACKUP BIOS: vanilla F7.

Unfortunately, nothing has changed. ME cleaned BIOS caused both WIN and ARCH to fail to exit out of sleep, everything works perfect on vanilla image of F7. It seems after all that stripped ME is the culprit. :/

[skochinsky]

I think it could also be a BIOS issue. S3 resume is like a power-on but there is a much more limited hardware initialization done before replaying the S3 resume script and handing off execution back to the OS. So either the S3 path ME initialization fails somehow (e.g. it decides to hang if there is no reply from ME while it continues in the cold boot path) or somehow the S3 script replay goes wrong. Unfortunately, issues like these are pretty much impossible to debug without a hardware debugger.

[corna]

I agree with @skochinsky, unfortunately there isn't much we can do. Sometimes the BIOS hangs waiting for ME, like in the coreboot's Nehalem raminit.

This situation is quite uncommon though, as the BIOS should either fail on both power on and S3 resume, or it should work on both of them.