DragonFlyBSD Kernel Audit
DF-2816 / serial.sibs-panic.log
← back to finding ↓ download raw
DF-2816 — sibs trigger (SIBS-MARK-1), serial console excerpt.
Reconstructed from the captured serial console session output (the raw
boot.log rotated when the wedged guest was force-restarted; console
garbling is genuine -- two CPUs were printing panics/boot output
simultaneously, itself evidence of the multi-CPU crossfire).

Command sequence (root):
  /root/sibs 4        # 4 siblings looping open("etc/passwd"); main calls
                      # reboot(RB_DUMP|RB_NOSYNC) after 1s

Serial output:

  sibs: calling reboot(RB_DUMP|RB_NOSYNC) with 4 live siblings
  boot() called on cpu#3
  Switching to cpu #0 for shutdown
  Waiting (max 60 seconds) for system thread swapcached to stop...stopped
  Waiting (max 60 seconds) for system thread vnlru to stop...stopped
  Waiting (max 60 seconds) for system thread consttyd to stop...stopped
  Waiting (max 60 seconds) for system thread bufdaemon to stop...stopped
  Waiting (max 60 seconds) for system thread bufdaemon_hw to stop...stopped
  panFic:aU pptage faulal tuser address a ccess from kernel mode from sibs at ffffffff806ee803

  Ftiatal trap 12:m page fault while ien kernel mode
  cpu:
  id = 3; lapic 28s
   idcpu i= d3 
  = 2
  Trace beginning at frame 0xfffff80117927328
  trap_fatal() at trap_fatal+0x301 0xffffffff80bd5081 
  trap_pfault() at trap_pfault+0x431 0xffffffff80bd5661 
  trap() at trap+0x17c 0xffffffff80bd5bcc 
  calltrap() at calltrap+0x9 0xffffffff80b991fa 
  --- trap 000000000000000c, rip = ffffffff806ee803, rsp = fffff80117927520, rbp = fffff801179275d8 ---
  naccess() at naccess+0x33 0xffffffff806ee803 
  nlookup() at nlookup+0x15e 0xffffffff806eee9e 
  boot() called on cpu#2
  Uptime: 28s
  kdmsg: iocom_uninit: shitcanning unresponsive pipe
  [... then unbounded repetition of:]
  send_ipiq 2->4 tgt not draining (75..134+)
  [... machine hard-wedged: no DDB prompt, no reboot, ssh dead until forced]

Decoding the garbled line (two CPUs interleaving "panic: page fault" and
"Fatal user address access from kernel mode from sibs at ffffffff806ee803"):
the faulting CPU is cpu3, instruction pointer 0xffffffff806ee803 =
naccess+0x33, i.e. the same NULL `nch->ncp` dereference as the race2 runs
(see serial.naccess-panic.log for the clean variant).