r259286 panic
Aleksandr Rybalko
ray at dlink.ua
Mon Dec 16 23:48:23 UTC 2013
Hi guys!
I've investigate problem a bit. And can say that callout initialized with
callout_int(), w/o mpsafe flag:
callout_init(&vw->vw_proc_dead_timer, 0);
[sys/dev/vt/vt_core.c:1714]
And callout_init did not set CALLOUT_RETURNUNLOCKED flag, and assign it's
lock object to Giant, but where Giant lost on exit from callout I dunno :)
seems some bug somewhere much deep.
Eitan, do this 100% reproducible? If so, can you please try to replace
callout_init(&vw->vw_proc_dead_timer, 0);
with
callout_init(&vw->vw_proc_dead_timer, CALLOUT_MPSAFE);
at [sys/dev/vt/vt_core.c:1714] ?
Thanks!
2013/12/16 Alexander Motin <mav at freebsd.org>
> On 15.12.2013 22:22, Eitan Adler wrote:
>
>> On Sun, Dec 15, 2013 at 3:23 AM, Eitan Adler <lists at eitanadler.com>
>> wrote:
>>
>>> FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #7 r259286:
>>> Fri Dec 13 00:33:37 EST 2013
>>> eitan at gravity.local:/usr/obj/usr/src/sys/EADLER amd64
>>>
>>> Complete textdump here: http://people.freebsd.org/~
>>> eadler/files/core.txt.1
>>>
>>> My kernel is built with complete debug symbols, INVARIANTS, ddb, etc.
>>> but no WITNESS.
>>>
>>> I have vt and vt_vga enabled but not sc and vga (newcons, but not
>>> syscons).
>>>
>>
>>
>> Replying to myself with more data:
>>
>> gdb$ list kern_timeout.c
>> Can't find member of namespace, class, struct, or union named
>> "kern_timeout.c"
>> Hint: try 'kern_timeout.c<TAB> or 'kern_timeout.c<ESC-?>
>> (Note leading single quote.)
>> gdb$ list kern_timeout.c:700
>> 695 lastfunc = c_func;
>> 696 }
>> 697 #endif
>> 698 CTR1(KTR_CALLOUT, "callout %p finished", c);
>> 699 if ((c_flags & CALLOUT_RETURNUNLOCKED) == 0)
>> 700 class->lc_unlock(c_lock);
>> 701 skip:
>> 702 CC_LOCK(cc);
>> 703 KASSERT(cc->cc_exec_entity[direct].cc_curr == c,
>> ("mishandled cc_curr"));
>> 704 cc->cc_exec_entity[direct].cc_curr = NULL;
>> gdb$ p c
>> $1 = (struct callout *) 0xffffffff812121f8
>> gdb$ p *c
>> $2 = {
>> c_links = {
>> le = {
>> le_next = 0xfffffe0005f00318,
>> le_prev = 0xffffffff813aa690
>> },
>> sle = {
>> sle_next = 0xfffffe0005f00318
>> },
>> tqe = {
>> tqe_next = 0xfffffe0005f00318,
>> tqe_prev = 0xffffffff813aa690
>> }
>> },
>> c_time = 0x2c0d9170f2f51,
>> c_precision = 0xeffffeea,
>> c_arg = 0xffffffff81212148,
>> c_func = 0xffffffff8067e6e0 <vt_switch_timer>,
>> c_lock = 0x0,
>> c_flags = 0x80,
>> c_cpu = 0x0
>> }
>>
>>
>> From the 'vt_switch_timer' function it appears that something is wrong
>> with vt.
>>
>>
>> In addition avg@ mentioned that he wonders why class->lc_lock(c_lock,
>> ...) is protected by if (c_lock != NULL) but class->lc_unlock(c_lock)
>> does not have that guard.
>>
>
> It worked so far because callout_init() sets CALLOUT_RETURNUNLOCKED flag
> if there is no callout lock. I am not sure whether we should better add
> check or assertion to _callout_init_lock().
>
> So either VT passes something odd/NULL pointer to callout_init_mtx(), or
> something overwrites the callout structure after scheduling the callout.
>
> --
> Alexander Motin
>
--
WBW
-------
Rybalko Aleksandr <ray at dlink.ua>
aka Alex RAY <ray at ddteam.net>
D-Link.ua
More information about the freebsd-current
mailing list