Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 08 Sep 2014 15:34:02 -0400
From:      Eric van Gyzen <eric@vangyzen.net>
To:        sbruno@freebsd.org, FreeBSD Net <freebsd-net@freebsd.org>
Subject:   Re: ixgbe(4) spin lock held too long
Message-ID:  <540E04AA.80806@vangyzen.net>
In-Reply-To: <1410203965.1343.3.camel@bruno>
References:  <1410203348.1343.1.camel@bruno> <1410203965.1343.3.camel@bruno>

next in thread | previous in thread | raw e-mail | index | archive | help
On 09/08/2014 15:19, Sean Bruno wrote:
> On Mon, 2014-09-08 at 12:09 -0700, Sean Bruno wrote:
>> This sort of looks like the hardware failed to respond to us in time?
>> Too busy?
>>
>> sean
>>
> This seems to be affecting my 10/stable machines from 15Aug2014.  
>
> Not a lot of churn in the code so I don't think this is new.  The
> afflicted machines, quite a few by my count, appear to have not been
> super busy (pushing about 200 Mb/s).
>
> sean
>
>
>
>> panic: spin lock held too long
>>
>> GNU gdb 6.1.1 [FreeBSD]
>> Copyright 2004 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you
>> are
>> welcome to change it and/or distribute copies of it under certain
>> conditions.
>> Type "show copying" to see the conditions.
>> There is absolutely no warranty for GDB.  Type "show warranty" for
>> details.
>> This GDB was configured as "amd64-marcel-freebsd"...
>>
>> Unread portion of the kernel message buffer:
>> spin lock 0xffffffff812a0400 (callout) held by 0xfffff800151fe000 (tid
>> 100003) too long

TID 100003 is usually a kernel idle thread, which would seem to indicate
a dangling lock.  Can you enable WITNESS (without WITNESS_SKIPSPIN) on
this box?

>> panic: spin lock held too long
>> cpuid = 4
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>> 0xfffffe1f292752b0
>> panic() at panic+0x155/frame 0xfffffe1f29275330
>> _mtx_lock_spin_cookie() at _mtx_lock_spin_cookie+0x243/frame
>> 0xfffffe1f29275390
>> callout_lock() at callout_lock+0xd4/frame 0xfffffe1f292753d0
>> callout_reset_sbt_on() at callout_reset_sbt_on+0x10b/frame
>> 0xfffffe1f29275450
>> tcp_timer_activate() at tcp_timer_activate+0xe7/frame 0xfffffe1f29275470
>> tcp_do_segment() at tcp_do_segment+0x96/frame 0xfffffe1f292755b0
>> tcp_input() at tcp_input+0xeed/frame 0xfffffe1f292756f0
>> ip_input() at ip_input+0x97/frame 0xfffffe1f29275740
>> netisr_dispatch_src() at netisr_dispatch_src+0x62/frame
>> 0xfffffe1f292757b0
>> ether_demux() at ether_demux+0x126/frame 0xfffffe1f292757e0
>> ether_nh_input() at ether_nh_input+0x349/frame 0xfffffe1f29275840
>> netisr_dispatch_src() at netisr_dispatch_src+0x62/frame
>> 0xfffffe1f292758b0
>> tcp_lro_flush() at tcp_lro_flush+0x198/frame 0xfffffe1f292758d0
>> ixgbe_rxeof() at ixgbe_rxeof+0x6b3/frame 0xfffffe1f29275990
>> ixgbe_msix_que() at ixgbe_msix_que+0xba/frame 0xfffffe1f292759e0
>> intr_event_execute_handlers() at intr_event_execute_handlers+0xab/frame
>> 0xfffffe1f29275a20
>> ithread_loop() at ithread_loop+0x96/frame 0xfffffe1f29275a70
>> fork_exit() at fork_exit+0x9a/frame 0xfffffe1f29275ab0
>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe1f29275ab0
>> --- trap 0, rip = 0, rsp = 0xfffffe1f29275b70, rbp = 0 ---
>> Uptime: 8d20h4m58s
>>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?540E04AA.80806>