r259286 panic
Alexander Motin
mav at FreeBSD.org
Mon Dec 16 12:56:17 UTC 2013
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
More information about the freebsd-current
mailing list