From owner-freebsd-stable@FreeBSD.ORG Tue Jul 31 20:42:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64514106564A; Tue, 31 Jul 2012 20:42:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3A08B8FC14; Tue, 31 Jul 2012 20:42:52 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 92D86B946; Tue, 31 Jul 2012 16:42:51 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, sbruno@freebsd.org Date: Tue, 31 Jul 2012 16:34:24 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <1342742294.2656.24.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1342742294.2656.24.camel@powernoodle.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201207311634.24169.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 31 Jul 2012 16:42:51 -0400 (EDT) Cc: Subject: Re: [stable 9] panic on reboot: ipmi_wd_event() X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:42:52 -0000 On Thursday, July 19, 2012 7:58:14 pm Sean Bruno wrote: > Working on the Dell R420 today, got most of it working, even the > broadcom ethernet cards! However, I get the following when I reboot the > system: > > Syncing disks, vnodes remaining...4 Sleeping thread (tid 100107, pid 9) > owns a non-sleepable lock > KDB: stack backtrace of thread 100107: > sched_switch() at sched_switch+0x19f > mi_switch() at mi_switch+0x208 > sleepq_switch() at sleepq_switch+0xfc > sleepq_wait() at sleepq_wait+0x4d > _sleep() at _sleep+0x3f6 > ipmi_submit_driver_request() at ipmi_submit_driver_request+0x97 > ipmi_set_watchdog() at ipmi_set_watchdog+0xb1 > ipmi_wd_event() at ipmi_wd_event+0x8f > kern_do_pat() at kern_do_pat+0x10f > sched_sync() at sched_sync+0x1ea > fork_exit() at fork_exit+0x135 > fork_trampoline() at fork_trampoline+0xe Hmmm, the watchdog pat should probably happen without holding locks if possible. This is related to the IPMI watchdog being special and wanting to schedule a thread to work. -- John Baldwin