Description Colin Percival 2014-05-13 03:20:00 UTC

panic: spin lock held too long

#2  0xffffffff808af8f4 in panic (fmt=<value optimized out>)
    at /usr/src/sys/kern/kern_shutdown.c:754
#3  0xffffffff8089cb71 in _mtx_lock_spin_cookie (c=<value optimized out>, 
    tid=<value optimized out>, opts=<value optimized out>, 
    file=<value optimized out>, line=<value optimized out>)
    at /usr/src/sys/kern/kern_mutex.c:554
#4  0xffffffff80725223 in ns8250_bus_ipend (sc=0xfffff800083fc400)
    at uart_cpu.h:92
#5  0xffffffff80723fe7 in uart_intr (arg=0xfffff800083fc400) at uart_if.h:87
#6  0xffffffff80883e5b in intr_event_handle (ie=0xfffff8000819c200, 
    frame=0xfffffe03a5ff8870) at /usr/src/sys/kern/kern_intr.c:1437
#7  0xffffffff80d8d1c8 in intr_execute_handlers (isrc=0xfffff800081bf168, 
    frame=0xfffffe03a5ff8870) at /usr/src/sys/x86/x86/intr_machdep.c:269

In some panic reports there were _mtx_lock_spin_cookie -> printf -> vprintf
-> kvprintf -> putchar -> cnputs -> cnputc -> uart_cnputc cycles as a result
of the bug being re-trigerred by attempting to print the "spin lock ... held
... too long" warning.  (Which may be something worth fixing separately, by
detecting the loop and skipping straight to the panic call.)

No console output is available (panicmail does not submit it) so I don't know
which thread was holding the spin lock for so long; but it clearly unlocked
eventually since the "spinning too long -> printf -> spinning too long" cycles
were not infinite.

How-To-Repeat: 
No idea.  This panic is strongly correlated with residing in EC2, but it may
merely be caused by the broken_txfifo option since EC2 is where that option
is most often used.