On Tue, Nov 04, 2025 at 05:32:55PM +0100, Walter Alejandro Iglesias wrote: > 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. ;-) >
squeaky wheel, you know what they say... > 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. > I think i have a couple experimental diffs that krw sent me that might show some improvement. lemme see if i can dig those up and send off-list. > > > > > > > > > 4. results if setperf 100 improves things or not > > > > > > # sysctl hw.setperf=100 > > > sysctl: hw.setperf: Operation not permitted > > > > > > > > > -- > > > Walter > > > > -- > Walter >
