[Testers?] Suspend/Resume MDs....

[totallymaxed]

OK, I have the suspend script working in conjunction with hibernate/s2ram.

My hardware doesn't seem to know how to resume at all.... is there anybody out there that would be interested in testing this script on their MDs? And possibly telling me whether it resumes?

Nice work Colin;

Colin we'll give this a test on Mon/Tues if I can grab some time on one of our test Cores... will post back here our experiences.

All the best

Andrew

[jondecker76]

I'm just now getting some time to start on this. I had a question on one of the steps...

- make a copy of powerbtn.sh, then edit the original to point at /usr/pluto/bin/suspend.sh

I'm not sure exactly what you want to do at this step, can you explain a bit more?

thanks

Jon

[colinjones]

I'm just now getting some time to start on this. I had a question on one of the steps...

- make a copy of powerbtn.sh, then edit the original to point at /usr/pluto/bin/suspend.sh

I'm not sure exactly what you want to do at this step, can you explain a bit more?

thanks

Jon

Sorry Jon, I completely screwed up the instructions because I was trying to convert them from how I hacked it together into how it should be done in retrospect! So I got mixed up as to what was in each file Give me 5 mins and I will update the instructions...

EDIT: OK, the instructions are now updated!

[sambuca]

I'll give it a go. I was out of town this weekend, if not I would probably have tested it already 

I already have a working suspend/resume on one of my MDs, so I think this should be easy to test. But I also have had my share of problems with suspending, or more correctly resuming. In 704 I had suspend to ram working, but when 710 came out, they had removed the s2ram utility.. bummer. To make a long story short, I instead set it up to suspend to disk using a compact flash card.

btw, nice work Colin 

[sambuca]

ok, I tried your script, and it works fine for me. I used suspend to disk, but that should be the same from lmce's perspective.
It stops all devices and lastly kills the launch manager.

At resume, it does nothing (yet). You said you started the devices using Start_LocalDevices.sh, but that it does not start the MD DCE device? Not sure what you mean by that? The App server? Didn't have time to try this though, my wife wanted to use the TV 

But I did try to run the lmce_launch_manager.sh at resume via a resume hook, and that sort of worked. It started the launch manager and every device successfully, but it seemed like the resume script didn't end. I even tried to wrap the lmce_launch_manager.sh in a script with the fork (&) char at the end, but the script still did not return to the console. Didn't have time to try repeated suspend/resumes with this configuration though.

Btw. I noticed there is a enable_wol.sh script in /usr/pluto/bin folder. I guess it might be good to use that instead of the ethtool directly?

And one final suggestion: I've read (and experienced first hand) that suspend to disk is easier to get to work than suspend to ram. This is because when resuming from disk normal BIOS POST happens and starts the graphics card normally, in contrast to resume from ram where the OS needs to do much stuff. Maybe you will have more success trying s-to-disk?

I hope to do some more testing later this week.

br,
sambuca

[colinjones]

Great news, Sambucca, thanks for testing...

Yes, I hadn't done the resume bit yet, but my intention was to use the lmce_launch_manager.sh - you correctly noted that Start_LocalDevices.sh does not start the MD device itself. In my testing so far, just running this command at the shell after using the shutdown scripts (but not actually suspending) seemed to start everything back up successfully, so I would be interested in any further testing you do on this. That script doesn't exit (not checked why, just assumed that was normal, certainly it continues running after a reboot of my core...) when I executed it I used the & character as well... I guess the only untidiness is that it will be a job in that bash session, but that bash session in a script will soon terminate and leave the orphaned process running, just like a normally booted system, so do you think this is a real issue?

Agreed on the WOL point, will try that. Also, will look into the suspend to disk option... I think I have a disk somewhere, just not sure what I have to do to prepare it for this... doesn't 0710 MDs detect HDDs and use them as swap? Does it need to be partitioned and formated first? As what?

[sambuca]

In my testing so far, just running this command at the shell after using the shutdown scripts (but not actually suspending) seemed to start everything back up successfully, so I would be interested in any further testing you do on this. That script doesn't exit (not checked why, just assumed that was normal, certainly it continues running after a reboot of my core...) when I executed it I used the & character as well... I guess the only untidiness is that it will be a job in that bash session, but that bash session in a script will soon terminate and leave the orphaned process running, just like a normally booted system, so do you think this is a real issue?

