--- Comment #11 from Peter Grehan <> ---
It's ddb from within the guest. The signature is:

1 vCPU will panic with a lock-spin timeout:
CPU 11, panic spin lock 0xffffffff81ea0480 (smp rendezvous) held by
0xfffff800079da000 (tid 100093) too long
vpanic() at vpanic+0x1b9/frame 0xfffffe02ba76f6f0
panic() at panic+0x43/frame 0xfffffe02ba76f750
_mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x328/frame 0xfffffe02ba76f7d0
__mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xe0/frame 0xfffffe02ba76f810
smp_rendezvous_cpus() at smp_rendezvous_cpus+0xab/frame 0xfffffe02ba76f880
dtrace_sync() at dtrace_sync+0x77/frame 0xfffffe02ba76f8d0
dtrace_state_deadman() at dtrace_state_deadman+0x13/frame 0xfffffe02ba76f900

That spinlock is held by another vCPU that is waiting for an ack to it's IPI
--- trap 0x13, rip = 0xffffffff81033ac2, rsp = 0xfffffe02c8009860, rbp =
0xfffffe02c80098d0 ---
smp_targeted_tlb_shootdown() at smp_targeted_tlb_shootdown+0x352/frame
smp_masked_invlpg() at smp_masked_invlpg+0x4c/frame 0xfffffe02c8009900
pmap_invalidate_page() at pmap_invalidate_page+0x191/frame 0xfffffe02c8009950
pmap_ts_referenced() at pmap_ts_referenced+0x7b3/frame 0xfffffe02c8009a00
vm_pageout() at vm_pageout+0xe04/frame 0xfffffe02c8009a70

... and all other vCPUs are waiting on the lock held by the vCPU awaiting
the ack.
--- trap 0x13, rip = 0xffffffff80a8d222, rsp = 0xfffffe02c8349600, rbp =
0xfffffe02c8349610 ---
lock_delay() at lock_delay+0x42/frame 0xfffffe02c8349610
__mtx_lock_sleep() at __mtx_lock_sleep+0x228/frame 0xfffffe02c83496a0
__mtx_lock_flags() at __mtx_lock_flags+0xe8/frame 0xfffffe02c83496f0
vm_page_enqueue() at vm_page_enqueue+0x6b/frame 0xfffffe02c8349720
vm_fault_hold() at vm_fault_hold+0x1ab9/frame 0xfffffe02c8349850
vm_fault() at vm_fault+0x75/frame 0xfffffe02c8349890

You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________ mailing list
To unsubscribe, send any mail to 

Reply via email to