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