Clear encrypted SWAP memory?

You missed the "-F" I had in my command. -F means "force". Your error message means "You have partitions on the device, either delete them all or use the -F to force things
Oops - sorry!. Thanks - that worked, took a while though.

But unfortunately the chromium browser session continues to be unresponsive in the workspace :( - seems like I will lose that unsaved tabs/work.

For future - maybe I should just turn off swap altogether? Given the sufficient memory. This is an annoying issue.
 
One could turn off swap or see if the behavior is different by not encrypting the swap.
At this point, if the swapoff on ada0p4 you could now edit /etc/fstab as I said earlier, then do a swapon /dev/ada0p4, swapoff /dev/gpt/tmpswap and wait.
It may (NOTE may) cause chromium to recover. Have you at least tried bookmarking the tabs?
 
One could turn off swap or see if the behavior is different by not encrypting the swap.
Ok - going to try it now

At this point, if the swapoff on ada0p4 you could now edit /etc/fstab as I said earlier, then do a swapon /dev/ada0p4, swapoff /dev/gpt/tmpswap and wait.
It may (NOTE may) cause chromium to recover
So I have dropped the ".eli" for the swap in the /etc/fstab - now will try
swapon /dev/ada0p4; swapoff /dev/gpt/tmpswap
Will report back - hoping this works!!
Have you at least tried bookmarking the tabs?
No - quite a lot of the tabs are in incognito - so even a session restore won't be handy. Don't ask why - just have this habitual way of working.
 
Will report back - hoping this works!!
Unfortunately the swapping the swap game didn't quite work - the browser instance continues to be unresponsive :( - very likely will result in loss of work ...... can't think of another way to recover from this - wish it was easier, phew. Guess i will have to kill the session from htop, if no other way.

But thanks for the help mer and others - appreciate it.
 
Each tab should be a separate process or thread so instead of killing the whole browser, try killing one or two threads and see if it recovers. That would result in minimum loss
 
Each tab should be a separate process or thread so instead of killing the whole browser, try killing one or two threads and see if it recovers. That would result in minimum loss
Yes - tried killing a few of those threads - didn't result in any response from the browsing session. This method is sometimes useful though when a tab is misbehaving wrt memory/cpu - helps get down the system load - but not in this particular case, unfortunately.
 
  • Like
Reactions: mer
Your browser might be unresponsive if the data is not available (lost on the old swap). So you might need to copy the links of the tabs to a document. Close the browser and clean up. Then restore the tabs afterwards. Have you restarted the system since the changes ???
 
Your browser might be unresponsive if the data is not available (lost on the old swap). So you might need to copy the links of the tabs to a document.
The browser starts to become unresponsive/lagging as soon as the swap space fills up (8G - usually happens when I close lid and the machine goes to sleep).
So you might need to copy the links of the tabs to a document. Close the browser and clean up. Then restore the tabs afterwards
After that random crashes start happening, with increasing frequency - until at one point it became totally unresponsive (this was the stage I described a couple of posts back). Hence no way to salvage the data.
Have you restarted the system since the changes ???
Yes - had to restart, the browser was totally unresponsive - even after trying to kill a few tabs from htop. Now the only config change is the ".eli" extension from /etc/fstab missing - which I presume means an unencrypted swap. Let's see - hopefully this shouldn't cause same issues 🤞
 
Basics. Tracker you should diagnose before drawing conclusions, or acting upon guesswork.

For definite, useful information about how swap is used, run:

systat -swap

I should not expect any improvement from non-encrypted swap.

Do not disable swap.
 
It contains
Code:
...
#For lid close sleep
hw.acpi.lid_switch_state=S3
...


I have yet to try and close the lid - swap is empty for now


Even with the available memory? 64G - what are the downsides?
There are reports of different problems and stange behavior on some machines with hw.acpi.lid_switch_state=S3
Some suggest using "hw.acpi.lid_switch_state=S5" instead. I know the powersavings are not as good. But it should be working well enough :)
Is your bios up to date ??
 
There are reports of different problems and stange behavior on some machines with hw.acpi.lid_switch_state=S3

Reports where?

Alternatives for sleep on lid close are:
. # acpiconf -s3
. # zzz (same as above)
. on Thinkpads, Fn + F4

Some suggest using "hw.acpi.lid_switch_state=S5" instead. I know the powersavings are not as good. But it should be working well enough :)

S5 is poweroff, not sleep. Same as shutdown -p

Power savings with poweroff are infinitely better ;-)

Is your bios up to date ??

Apparently. We're waiting to hear if not encrypting swap gives a different result, or solves it.
 
Reports where?

Alternatives for sleep on lid close are:
. # acpiconf -s3
. # zzz (same as above)
. on Thinkpads, Fn + F4



S5 is poweroff, not sleep. Same as shutdown -p

Power savings with poweroff are infinitely better ;-)



Apparently. We're waiting to hear if not encrypting swap gives a different result, or solves it.
Hi I do note use a laptop myself. So I cant test it but here:
https://forums.freebsd.org/threads/what-would-you-like-to-see-freebsd-do-differently.59058/page-2 (tobik)
https://github.com/helloSystem/ISO/issues/73
https://forums.freebsd.org/threads/what-does-not-work-very-good-on-freebsd.89893/page-2 BaronBS

