Date: 13 May 2014 02:03:22 -0000 From: Colin Percival <cperciva@freebsd.org> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/189745: ns8250 uart spin lock held too long Message-ID: <20140513020322.10781.qmail@clamshell.daemonology.net> Resent-Message-ID: <201405130220.s4D2K0Wp044571@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 189745
>Category: kern
>Synopsis: ns8250 uart spin lock held too long
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue May 13 02:20:00 UTC 2014
>Closed-Date:
>Last-Modified:
>Originator: Colin Percival
>Release: FreeBSD 10.0-RELEASE
>Organization:
>Environment:
FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC
6 identical panics reported via panicmail; all afflicted systems
were in EC2, i.e., with hw.broken_txfifo=1.
>Description:
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.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140513020322.10781.qmail>