How I control type of memory suspend

[Marv]

I modified /etc/acpi/actions/suspend.sh and /etc/acpi/acpi.conf to give me a bit more flexibility in setting the suspend mode. The changes I made are attached as a pet. As usual, extract it and have a look before using.

A bit of context: There are two memory based suspend modes. s2idle is an older 'software based' suspend mode. It is compatable with older hardware that does not support the hardware based deep mode, available on most hardware since very roughly 2007 or so, depending on manufacturer. The deep mode relies more on the kernel and system firmware getting EVERYTHING just right and has much better power savings. It seems to be the default setting in most recent pups and kernels.

That said, I run a stable of Fujitsu S761 and S762 laptops circa 2012. They support the deep suspend mode but with age and lots of hours both of use and in deep suspend, I started to see some failures, first on my most used machine and then on 3 others in the stable. CMOS batteries replaced on all etc. The failure isn't in resuming from suspend, but rather that on rebooting thereafter the BIOS chip and/or its' flash memory isn't reset correctly. Best case is a split screen through the initial setup and boot then X takes over and corrects the mode. Worst case is a black screen through the initial BIOS setup/info. the grub4dos menu, and finally a split screen when the default pup boots. Kernel and pup independent over a broad range of both.

The cure is power off, charging cable out, battery out, and several hours sitting or a bit shorter time if the power button is held down. Variable and a real PITA.

Finally I experimented enough to get certain it was the deep suspend and tried the s2idle instead. A CURE.
I know, they're old, but extremely light, sturdy, capable and I have 7 of them running so this makes me happy.

I've tested it in VoidPup64 +14, S15Pup64 22.12 +2, LxPupSc64 23.01, fossapup64_9.6-radky6, and fossapup F96-CE so far. Just works. The one line added in suspend.sh is annotated and the lines added to acpi.conf should be self explanatory.

[mikewalsh]

@Marv :-

Suspending laptops IS - or CAN be - a right royal PITA. Suspending desktops is much, much easier. A single line script will usually do the job; in my case, the following performs the honours, because I've "dressed it up" a bit:-

Code: Select all

#!/bin/sh
#
#'Suspend' script for Puppy - with 30 second delay...
#
yad --undecorated --no-buttons --center --borders=30 --timeout=30 --timeout-indicator=top  \
--text="                                    
      SUSPENDING 'PUPPY' TO RAM IN 30 SECONDS......      
                                                                 
                                         PLEASE WAIT.....                         "
#
echo -n mem > /sys/power/state

This gives me plenty of time to switch my mouse off (keyboard powers-down automatically after 5 minutes of inactivity), and turn the monitor to standby. When I want to resume - usually, the next morning - I just switch the monitor back on, and tap the space bar.

Bob's yr uncle, up & running in seconds..! Especially handy when you're in the middle of summat 'fiddly'...

Mike.

[Marv]

Hi Mike, that one-liner is basically what the puppy suspend script does midst all its barnacles. I have written simple ones but try and keep the stocker mostly for simplicity of maintenance -or is it sloth? Just out of curiosity, check the contents of /sys/power/mem_sleep in your system. You can cat it or just open it with an editor. The active mode will have square brackets around it. Tthat's the one I switch to change modes as my lappies no longer tolerate the deep mode.

Jim

[mikewalsh]

@Marv :-

O-kay. Now; I wonder if I might "pick your brains" here?

Take it as a 'given' that this is not something I've ever attempted before. Frankly, it would have been pointless with the old Inspiron lappie; with that P4, and the fact that these CPUs were built prior to Intel adopting many of the 'sleep states' & 'low-power states' that we take for granted today, it would have been counter-productive.

The recently-acquired Dell Latitude D630, on the other hand, is a different kettle of fish altogether. Although it's only 4 or 5 years younger than the Inspiron, the use of a Core2Duo, as well as various other chipset and mobo improvements, means I can run thoroughly modern Pups, and do lots of stuff that was impossible with a 32-bit-only P4.

--------------------------------

So; assume that in this respect, despite a decade of Linux experience - most of that with Puppy - I'm a complete 'noob'. A total 'greenhorn'.....okay?

From what I've read above, as well as various other posts you've made over the years, you sound as though you've had some experience with this side of things. Now; in the simplest possible terms, what would be needed to set the Latitude up so that closing the lid will trigger 'suspend-to-RAM' (which from what I understand is the 'deep' state of /sys/power/mem_sleep.....yes?) And then to wake it up again upon opening the lid, so it's ready-to-go in the same state as when I suspended? How would I do this?

I'm right in assuming it's the wee magnetic reed switch in the front edge of the lid that triggers all this, yes?

