From owner-freebsd-current@FreeBSD.ORG Thu Jan 1 01:16:14 2015 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.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0286E5D for ; Thu, 1 Jan 2015 01:16:14 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7BE366474E for ; Thu, 1 Jan 2015 01:16:14 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id A8B381FE023; Thu, 1 Jan 2015 02:16:05 +0100 (CET) Message-ID: <54A4A002.8010802@selasky.org> Date: Thu, 01 Jan 2015 02:16:50 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivan Klymenko Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> In-Reply-To: <54A49CA5.2060801@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 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: Thu, 01 Jan 2015 01:16:14 -0000 On 01/01/15 02:02, Hans Petter Selasky wrote: > On 12/31/14 23:56, Ivan Klymenko wrote: >> В Mon, 29 Dec 2014 21:03:24 +0100 >> Hans Petter Selasky пишет: >> > > Hi, > > Is your kernel compiled with Witness? Do you see any lock order reversal > warnings? > > Can you do from kgdb: > > thread apply all bt > > And send me the result off-list? > > I'll have a closer look at this tomorrow. > >> >> panic: spin lock held too long >> http://paste.org.ru/?acf7io >> > > Thank you! > Hi, This backtrace looks incorrect, because I cannot find where teken code calls into callout_xxx(). --HPS cpuid = 2 KDB: stack backtrace: #0 0xffffffff80a03680 at kdb_backtrace+0x60 #1 0xffffffff809c19a1 at panic+0x1c1 #2 0xffffffff809a3d57 at _mtx_lock_spin_cookie+0x257 #3 0xffffffff809da367 at callout_lock+0x87 #4 0xffffffff809da3c0 at callout_restart_async+0x20 #5 0xffffffff809da22d at callout_reset_sbt_on+0xfd #6 0xffffffff809da64e at callout_schedule+0x2e #7 0xffffffff80c6c179 at teken_subr_do_putchar+0x79 #8 0xffffffff80c6b80e at teken_state_init+0x2ae #9 0xffffffff80c6d78e at teken_input_char+0x4e #10 0xffffffff80c6bb18 at teken_input+0x28 #11 0xffffffff80a15821 at termcn_cnputc+0xc1 #12 0xffffffff80961dd0 at cnputc+0x80 #13 0xffffffff809620e8 at cnputs+0xb8 #14 0xffffffff80a09561 at putchar+0x151 #15 0xffffffff80a08186 at kvprintf+0xf6 #16 0xffffffff80a09bad at _vprintf+0x8d #17 0xffffffff80a09dc3 at printf+0x53