Re: -10.0_BETA panics when system is rebooting

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

> Date: Fri, 6 Jan 2023 22:04:26 +0100
> From: BERTRAND Joël <joel.bertrand%systella.fr@localhost>
> 
> [ 856605,576197] uvm_fault(0xffffffff8190e240, 0xffffe80ea992e000, 4) -> e

This indicates that the kernel tried to execute code in the page at
0xffffe80ea992e000in kernel virtual address space (VM_PROT_EXECUTE=4),
but that led to a page fault.

> [ 856605,576197] fatal page fault in supervisor mode
> [ 856605,576197] trap type 6 code 0x11 rip 0xffffe80ea992e498 cs 0x8
> rflags 0x10246 cr2 0xffffe80ea992e498 ilevel 0x6 rsp 0xffffb504492c29f8

trap type 6 = T_PAGEFLT (same as `page fault' in line above)
code 0x11 = PGEX_P (0x01, page was present)
          | PGEX_I (0x10, exception during instruction fetch)
rip = 0xffffe80ea992e498, the instruction address which led to fault
cr2 = 0xffffe80ea992e498, the faulting address (same as rip, because
                          attempting to fetch the instruction faulted)

> [ 856605,576197] ?() at ffffe80ea992e498
> [ 856605,576197] priqclose() at netbsd:priqclose+0x4a

If you disassemble priqclose that might help identify what instruction
led to a call to ffffe80ea992e498.  However, I don't see a lot of
indirect calls in priqclose, so there is likely something else wrong
here.

> [ 856605,000596] acpiout5 at acpivga0 (DD.5961966] dump device bad
> 
> 	I don't understand last line as dmesg indicates :
> [     3,718620] boot device: raid0
> [     3,718620] root on raid0a dumps on raid0b
> 
> 	Unfortunately, I have replaced netbsd and netbsd.dbg by two new kernels
> and I cannot debug. I don't know if this kind of panic is already known.
> Next time I can reboot this server, I will try to obtain more information.

You might want to verify whether crash dumps work on your system by
using the crashme sysctl knobs to force a crash:

# sysctl -w debug.crashme_enable=1
# sysctl -w debug.crashme.panic=1

(Again: strongly recommend trying this in a VM that simulates your
setup -- e.g., raid on virtual disks in qemu -- so you can test it
without affecting production use!)