riscv64.ports was running dpb(1) with two other members in the build cluster. A few minutes ago I found it in ddb(4). The report is short, sadly, as the machine doesn't return from the 'bt' command.
The machine is acting both as an NFS server and and NFS client. OpenBSD/riscv64 (riscv64.ports.openbsd.org) (console) login: panic: pool_anic:t: pol_ free l: p mod fiee liat m oxifief:c a2e 07ff0ff fte21ade0 00f ifem c0d 1 07f1f0ffcf2177 010=0 c16ce6 7x090xc52c ! 0x9066d21 919 xc1521 Stopped at panic+0xfe: addi a0,zero,256 TID PID UID PR FLAGS PFLAGS CPU COMMAND 24243 43192 55 0x2 0 0 cc *480349 52543 0 0x11 0 1 perl 480803 72746 55 0x2 0 3 c++ 366351 3003 55 0x2 0 2K c++ panic() at panic+0xfa panic() at pool_do_get+0x29a pool_do_get() at pool_get+0x76 pool_get() at pmap_enter+0x128 pmap_enter() at uvm_fault_upper+0x1c2 uvm_fault_upper() at uvm_fault+0xb2 uvm_fault() at do_trap_user+0x120 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{1}> bt panic() at panic+0xfa panic() at pool_do_get+0x29a pool_do_get() at pool_get+0x76 pool_get() at pmap_enter+0x128 pmap_enter() at uvm_fault_upper+0x1c2 uvm_fault_upper() at uvm_fault+0xb2 uvm_fault() at do_trap_user+0x120 do_trap_user() at cpu_exception_handler_user+0x7a <hangs> The conserver logs for this console provide a hint about when it happened: --8<-- [-- MARK -- Fri Oct 8 08:00:00 2021] [-- MARK -- Fri Oct 8 09:00:00 2021] [-- MARK -- Fri Oct 8 10:00:00 2021] bt ^Mpanic() at panic+0xfa ^Mpanic() at pool_do_get+0x29a ... -->8-- It seems that Theo was plugging/unplugging usb cables at that time. I asked Theo to reboot the machine as I couldn't get more useful output. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
