> From: Jeremie Courreges-Anglas <j...@wxcvbn.org> > Date: Fri, 08 Oct 2021 18:19:47 +0200 > > 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.
Thanks for the heads up. Some sort of memory corruption, but no real clues what caused it.