And yes S5 is poweroff. My bad :(. I would use that instead on FreeBSD14. It boots so fast (10 seconds) And if you have a desktop set to restore previous section it will be good to go for me. If S2 or S1 works reliable I could also use them as an alternative to S3
 

Tobik said, 7 years ago:
"Suspend doesn't work correctly on a lot of laptops. I always have to fiddle with sysctls to make laptops properly suspend/resume with FreeBSD (if it works at all)."

Which is still true enough, some effort is required; FreeBSD disappoints those expecting it to suit their unique usage case OOTB, and hopefully always will.

It really pays to buy hardware known to support your desired features, especially for 'workstation', 'desktop' or 'laptop' use, as distinct from 'server' use, which must remain unimpeded by any bolt-on subsystems.


Issues with MacBooks: sure.


One anecdote amid assorted issues, this one the guy who used S5 when S3 didn't work (often issues resuming with the wrong video drivers, in my own anecdotal experience).

And yes S5 is poweroff. My bad :(. I would use that instead on FreeBSD14. It boots so fast (10 seconds) And if you have a desktop set to restore previous section it will be good to go for me.

Fair enough. Different for different people; I wouldn't regularly use any laptop without 100% reliable suspend & resume, but I don't reboot for months sometimes.

If S2 or S1 works reliable I could also use them as an alternative to S3

Unlikely, unless they appear in sysctl hw.acpi.supported_sleep_state

I've not seen one that does, but have only used T and X series Thinkpads since 2004, before then a Compaq Armada 1500c with reliable APM suspend.
 
The sleep/suspend landscape now is very different from the January 2017 landscape of the comment by tobik@. At least, the "always have to fiddle" part can't be true in 2024.

Sleep resume - caveats and gotchas. | The FreeBSD Forums

… FreeBSD disappoints those expecting it to suit their unique usage case OOTB, and hopefully always will.

It really pays to buy hardware known to support your desired features, …

A computer such as this is neither unique nor rare:

Product | HP EliteBook 650 G10 Notebook - 15.6" - Intel Core i7 - 1355U - 16 GB RAM - 512 GB SSD - UK

Boot is desirable.
 
The sleep/suspend landscape now is very different from the January 2017 landscape of the comment by tobik@. At least, the "always have to fiddle" part can't be true in 2024.

Maybe we need a revival of the old Laptop Compatibility List of yore? Or at least, $omeone dedicated to keeping the wiki up to date? Otherwise it still seems generally true in '24.


Sorry, I can't guess relevance to ... what, exactly?


No, but you and your individual usage patterns surely are.

Even Linux, with its relatively huge user and developer base, can't be all things to all people, like Windows tries hard to be (and at what cost?)

Boot is desirable.

Do you mean it doesn't boot? Please try being more explicit, my mindreading is broken ...
 
Do you mean it doesn't boot?

Yes, I'd like FreeBSD to boot. Installers fail to boot. I suspect that other hardware is similarly unusable, I'm taking advice elsewhere; the point here is that if you can neither boot nor install, use cases are irrelevant.



Tracker (opening poster) I'll respond to your question later, maybe at the weekend.
 

Do you mean it doesn't boot?
Yes, I'd like FreeBSD to boot. Installers fail to boot. I suspect that other hardware is similarly unusable, I'm taking advice elsewhere; the point here is that if you can neither boot nor install, use cases are irrelevant.

So this is now a separate issue from Tracker's case, to do with swap, and suspend /resume affecting it?

Is there a PR for this case?
 
Yes removing the .eli means "don't encrypt swap"
Seems like removing the ".eli" solved the issue. Now the swap isn't being used at all - which seems strange since it was regularly being used earlier, even though the memory was more than enough (64G). So all I did was "unencrypted" the swap.
I don't reboot for months sometimes.
This is what I aspire to do.
This somehow requires permissions and says Operation isn't permitted - didn't even realise this was a shortcut, also it doesn't show up in the alias list 🤔
 
Seems like removing the ".eli" solved the issue. Now the swap isn't being used at all - which seems strange since it was regularly being used earlier, even though the memory was more than enough (64G). So all I did was "unencrypted" the swap.
That is very odd.
So you edited /etc/fstab, removed the .eli, rebooted, did your typical workload, suspended, etc and it's not using swap now?

Very strange.
 
Tracker: you quote me as saying just

zzz

Please don't get in the bad habit of quoting a word or phrase out of context, when I said:
Alternatives for sleep on lid close are:
. # acpiconf -s3
. # zzz (same as above)
. on Thinkpads, Fn + F4

This somehow requires permissions and says Operation isn't permitted -

Are you not a member of group operator? For permission to suspend or shutdown the system? If not, su needed.

didn't even realise this was a shortcut, also it doesn't show up in the alias list 🤔

Why assume a 'shortcut', let alone a shell alias? Whenever in doubt, ask man (or apropos):
zzz(8)
 
Back
Top