Well, here's the thing - I am not even sure if it tried to load the hibernated image, or it failed in the middle, or it crashed after the load. When I powered it up after an s2d it went through the Acer logo, the boot prompt, the usual device laundry list shows up, the Intel graphics driver redrew the console, the USB configurations show up, one more line of text shows up for about 2 seconds, and then it was back to the Acer logo once again.
I had to do the same thing multiple times just to catch the line at the very end: unhibernating @ block 12872447 length 31971840 bytes I made an annotated video of the entire experience here: https://www.youtube.com/watch?v=-GTWnES_134 On Sat, Mar 14, 2015 at 6:56 PM, Mike Larkin <mlar...@azathoth.net> wrote: > On Sat, Mar 14, 2015 at 02:02:09PM -0400, Kevin Kwan wrote: > > Nope, hibernate/suspend to disk also causes a reset. Is there anything > > else I should try? > > Hibernate resume will perform what looks like a full boot. Did you let it > go through that or did you power off when you saw it booting again? > > Or did it load the hibernated image and *then* reboot? > > -ml > > > On Mar 14, 2015 1:22 PM, "Theo de Raadt" <dera...@cvs.openbsd.org> > wrote: > > > > > > My daily driver notebook is an Acer Aspire 1410 notebook. Penryn-ULV > > > > Celeron, Intel GS45 chipset, Intel Centrino 6205 (iwn) swapping a > > > > non-supported Atheros AR2425, 6GB of RAM, normal everyday HDD. > > > Everything > > > > seems to work in OpenBSD 5.6 except for the fact that every time I > put it > > > > on suspend (zzz), it suspends properly (LED indicators in the front > goes > > > > from blue to blinking orange), but when I take it out of suspend it > goes > > > > into instant amnesia, takes me back to the Acer boot logo, > > > > > > You mean the machine resets. > > > > > > > Okay, what should be my next steps here? I see from precursory > Google > > > > searches that the Linux guys had this problem back in the old Kernel > 3.3 > > > > days, and their workaround involves passing grub the i8042.reset > > > parameter, > > > > which seems to tell the on-board keyboard controller to clean up its > own > > > > mess. Any similar directives I can use here? > > > > > > Highly unlikely. > > > > > > Thanks for including all the information in the report. Result is a > > > few people can glance over it and look for hints (as I am about to > > > do). Unfortunately the few rare suspend/resume issues we see are > > > pretty hard to diagnose without access to failing machines. > > > > > > One thing is missing from your report. Does hibernate work?
