DF-2816 / serial.sibs-panic.log
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).