## run log -- UNPATCHED baseline kernel (#0)
## guest: DragonFly 6.5-DEVELOPMENT #0: Thu Jul  2 06:02:54 UTC 2026
## command:  kldload /tmp/df18_harness/df18_harness.ko
## result:   kernel panic via KKASSERT at kern_dmsg.c:1076
##           (serial console capture from dfbsd-qemu/boot.log lines 201-215)

login: df18: loading; creating pipe-backed kdmsg iocom...
df18: iocom up; writing CREATE+2xDELETE for msgid=42
panic: assertion "(state->rxcmd & DMSGF_DELETE) == 0" failed in kdmsg_state_msgrx at /usr/src/sys/kern/kern_dmsg.c:1076
cpuid = 5
Trace beginning at frame 0xfffff80117f5b940
kdmsg_msg_receive_handling() at kdmsg_msg_receive_handling+0xb39 0xffffffff80636d39 
kdmsg_msg_receive_handling() at kdmsg_msg_receive_handling+0xb39 0xffffffff80636d39 
kdmsg_iocom_thread_rd() at kdmsg_iocom_thread_rd+0x98 0xffffffff806380e8 
Debugger("panic")

CPU5 stopping CPUs: 0x0000001f
 stopped
Stopped at      Debugger+0x7c:  movb    $0,0xbdaf09(%rip)
db> 

## interpretation
The harness writes 3 raw dmsg headers to a pipe that backs a private kdmsg_iocom:
  1. CREATE  msgid=42  -> kdmsg_state_msgrx case DMSGF_CREATE inserts state into
                          staterd_tree (kern_dmsg.c:916), state->rxcmd = CREATE
  2. DELETE  msgid=42  -> case DMSGF_DELETE; state found via RB_FIND; line 943
                          check `(state->rxcmd & DMSGF_CREATE) == 0` is FALSE
                          (CREATE still set); error=0; line 1077 sets
                          state->rxcmd |= DMSGF_DELETE; line 1078 txcmd lacks
                          DELETE so RB_REMOVE NOT taken -- state stays in tree
  3. DELETE  msgid=42  -> state still in tree; line 943 still FALSE; error=0;
                          line 1075 enters DELETE block; line 1076
                          KKASSERT((state->rxcmd & DMSGF_DELETE) == 0) FIRES
                          because rxcmd now has DELETE -> panic

The panic is in kdmsg_state_msgrx (the receive-side state machine), called from
kdmsg_msg_receive_handling, called from the kdmsg_iocom_thread_rd reader thread
-- exactly the path any DMSG peer (HAMMER2 cluster / disk cluster / xdisk)
would drive.