Strange Behaviour of Suspend-to-Ram (ACPI S3) on S1200V3RPL Server Board

[idata]

Hi there,

I have a system with a S1200V3RPL Server Board in an Intel P4000S chassis, using the latest available FW version S1200RP.86B.02.01.0004.

There are also two raid controllers installed:

Controller # 1: Intel RMS25JB080; FW version 13.00.66.00-IR

Controller # 2: Intel RMS25KB080; FW version 17.00.01.00-IR

I have been testing Suspend-to-Ram (ACPI S3) and it initially worked ok, but this was because I was suspending for a short period, say 1, 2, 5 or 10 minutes and then resuming. During suspend, the power led flashes as expected. Even for a longer period say 1 or 2 hours, it works ok.

However, when I resume after a period of many hours, e.g. greater than 12 hours for example, the system seems to perform a full boot with the POST startup (beeps) etc. As you can imagine, this is a time-consuming and difficult problem for me to investigate the cause - I have tried suspending for long periods, e.g. 4, 5, 6 hours, and for these kinds of periods it resumes ok without the full boot. I have only observed the full boot problem for periods of over 12 hours (although I haven't done extensive testing, so it could be the case that a lower period will cause the problem, e.g. 9 or 10 hours).

What is the cause of this strange behaviour? I would have thought that suspend-to-ram would either be

a) fully and correctly supported, or

b) not supported at all (e.g. show an error message when attempting to suspend),

but not this strange situation where it is 'partially' working, depending on the time period (which is frustrating, because it makes me believe it is fully working, only to later discover that it is not, which is of no use to anyone).

Thanks

Alex.

[David_A_Intel]

Let me investigate on this to see if I can replicate it on my end. I will post back as soon as possible since the issue seems to occur only after a given amount of hours.

When this occurs, does it actually reboot the entire system? Meaning that all of your open programs or files are not there.

[idata]

Hi there,

Yes that's correct - when I resume after a period of many hours, e.g. greater than 12 hours for example, the system seems to perform a full boot with the POST startup (beeps) etc. As such, the contents of RAM as they were at the point of the suspend, are lost.

I should also mention that the server OS is Fedora 20 Linux, with the latest kernel update at the time of writing (3.17.4-200.fc20.x86_64)

Thanks

Alex.

Note: I thought I had found a workaround by disabling the "Reboot on CATERR" option in the BIOS, which seems to prevent the issue, but occasionally seems to cause a different problem, whereby the server reboots immediately after initiating a suspend (as in, the system suspends, but then immediately resumes into a full boot with POST etc.)

[Salem_W_Intel1]

The fact the situation only takes place when and only when "[resuming] after a period of many hours, e.g. greater than 12 hours" (qtd. before), not only does it prove ACPI S3 does work, but it also shows the cause is something else. In light of this, and since Operating System-wise, you confirm it has the latest kernel updates, I would recommend the following (see steps below) in the event there is a BIOS corruption:

1. Clear the System Event Log and load up the BIOS default settings. For this, please, proceed as follows:

1.1. Boot into BIOS.

1.2. Once in BIOS, hit the F9 key to load up the BIOS default settings.

1.3. Go into the Server Management tab and enable the "Clear System Event Log" option.

Note: Reset any customized BIOS settings before continuing.

1.4. Hit the F10 to save the changes and exit.

2. Test. If the situation still takes place, because the most current BIOS one version is 02.02.0005, please, update this (click https://downloadcenter.intel.com/Detail_Desc.aspx?DwnldID=24418 here). The instructions on how to run the BIOS/firmware updating are found here:

http://downloadmirror.intel.com/24418/eng/Release.txt http://downloadmirror.intel.com/24418/eng/Release.txt

Please, repeat step 1.2 above right after the BIOS/firmware is updated.