Hello Kirill,

Thanks for the report.  Unfortunately the report is incomplete.  If you
can reproduce this issue, could you please send the information to bugs@
making sure that you get the trace of the cpu that paniced?  See below.

On 28/12/24(Sat) 22:15, Kirill Miazine wrote:
> panic of a rather fresh amd64 snapshot, probably 3-4 days old
> 
> 
> 
> text below is OCR-ed with a phone, proofread by me:
> 
> panic(ffffffff8245eb59) at panic+0xc2
> __assert(ffffffff82411a0a,ffffffff82438926,1c5,ffffffff823eb04f) at
> __assert+0x29
> amap_free(fffffd80506ac218) at amap_free+0x158
> uvm_unmap_detach(ffff800032399418,0) at uum_unmap_detach+0xc3
> sys_munmap(ffff8000ffff0338, ffff800032399530,ffff8000323994a0) at
> sys_munmap+0x186
> syscall(ffff800032399530) at syscall+0x620
> Xsyscall() at Xsysca11+0x128

This is CPU0, not the one that paniced

> end of kernel
> end trace frame: 0x7108d33299c0, count: 231
> End of stack trace.
> WARNING: SPL NOT LOWERED ON SYSCALL 72 8 EXIT 0 4
> Stopped at savectx+0xae: movl $0,%gs:0x680
> TID PID UID PRFLAGS PFLAGS CPU COMMAND
> 462835 55586 1000 0x100033 0 3 ping
> 495939 25031 1000 0x2200003 2 python3.12
> *190552 6630 1001 0x3 0x4000000 0 syncthing
> 374420 2561 0x14000 0x200 1 softnet0
> savectx() at savectx+0xae
> end of kernel
> end trace frame: 0xZcb766910, count: 14
> https://www.openbsd.org/ddb.html describes the minimum info required in bug
> reports.
> Insufficient info makes it difficult to find and fix bugs.
> ddb{0} > show panic
> cpu0: kernel diagnostic assertion "!rw_write_held(amap->am_lock)" failed:
> file /usr/src/sys/uum/uum_amap.c", line 453
> *срu3: kernel diagnostic assertion "off == trunc_page(off)" failed: file
> "/usr/src/sys/uvm/uvm_page.c", line 888

   ^^^^ 
  CPU3 is the one that one that interest us.  You can switch CPU in ddb
  with "mach ddbcpu 3".

Thanks,
Martin