From owner-freebsd-current@FreeBSD.ORG Mon Dec 16 12:56:17 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EBCFBDC; Mon, 16 Dec 2013 12:56:17 +0000 (UTC) Received: from mail-bk0-x229.google.com (mail-bk0-x229.google.com [IPv6:2a00:1450:4008:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AC77B1DE6; Mon, 16 Dec 2013 12:56:16 +0000 (UTC) Received: by mail-bk0-f41.google.com with SMTP id v15so2301650bkz.14 for ; Mon, 16 Dec 2013 04:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bAHc93Z8XpJ5sCn/9XmRnrYtGZ5w5Ffc+zWD/ayuXX0=; b=trSWqCqwtS5G3g7TQRz3WwTZq+OsW6uge1lx5WgUdDYWUGrrzXQtkoTpWH30CCKGqO RBrtQxRTD8MzFWB5fC0x0KsLycDMiq4e+oUHhKHqwB7YkRphdugEz/HSbHUbd7VhsTCp 2IwJgc4VIpFcxymVyCYW6/AsMX4TTU1qPaSmqYTiT8upDrn4iNmnL42UnyU9A3Sp9tjj n7A1Bu9NvqZrwxJoFVu+RxSxX0BPywYFApvQAoXwFD1COZklmAI1Jgd8F/StnN0eIJui DfjD18zoSPGp1bNn5eXwCcB62y7wFjSSxTwARPKMq56LzWzEEiY+5C9w6uqcuCQhMLGo QpDg== X-Received: by 10.205.74.199 with SMTP id yx7mr210516bkb.163.1387198574823; Mon, 16 Dec 2013 04:56:14 -0800 (PST) Received: from mavbook.mavhome.dp.ua ([178.137.150.35]) by mx.google.com with ESMTPSA id a4sm10502666bko.11.2013.12.16.04.56.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Dec 2013 04:56:13 -0800 (PST) Sender: Alexander Motin Message-ID: <52AEF86B.5080600@FreeBSD.org> Date: Mon, 16 Dec 2013 14:56:11 +0200 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Eitan Adler , freebsd-current Current , Aleksandr Rybalko Subject: Re: r259286 panic References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 12:56:17 -0000 On 15.12.2013 22:22, Eitan Adler wrote: > On Sun, Dec 15, 2013 at 3:23 AM, Eitan Adler 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 or 'kern_timeout.c > (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 , > 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