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());
}
