On Sun, Feb 08, 2026 at 11:18:26AM +0100, Walter Alejandro Iglesias wrote: > 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. >
ok maybe... We have another report of similar crashes but only when X is used. I can't recall; does it fail for you (-current, without any of these diffs) if you don't run X? If you never tested that can you try? Just don't run X at all and do a ZZZ from the console. LMK. -ml > > 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