(I've done a bit of reading already:- https://www.howtogeek.com/devops/how-to ... mand-line/ )

Fancy taking on a 'pupil' for a little while?

Mike.

[Marv]

@mikewalsh :

Morning Mike, I thought I responded last night but it got lost in blur of other things. At any rate, lets have a go at it.

Just so we're on the same page, what pup on that D630 do you want to start with? The basic structure hasn't changed since Tahr at least so assuming that or newer we're good. I've gotten quite hooked on my non savefile/folder pups when sky-diving, every boot is a fresh one. At any rate, the standard back up your save applies.

Yes that magnetic reed switch sends a signal that via the kernel that should result in the script 'suspend.sh' in /etc/acpi/actions being executed via a symlink in /etc/acpi/LID. Saving/renaming the stock suspend.sh, you can run something in an executable /etc/acpi/actions/suspend.sh to see if the message is getting through, perhaps: aplay "/usr/share/audio/bark.au"

If the message is getting through, the next small step is to try your one-liner in a terminal and see if you get a viable suspend and wake:

Code: Select all

echo -n mem > /sys/power/state

or perhaps my slightly more conservative two liner first:

Code: Select all

echo -n s2idle > /sys/power/mem_sleep

then:

Code: Select all

echo -n mem > /sys/power/state

OK for starters? If so, then on to what's the simplest viable suspend.sh or seeing if the stock one will fly. Any USB connection will keep the stock one from suspending, with pretty sound reason, but I am going to see how USB plays with a shallow (s2idle) suspend sometime.

Jim

[amethyst]

@Marv Have you tried my nicOS-PowerTimeout tool (more functions as well)? Note that this does not work with Slacko Puppys but should with other Puppys as far as I know. This tool is so cool, it's probably the most used tool by myself. I'm surprised that it has had so few downloads up to date to be honest.

[Phil_54]

@amethyst I will try your utility in hope.

@Marv
I have managed to do normal suspend on many pups/KLV/KLU/fatdog64 using the

Code: Select all

echo -n mem >/sys/power/state

script. If I don't close lid, I get minimal battery loss overnight for some but not all (could be kernel dependent). When I close the lid, after executing script or just closing lid, fan stops, no sound from drive, seems to be sleeping. Open lid, immediate reboot, without exception. Normally battery is fairly depleted too, if left overnight.
In mainstream iso's, lid suspends, battery drain overnight minimal.

I've tried some code suggested on other forums for suspending lid switch, but that doesn't seem to affect opening lid.
Suspend to idle works but I've not fully tested lid opening, as battery drain is almost equivalent to just blanking screen, i.e. processes keep running in background, so not much use to me.
I use a script to freeze

Code: Select all

echo -n freeze > /sys/power/state

my current puppy for short term lid closure (hour or two) which works, but battery drain is significant.

I know I've asked you before, and also on fatdog and elsewhere, if there are other options.
Without a solution either I leave lid open after suspend, or I just shut down, which takes quite a few seconds, before closing lid, and then reboot as required, which takes 45 to 55 seconds. Annoying but not life threatening.
I will eventually get a second hand laptop, when I find a good recommendation for puppylinux that has ample ram for interweb thingies, is suitable screen size and has good battery life still (Back Market seems promising). But I like squeezing this trusty chromebook.

[Marv]

@amethyst I have been aware of it but haven't, Since I'm pretty much an all Laptop operation (except for a couple of fanless BayTrail boxes that only draw 14 Watts running at max processor speed and 12 Watts suspended so it's pretty pointless there) a solid lid-suspend is all I really need. Pretty much since Tahr the stock suspend has just worked on my hardware and that simplifies my maintenance of the various users/machines. I do remember pulled hair on X-Slackos but that's a bit ago.

I have used your other tools and they're solid but being a dinosaur I really like to unsquash, manually modify and inspect, and then resquash. I was rummaging through my physical CD collection and the last remaster I did was circa 2015. The advent of extra _drv support really greatly simplified the manual process. On my savefile less pups I have a little toggle to temporarily enable a new savefile on shutdown if I make major changes, and I can simply add that to my working ydrv. Idiosyncratic, but that's me.

[Marv]

@Phil_54 Yes, the wake on lid opening seems beyond our control. I played trying to disable it when I had flaky lid switches but to no avail. It is easy to disable the stock puppy suspend, at least since Tahr, if you use an alternative method. In /etc/acpi/acpi.conf just uncomment the #DISABLE_SUSPEND='yes' line. The s2idle suspend is very much a fallback position for me as my aging laptops no longer support the deep suspend

Just for -no reason- I recompressed my FP64_CE main, ydrv, and zdrv files to gz from xz. Total time to working OS is now 17.0 seconds from on button-push to full OS. Recover from sleep is variable but averages roughly 5 seconds. Shutdown with no savefile is a second or two. This is on a 2nd gen i5 based lappie, circa 2012. Tempting to just hit shutdown, at least on this install.

[mikewalsh]

@Marv :-

O-kay. Now; first things first.

I don't appear to have a /sys/power/mem_sleep file. Furthermore, I also can't find any method in the BIOS for changing power management states (except for wake-on-lan, and that kind of thing).

The /etc/acpi/actions/suspend.sh file - the "stock" one - does absolutely nothing. Running it in the terminal just returns immediately to the prompt.

The one bit of good news is that running

Code: Select all

echo -n mem > /sys/power/state

.....from the terminal DOES suspend to RAM. On wake up via the power switch, however.....no network connection. It had to be set up again from scratch - like a 'first run' - as though it had never HAD a connection before. Sound about right?

Code: Select all

cat /sys/power/state

.....returns

Code: Select all

freeze mem

Mike.

[Marv]

@mikewalsh :
I just ran

Code: Select all

echo -n mem > /sys/power/state

in FP64_CE, both with deep in /sys/power/mem_sleep and with s2idle there. In both cases the connman connection survived intact. That has been true for LxPupSc64, VoidPup64, S15Pup64 and pretty much all of my pups in the past couple of years, both with PeasyWifi and with SNS connections. The suspend and wakeup process is a strong function of the kernel and it has gotten much better with newer kernels, ie. the 5 and 6 series. Older kernels it didn't, see below.

What pup & kernel are you in? In /etc/acpi is there an acpi.conf? Contents of that? The three conditions that should make the stock suspend.sh bail immediately are:
1. Any USB connection detected.
2. The DISABLE_SUSPEND='yes' line in /etc/acpi/acpi.conf not being commented out.
3. A pre-existing lock file from a failed suspend run. It would be tmp/acpi_suspend-flg

The stock suspend.sh file has a line in it post resume

Code: Select all

/etc/rc.d/rc.network restart

that is often commented out in more recent pups. You could try that post resume in terminal.

I've also attached (false .gz) a brutally trimmed suspend file you could try/modify.

Edit 05/02/2023: Trimmed suspend file pulled. Failed on intended hardware and was purely for diagnostic purposes.

[mikewalsh]

@Marv :-

Uh.....right. So you're telling me that any USB connection, of any sort, will throw a spanner in the works?

Ri-i-i-ight. So, before suspending, you're seriously telling me that I've got to disconnect my

External keyboard
External mouse
Headphones
Wireless USB dongle???
.....along with my webcam and media drive, because otherwise the suspend process will throw a wobbly? Oh, for f***s sakes.....that seems kinda self-defeating, to me. The desktop doesn't need everything unplugging, and that suspends fine. What makes laptops so "fussy"?

---------------------------------------------------------

This is Xenialpup64 with k4.9.58, so, yes; by most folks' definition quite an elderly and now unsupported Puppy. At which point most will wonder, "Why don't you run the very newest? You wouldn't have the problems then..."

I rarely, if ever, run the very newest of anything EXCEPT browsers. I've NEVER been obsessive about it, either. I don't WANT to run the very newest! Guess there's summat ever so slightly "off" about me, huh?

---------------------------------------------------------

/Etc/acpi/acpi.conf does exist. Contents as follows:-

Code: Select all

#/etc/acpi/actions/acpi_poweroff.sh read this
#TIME_LIMIT=30	# sec, no dialog if 0(zero).
#TIMEOUT_ACTION='poweroff'	# or 'suspend'
#DISABLE_SUSPEND='yes'
#DEBUG_MODE='yes'

--------------------------------------------------------

It's not a life or death matter, y'know! I was just curious as to whether it could be implemented easily, without TOO much messing about. If it's going to take a lot of messing around, I probably won't bother.

(In case you're wondering why I have so many things plugged into the laptop, this is what I have permanently set-up in the front room, so everything's ready for the occasions I keep Mama company...)

Mike.

[Marv]

Hi Mike,

Anyone who's slightly interesting has "summat ever so slightly "off" " about them. My "summat" is a love of tinkering. I was born to it

The USB restriction a. is old, and b. is primarily for the protection of the drives and to prevent changes in the drive enumeration when they come live again. I have run without it.

Yes laptops are more fiddly than desk iron but I'm glad I don't have to carry my Bay Trail boxes around.

Unplug the media drive and try the trimmed suspend.sh I posted (make it executable). It has no USB restriction and does try to restart the network after resume. I held my tongue and left

Code: Select all

aplay "/usr/share/audio/bark.au"

out of it.

Jim

[mikewalsh]

@Marv :-

Uh-huh. So I don't need to unplug the keyboard, mouse, webcam or headphones? Just anything that "identifies" as a drive.....even though, as in this case, it's purely data (movies, music, pictures & image files, etc, etc)?

The "media" drive is a relatively modern - and very tiny! - 256 GB SanDisk USB 3.2 Gen1 all-plastic Ultra Fit thumb drive. I had kinda hoped that, once plugged-in, I wouldn't be moving it again; the type of plastic SanDisk use extends to the actual port plug-in bit, too, and after relatively few plug-in/plug-out operations the plastic starts to crack at the corners of the connector. They ARE a bit fragile, but they're very reasonably-priced & blazing fast for a drive of that type - 90 MB/s write, 160-180 MB/s read - and the 'nano' design means you can tuck it away in a port round the back or side somewhere & basically forget about it...

In any case, it'll be tomorrow evening before I get a chance to experiment further - I visit all my regular forums in the morning, take care of any 'mod' duties here and over at BleepingComputer, then catch-up on other things. Afternoons are generally busy, then I don't really get any 'me-time' till after the evening meal...

We'll see how it goes tomorrow.

Mike.

[mikewalsh]

@Marv :-

Sorry to be a while getting back to you.

So far, the results are not looking promising on this D630 Latitude.....

To sum up:-

Xenialpup64 - k4.9.58

The 'one-liner' suspends fine. On recovery, the desktop's back & functional, but networking has to be set up again.
Your 'brutally' trimmed' script shuts down fine, but on resume, not only is there no network connection, but the desktop + everything else is frozen solid, and unresponsive. I can't tell if the network HAS resumed, because the only thing that works is the cursor.

Tahrpup64 - k3.14.79

Ditto as the above.

Fossapup64 - k5.4.53

Haven't had time to test this one yet. I will continue with these - as & when I get time - and update the test results accordingly... I'm NOT hopeful.

Mike.

[Marv]

@mikewalsh

Hi Mike, There's a phrase, Physician, do no harm. At this point given what's all connected to this laptop and as I understand, it doesn't travel, it might apply here. Clearly toss the trimmed script (retested on my hardware but I'd guess your USB mouse and keyboard aren't coming back up viable) and I'd say just run it with a screen saver option and pull your hairs out over a more noble cause. On my laptops, shutting down the screen cuts the power consumption by half, with the s2idle by half again. Nice but not worth doing harm to a solid working system...

If you do stop here, in /etc/acpi/acpi.conf, uncomment the DISABLE_SUSPEND='yes' line to get the suspend script totally out of the picture and see if the screen doesn't shut down on lid close. It does on my hardware.

Jim

Edited 05/02/2023: retested trimmed suspend here and thought about why it failed on your hardware.

[Phil_54]

@Marv

I recompressed my FP64_CE main, ydrv, and zdrv files to gz from xz. Total time to working OS is now 17.0 seconds from on button-push to full OS. Recover from sleep is variable but averages roughly 5 seconds. Shutdown with no savefile is a second or two. This is on a 2nd gen i5 based lappie, circa 2012. Tempting to just hit shutdown, at least on this install.

Umm, my ydrv and zdrv are sfs compression, not xz. I'm naive when it comes to this so help needed how to do what you did, as fast boot and shutdown seems a good place to be.

[amethyst]

@Marv

I recompressed my FP64_CE main, ydrv, and zdrv files to gz from xz. Total time to working OS is now 17.0 seconds from on button-push to full OS. Recover from sleep is variable but averages roughly 5 seconds. Shutdown with no savefile is a second or two. This is on a 2nd gen i5 based lappie, circa 2012. Tempting to just hit shutdown, at least on this install.

Umm, my ydrv and zdrv are sfs compression, not xz. I'm naive when it comes to this so help needed how to do what you did, as fast boot and shutdown seems a good place to be.

sfs is a an archived file. Different compression methods of the archived file are possible. So the sfs can be gz, xz, etc. compressed. xz compression gives the best compression ratio in terms of size but is slow compressing and decompressing. gz compression and decompression is much faster. All you need to do is to re-compress your sfs files. There are tools available to decompress the sfs and then rebuild it. Here is one of my tools you can use: https://forum.puppylinux.com/viewtopic. ... 46#p54846

[Phil_54]

Thanks. I've always skipped over comments about sfs files so I'll try this out and learn something! (Hopefully )