Thanks for the report. On 18/01/22(Tue) 22:46, Ralf Horstmann wrote: > >Synopsis: panic: kernel diagnostic assertion > >"uvm_page_owner_locked_p(pg)" failed: file "/usr/src/sys/uvm/uvm_page.c", > >line 1064 > >Category: kernel > >Environment: > System : OpenBSD 7.0 > Details : OpenBSD 7.0-current (GENERIC.MP) #248: Tue Jan 11 > 10:12:07 MST 2022 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > >Description: > The panic typically happens while using some X programs, in > most cases chromium. It can take days of uptime and occasional > system usage for the problem to show, sometimes but not always > with suspend and resume between boot and panic. > > I have seen the same diagnostics assertion with snapshots from > 2021-31-12, 2022-01-05 and now 2022-01-11. > > Even though I do have ddb enabled by default, the system does > not always enter ddb and print a backtrace. But for the most > recent case I have the following details and a backtrace > (typed from screen): > > Stopped at db_enter+0x10: popq %rbp > TID PID UID PRFLAGS PFLAGS CPU COMMAND > *310366 55004 0 0x14000 0x200 0K aiodoned > 508990 62541 0 0x14000 0x200 2 srdis > db_enter () at db_enter+0x10 > panic(ffffffff81e5053e) at panic+0xbf > __assert(ffffffff81ebcdc6,ffffffff81e23741,428,ffffffff81e718b1) at > __assert+0x25 > uvm_page_unbusy(ffff800022738d90,10) at uvm_page_unbusy+0x20e > uvm_aio_aiodone(fffffd81cd592360) at uvm_aio_aiodone+0x252 > uvm_aiodone_daemon(ffff8000fffefa40) at uvm_aiodone_daemon+0x124 > end trace frame: 0x0, count: 9
This is caused by an incorrect lock assertion. I just committed a fix. The problem can be triggered when swapping anon. It should be fixed in the next snapshot. Thanks again, Martin
