Re: r259286 panic
On 15.12.2013 22:22, Eitan Adler wrote: On Sun, Dec 15, 2013 at 3:23 AM, Eitan Adler li...@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.cTAB or 'kern_timeout.cESC-? (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 *) 0x812121f8 gdb$ p *c $2 = { c_links = { le = { le_next = 0xfe0005f00318, le_prev = 0x813aa690 }, sle = { sle_next = 0xfe0005f00318 }, tqe = { tqe_next = 0xfe0005f00318, tqe_prev = 0x813aa690 } }, c_time = 0x2c0d9170f2f51, c_precision = 0xeeea, c_arg = 0x81212148, c_func = 0x8067e6e0 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r259286 panic
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 m...@freebsd.org On 15.12.2013 22:22, Eitan Adler wrote: On Sun, Dec 15, 2013 at 3:23 AM, Eitan Adler li...@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.cTAB or 'kern_timeout.cESC-? (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 *) 0x812121f8 gdb$ p *c $2 = { c_links = { le = { le_next = 0xfe0005f00318, le_prev = 0x813aa690 }, sle = { sle_next = 0xfe0005f00318 }, tqe = { tqe_next = 0xfe0005f00318, tqe_prev = 0x813aa690 } }, c_time = 0x2c0d9170f2f51, c_precision = 0xeeea, c_arg = 0x81212148, c_func = 0x8067e6e0 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 r...@dlink.ua aka Alex RAY r...@ddteam.net D-Link.ua ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r259286 panic
On Mon, Dec 16, 2013 at 6:41 PM, Aleksandr Rybalko r...@dlink.ua wrote: 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] ? I can not reproduce it, despite trying. From memory here is what I saw: - X seemed frozen so I VT switched to the terminal - this took a long time - I plugged in a USB mouse - instant panic I have no idea if any of those are related (in particular, was the mouse just a fluke?). -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r259286 panic
On Sun, Dec 15, 2013 at 3:23 AM, Eitan Adler li...@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.cTAB or 'kern_timeout.cESC-? (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 *) 0x812121f8 gdb$ p *c $2 = { c_links = { le = { le_next = 0xfe0005f00318, le_prev = 0x813aa690 }, sle = { sle_next = 0xfe0005f00318 }, tqe = { tqe_next = 0xfe0005f00318, tqe_prev = 0x813aa690 } }, c_time = 0x2c0d9170f2f51, c_precision = 0xeeea, c_arg = 0x81212148, c_func = 0x8067e6e0 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. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org