The only problem might be that the script is started within the resume hook. Don't know how the resume system handles a script not exiting.

Agreed on the WOL point, will try that.

Not a big issue, I also used the ethtool directly in my scripts. I just noticed the other script today 

Also, will look into the suspend to disk option... I think I have a disk somewhere, just not sure what I have to do to prepare it for this... doesn't 0710 MDs detect HDDs and use them as swap? Does it need to be partitioned and formated first? As what?

Yes, it does detect swap partitions on HDDs and uses them. (Which is something I'd like to avoid, as I use a CF card for suspend to disk). You need to create a swap partition and possibly also do a mkswap on it. Also see the suspend wiki article for more information, there is some special considerations for LMCE.

br,
sambuca

[sambuca]

Hi,

I successfully tested suspending/resuming using this script today, with repeated suspend/resume cycles.

I added a new script to handle resume:
/usr/pluto/bin/resume.sh

Code: [Select]

#!/bin/bash

/usr/bin/screen -d -m -S "LMCE Launch Manager" /usr/pluto/bin/lmce_launch_manager.sh
It wraps the launch manager in a screen session, which detachs it from the console, letting the resume scripts return normally.
And added a resume hook to /etc/hibernate/scriptlets.d/lmce which now looks like

Code: [Select]

AddSuspendHook 15 LMCESuspend
AddResumeHook 15 LMCEResume

LMCESuspend() {
    /usr/pluto/bin/suspend.sh
}
LMCEResume() {
    /usr/pluto/bin/resume.sh
}

As far as I can see, this works perfectly.

br,
sambuca

[colinjones]

Great, OK, so focusing on suspend to disk, what do you think we need to do to add this into 0810? Are we confident enough of all the config and script files working on most platforms that this can be just static files added to the installation process? Also, has s2ram been added back into hibernate/uswsusp in 0810 or do we need to compile a version (like we did manually) and add it to the build?

[Marie.O]

Great, OK, so focusing on suspend to disk, what do you think we need to do to add this into 0810? Are we confident enough of all the config and script files working on most platforms that this can be just static files added to the installation process? Also, has s2ram been added back into hibernate/uswsusp in 0810 or do we need to compile a version (like we did manually) and add it to the build?

Especially for MDs, I do not think focusing on suspend to disk is such a grand idea. All my MDs are (going to be) diskless.

[colinjones]

Great, OK, so focusing on suspend to disk, what do you think we need to do to add this into 0810? Are we confident enough of all the config and script files working on most platforms that this can be just static files added to the installation process? Also, has s2ram been added back into hibernate/uswsusp in 0810 or do we need to compile a version (like we did manually) and add it to the build?

Especially for MDs, I do not think focusing on suspend to disk is such a grand idea. All my MDs are (going to be) diskless.

I agree, but as you can see from the thread, there are specific hardware issues particular to chipsets that cause s2ram to fail or fail if the right options are not specified... dunno how we can code for this as it seems to be a black art getting the right options for your specific hardware. I thought if we can get s2disk working reliably, s2ram can be bolted on afterwards by presenting the options to choose from based on the fact that the underlying suspend functionality works at least for s2disk.... what do you think?

Sambucca - forgot to ask, have you checked leaving your MD suspended for at least a day and then resuming? Just want to be sure that this mechanism genuinely deals with the TCP connections issues, and there isn't something else we need to cover as well.

[tschak909]

I really don't think you'll be able to handle the logistics of handling both suspend to ram, and suspend to disk, it may be too much of a headache.

-Thom

[colinjones]

I really don't think you'll be able to handle the logistics of handling both suspend to ram, and suspend to disk, it may be too much of a headache.

-Thom

Thom - if it is true, that suspend to disk is basically stable with static config files (ie no need for customised options based on the hardware you are using), then I think suspend to disk could be added to the build as a standard feature, couldn't it?

[tschak909]

but MD's are supposed to be _DISKLESS_ .

*hmm*

dammit, I do not wanna have this argument.

-Thom

[colinjones]

well lets just give up then.