On Sun, May 11, 2025 at 11:32 PM patrick keshishian <pkesh...@gmail.com> wrote:
>
> 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

oops:
[1] https://marc.info/?l=openbsd-bugs&m=174687185416179&w=2

Reply via email to