Date: Tue, 17 Dec 2013 01:41:46 +0200 From: Aleksandr Rybalko <ray@dlink.ua> To: Alexander Motin <mav@freebsd.org> Cc: Eitan Adler <lists@eitanadler.com>, freebsd-current Current <freebsd-current@freebsd.org> Subject: Re: r259286 panic Message-ID: <CAJ1Oi8HhRSGvuPVb_sQLqzeUAKy=oQFKRa2PO8ggwx6pBKS9Hg@mail.gmail.com> In-Reply-To: <52AEF86B.5080600@FreeBSD.org> References: <CAF6rxg=toapB1UuoqtmwT7Hwz=mzrVM9Zd7xgzWSM%2B9-WHydCw@mail.gmail.com> <CAF6rxg=eTf-VLDfjA=pA85idy1wFy=dgh2GgqDgFjJ%2B1kr0PoA@mail.gmail.com> <52AEF86B.5080600@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org> > On 15.12.2013 22:22, Eitan Adler wrote: > >> On Sun, Dec 15, 2013 at 3:23 AM, Eitan Adler <lists@eitanadler.com> >> wrote: >> >>> FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #7 r259286: >>> Fri Dec 13 00:33:37 EST 2013 >>> eitan@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@dlink.ua> aka Alex RAY <ray@ddteam.net> D-Link.ua
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ1Oi8HhRSGvuPVb_sQLqzeUAKy=oQFKRa2PO8ggwx6pBKS9Hg>