Hi Mike,
On Wed, May 7, 2025 at 8:44 PM Mike Larkin <mlar...@nested.page> wrote:
>
> On Wed, May 07, 2025 at 12:18:53AM -0700, patrick keshishian wrote:
> > This is potentially a very dumb question; please bear with me.
> >
> > I have an older thinkpad currently running OpenBSD 7.6. I have
> > recently added more RAM to the thinkpad, so the swap partition is
> > smaller than available RAM.
> >
> > Is there a way I can prevent OBSD from entering hibernation state?
> >
> > Reading apmd(8), I didn't see anything obvious, but I got the false
> > hope that if any of the /etc/apm/{hibernate,standby,suspend} were to
> > exit with non-0 exit code, maybe the respective state transition would
> > be aborted. I tried zzz(8) with /etc/apm/suspend with only false(1),
> > but that did not prevent zzz(8) suspending.
> >
> > --patrick
> >
> > [longer background - can ignore]
> > In the dark, I must have fat-fingered and hit the Fn+suspend-to-disk
> > combination. I have never before attempted hibernation so I had no
> > idea what the process entails. The system seemed to go through
> > similar steps as it does during suspend, but after blanking the screen
> > the power button light continued flashing, and seemed to just continue
> > forever. I assume(d) b/c the swap size is too small for current
> > memory, the process was stuck in a loop. I eventually powered-off and
> > restarted, and never having experienced hibernation cycle, I learned
> > OBSD tried to unpack (I assume) an incomplete image, which after an
> > interesting graphics display dropped me into ddb :-)
> >
> > I am hoping there is a simple way to prevent hibernation from even
> > being attempted, at least, until I resize my swap partition.
> >
> > I assume the hibernate path is much too complicated and a simple if
> > (swap_size < mem) check to abort hibernation is infeasible.
> >
>
> We don't have that check. It wouldn't be that hard to add. I intentionally
> didn't do this before because:
>
> 1. we compress the image, and skip any unused pages. I've never seen a
> situation
> where we even came close to needing the full amount of swap equal to ram.
>
> 2. when we allocate swap, we need a contiguous extent anyway, so even saying
> "you must have as much swap as physical ram" really doesn't guarantee it
> will succeed either. If swap is heavily fragmented, you're out of luck,
> even if you have enough available in total.
>
> Could the heuristic be better? Sure. But TBH nobody really has complained
> too much about it and it's been like this for over a decade.
I didn't mean to be complaining. As I pointed out, I had never
even tried hibernating any of my systems. zzz(8) has been
sufficient for my use.
> If you want to add the check, I'd put it in uvm_hibswap. If you improve it
> substantially, to include extent checking for the max RAM size to avoid
> fragmentation, your diff would be welcome on tech@. Please share if that's
> the case. I'd be happy to review it.
I thought I would have more time this weekend to browse the code.
I will continue studying the code, however, I'm afraid it is likely
outside my ability/scope of knowledge.
I did notice a post to bugs@ dated 2025-05-10 [1] with subject
"suspend/resume/hibernate", stating that their system fails both
on zzz(8) and ZZZ(8). This makes me wonder if mine also is
failing on ZZZ(8) for some (similar?) reason. I have not yet
had a chance to run any tests. I will have some time in the
morning to do so.
I did not want you to think I ignored your reply. I have been
preoccupied.
Thanks for your time and response.
--patrick
> -ml
