On Tue, Nov 04, 2025 at 07:02:35AM -0800, Mike Larkin wrote: > On Tue, Nov 04, 2025 at 11:28:07AM +0100, Walter Alejandro Iglesias wrote: > > On Mon, Nov 03, 2025 at 09:38:55AM -0800, Mike Larkin wrote: > > > > After sending this message I tried hibernation in my old machine, an > > > > Intel Core 2 Duo with 4GB of RAM, where I have also OpenBSD installed. > > > > And it also takes a long time to hibernate there, with the added problem > > > > that when I turned it back on, I got a kernel panic. I'm not entirely > > > > > > what panic? > > > > > > > Let's start here, which is the data we already have. You can download > > from here the panic report (including screenshots): > > > > https://en.roquesor.com/Downloads/panic.tar.gz > > > > Besides: > > > > > 2. how long it takes to ZZZ immediately after a clean boot > > > > Right after booting I logged in and run from the console (without X): > > > > $ doas /usr/sbin/ZZZ > > > > I takse 34 seconds my new machine, 24 seconds my old one. I still think > > it's too much. > > Your diff to improve the situation is welcome on tech@.
When I shut up and hack and post patches in tech@ to fix bugs or make improvements *nobody* answers me. Last time with a vi(1) patch that gave me a lot of work I had to contact Todd C. Miller privately and ask him to make me the favor of review my patch. I realize that it's more effective to make a casual comment or criticism without a detailed bug report; at least I manage to get someone to respond by lecturing me. ;-) I am going to mention something as a compensation. On this machine, I have a UPS connected via USB that, while connected, due to some udev problem, Linux is not even able to suspend the machine; this does not happen with OpenBSD. :-) > > My guess is that this is not a hibernate image writing issue but rather > that some device(s) in the machine is taking a while to suspend. I made the tests in both machines with only a PS/2 keyboard and mouse connected. No worries. I'm not a fan of performance. I raised the question in case this was hiding some problem, especially considering the kernel panic of the old machine. > Based on > what you wrote below (that the machine unhibernates its image so fast that > you can't even read the message about how much it actually read), this > delay can't really be caused by the image writeout phase. My guess is that > it's writing about 100mb and there's no way that takes 34 seconds. > > > > > > 3. the size of the image (printed on resume as it's being read) > > > > If at some point at booting this is printed, at least in my two machines > > it's imposible to catch (I can scroll back in my console). I can't find > > anything in the logs later either. > > On resume, the machine will boot, then read the image. It will be printed > to the console as part of the boot messages. It will be the last line of the > "booting" dmesg. Maybe I am too old and foolish, but I don't see it. I'll try oppening heavy applications and see if the message appears. > > The fact that it is so fast indicates the image is likely completely > tiny and that your problems aren't related to the image writeout. > > If you'd like to verify that supposition, you can comment out the line > of code that actually does the write, and just immediately resume the > machine. Then we'll know for sure. > > -or- > > Time how long it takes 'zzz' (lowercase) to suspend. That goes through > the same codepath except doesn't do the image write. That would more > or less be the same measurement. Both machines suspend instantly. > > > > > > 4. results if setperf 100 improves things or not > > > > # sysctl hw.setperf=100 > > sysctl: hw.setperf: Operation not permitted > > > > > > -- > > Walter > -- Walter
