Hi Mike, Unfortunately, I'm still able to reproduce the panic.
In case this is relevant. With #667 the panic followed by the debugger interface message happened right after the image was uncompressed. With current versions, I have to run startx to get a first single line message panic, and then reboot again to get a second panic with the debugger message. I can send you pictures if you want. On Sat, Feb 07, 2026 at 10:59:54AM -0800, Mike Larkin wrote: > On Sat, Feb 07, 2026 at 09:22:15AM -0800, Mike Larkin wrote: > > On Sat, Feb 07, 2026 at 09:09:13AM -0800, Mike Larkin wrote: > > > On Sat, Jan 17, 2026 at 07:53:14PM -0800, Mike Larkin wrote: > > > > On Sat, Jan 17, 2026 at 12:18:28PM +0100, Walter Alejandro Iglesias > > > > wrote: > > > > > This machine, apparently, hibernates correctly. Then, booting after > > > > > the > > > > > hibernation is complete, also apparently, unhibernates correctly. > > > > > But, > > > > > sometimes right after the image is uncompressed, sometimes after some > > > > > command is executed in the console, sometimes later, you always end up > > > > > with this same kernel panic (photos included in tarball): > > > > > > > > > > https://en.roquesor.com/Downloads/panic.tar.gz > > > > > > > > > > As I mentioned to mlarkin@ and krw@ in private, I knew for certain > > > > > that > > > > > this didn't happen with this machine. I used to test how it > > > > > hibernated > > > > > because I had it connected to a UPS when I used it (for many years) > > > > > as a > > > > > home mail-web server. And even though it's an old machine, I still > > > > > use > > > > > it occasionally, which is why I took the time to do the trace back. > > > > > > > > > > After three days installing snapshots I could find out in which one > > > > > the > > > > > panic starts happening and which modification causes it. > > > > > > > > > > This is the last snapshot working fine (the number of the beast :-): > > > > > > > > > > https://openbsd.cs.toronto.edu/archive/2025-05-22/amd64 > > > > > > > > > > kern.version=OpenBSD 7.7-current (GENERIC.MP) #666: Wed May 21 > > > > > 00:12:25 MDT 2025 > > > > > > > > > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > > > And this is the first when the issue appears: > > > > > > > > > > https://openbsd.cs.toronto.edu/archive/2025-05-23/amd64 > > > > > > > > > > kern.version=OpenBSD 7.7-current (GENERIC.MP) #667: Thu May 22 > > > > > 22:13:35 MDT 2025 > > > > > > > > > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > > > The modification that causes the issue is this: > > > > > > > > > > https://marc.info/?l=openbsd-cvs&m=174779996216651&w=2 > > > > > > > > > > After reverting those Mike's diffs in current, the panic disappears. > > > > > > > > > > > > > I'll take a look at those diff again but I don't see how this could be > > > > the > > > > problem. That diff just moved the allocation earlier. Maybe there's a > > > > double > > > > free. I'll look. > > > > > > > > -ml > > > > > > > > > > Hi Walter > > > > > > Can you try this diff on -current and let me know if this fixes it? > > > > > > diff /export/bin/src/OpenBSD/hib > > > path + /export/bin/src/OpenBSD/hib > > > commit - 12762e4337611beea64f8029adc3932766410745 > > > blob - 2b7924651df0c61efc89543ceacf5e7e5881e4ca > > > file + sys/kern/subr_hibernate.c > > > --- sys/kern/subr_hibernate.c > > > +++ sys/kern/subr_hibernate.c > > > @@ -2012,7 +2012,7 @@ hibernate_free(void) > > > pmap_activate(curproc); > > > > > > if (hibernate_temp_page) { > > > - pmap_kremove(hibernate_temp_page, PAGE_SIZE); > > > +// pmap_kremove(hibernate_temp_page, PAGE_SIZE); > > > km_free((void *)hibernate_temp_page, PAGE_SIZE, > > > &kv_any, &kp_none); > > > } > > > > > > > actually disregard, this isn't quit right either. I'll let you know when I > > have > > something fully baked. stay tuned. > > > > You can try this one instead. It replaces the km_alloc/km_free management of > the > temp page with a fixed stolen low VA (like we do for the other pages). I have > run this through about a dozen cycles here and it seems ok but since you can > repro, I'd like to know if I'm on the right track or not. > > Apply to -current on the affected machine and LMK. > > -ml > > > diff /export/bin/src/OpenBSD/hib > path + /export/bin/src/OpenBSD/hib > commit - 12762e4337611beea64f8029adc3932766410745 > blob - ec4e1904b741e23ee1df50ab3e807e90283c2fbc > file + sys/arch/amd64/include/hibernate_var.h > --- sys/arch/amd64/include/hibernate_var.h > +++ sys/arch/amd64/include/hibernate_var.h > @@ -52,8 +52,9 @@ > #define HIBERNATE_STACK_PAGE (PAGE_SIZE * 32) > > #define HIBERNATE_INFLATE_PAGE (PAGE_SIZE * 33) > +#define HIBERNATE_TEMP_PAGE (PAGE_SIZE * 34) > /* HIBERNATE_HIBALLOC_PAGE must be the last stolen page (see machdep.c) */ > -#define HIBERNATE_HIBALLOC_PAGE (PAGE_SIZE * 34) > +#define HIBERNATE_HIBALLOC_PAGE (PAGE_SIZE * 35) > > /* Use 4MB hibernation chunks */ > #define HIBERNATE_CHUNK_SIZE 0x400000 > commit - 12762e4337611beea64f8029adc3932766410745 > blob - 2b7924651df0c61efc89543ceacf5e7e5881e4ca > file + sys/kern/subr_hibernate.c > --- sys/kern/subr_hibernate.c > +++ sys/kern/subr_hibernate.c > @@ -66,7 +66,6 @@ CTASSERT((offsetof(union hibernate_info, sec_size) + s > */ > > /* Temporary vaddr ranges used during hibernate */ > -vaddr_t hibernate_temp_page; > vaddr_t hibernate_copy_page; > vaddr_t hibernate_rle_page; > > @@ -1527,13 +1526,14 @@ hibernate_write_chunks(union hibernate_info *hib) > case -1: > return EIO; > case 0: > - > pmap_kenter_pa(hibernate_temp_page, > + > pmap_kenter_pa(HIBERNATE_TEMP_PAGE, > inaddr & PMAP_PA_MASK, > PROT_READ); > > - > bcopy((caddr_t)hibernate_temp_page, > + > bcopy((caddr_t)HIBERNATE_TEMP_PAGE, > > (caddr_t)hibernate_copy_page, > PAGE_SIZE); > + > inaddr += hibernate_deflate(hib, > temp_inaddr, > &out_remaining); > @@ -1972,8 +1972,6 @@ hibernate_suspend(void) > int > hibernate_alloc(void) > { > - KASSERT(hibernate_temp_page == 0); > - > /* > * If we weren't able to early allocate a piglet, don't proceed > */ > @@ -1984,23 +1982,7 @@ hibernate_alloc(void) > pmap_kenter_pa(HIBERNATE_HIBALLOC_PAGE, HIBERNATE_HIBALLOC_PAGE, > PROT_READ | PROT_WRITE); > > - /* > - * Allocate VA for the temp page. > - * > - * This will become part of the suspended kernel and will > - * be freed in hibernate_free, upon resume (or hibernate > - * failure) > - */ > - hibernate_temp_page = (vaddr_t)km_alloc(PAGE_SIZE, &kv_any, > - &kp_none, &kd_nowait); > - if (!hibernate_temp_page) > - goto unmap; > - > return (0); > -unmap: > - pmap_kremove(HIBERNATE_HIBALLOC_PAGE, PAGE_SIZE); > - pmap_update(pmap_kernel()); > - return (ENOMEM); > } > > /* > @@ -2011,13 +1993,7 @@ hibernate_free(void) > { > pmap_activate(curproc); > > - if (hibernate_temp_page) { > - pmap_kremove(hibernate_temp_page, PAGE_SIZE); > - km_free((void *)hibernate_temp_page, PAGE_SIZE, > - &kv_any, &kp_none); > - } > - > - hibernate_temp_page = 0; > + pmap_kremove(HIBERNATE_TEMP_PAGE, PAGE_SIZE); > pmap_kremove(HIBERNATE_HIBALLOC_PAGE, PAGE_SIZE); > pmap_update(pmap_kernel()); > } -- Walter
