Re: Panic on head (r255759) [_callout_stop_safe()-> panic: Lock lle not exclusively locked @ /usr/src/sys/kern/kern_rwlock.c:140]

From: Bryan Drewery <bdrewery_at_FreeBSD.org>
Date: Sat, 21 Sep 2013 14:23:31 -0500
On 9/21/2013 2:14 PM, Cy Schubert wrote:
> In message <523D8C39.4050307_at_FreeBSD.org>, Bryan Drewery writes:
>> This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
>> --bTOWMsw68o4sI8l0qJIHm7QU0StCi2OQm
>> Content-Type: text/plain; charset=ISO-8859-1
>> Content-Transfer-Encoding: quoted-printable
>>
>> On 9/21/2013 7:06 AM, Bjoern A. Zeeb wrote:
>>> On Sat, 21 Sep 2013, Bryan Drewery wrote:
>>> =20
>>>>> Unread portion of the kernel message buffer:
>>>>> panic: Lock lle not exclusively locked _at_
>>>>> /usr/src/sys/kern/kern_rwlock.c:140
>>>>>
>>>>> cpuid =3D 0
>>>>> KDB: stack backtrace:
>>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
>>>>> 0xfffffe118aeef820
>>>>> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe118aeef8d0
>>>>> vpanic() at vpanic+0x126/frame 0xfffffe118aeef910
>>>>> panic() at panic+0x43/frame 0xfffffe118aeef970
>>>>> __rw_assert() at __rw_assert+0xa3/frame 0xfffffe118aeef980
>>>>> _callout_stop_safe() at _callout_stop_safe+0x54/frame 0xfffffe118aeef=
>> 9f0
>>>>> arptimer() at arptimer+0x14e/frame 0xfffffe118aeefa30
>>>>> softclock_call_cc() at softclock_call_cc+0x188/frame 0xfffffe118aeefb=
>> 10
>>>>> softclock() at softclock+0x47/frame 0xfffffe118aeefb30
>>>>> intr_event_execute_handlers() at
>>>>> intr_event_execute_handlers+0x93/frame 0xfffffe118aeefb70
>>>>> ithread_loop() at ithread_loop+0xa6/frame 0xfffffe118aeefbb0
>>>>> fork_exit() at fork_exit+0x84/frame 0xfffffe118aeefbf0
>>>>> fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe118aeefbf0
>>>>> --- trap 0, rip =3D 0, rsp =3D 0xfffffe118aeefcb0, rbp =3D 0 ---
>>> =20
>>> =20
>>> +1 from me;  I  guess introduced somwhere between 255569 and 255758,
>>> as these are my edges of kernel.old and kernel.
>>> =20
>>
>> r255726 was stable for me. r255759 is not.
>>
>> r255755 converted ipfilter to callout, but I am unsure if that is the
>> problem.
> 
> I've been running the r255755 code locally on a couple of r255665 systems 
> for about a week with no problems but I'll check it again.
> 
> 

It's ok, the problem wasn't your commit afterall. I missed that another
made more impactful callout changes recently.

-- 
Regards,
Bryan Drewery


Received on Sat Sep 21 2013 - 17:23:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:41 UTC