From owner-freebsd-current@FreeBSD.ORG Tue Sep 17 14:36:33 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 05334142; Tue, 17 Sep 2013 14:36:33 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-qe0-x22f.google.com (mail-qe0-x22f.google.com [IPv6:2607:f8b0:400d:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id ACA8B2949; Tue, 17 Sep 2013 14:36:32 +0000 (UTC) Received: by mail-qe0-f47.google.com with SMTP id b4so3707808qen.20 for ; Tue, 17 Sep 2013 07:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9lxuU3/iO8hg85xnyYuk4hYa/WNEbi5GdVIEvpzeobw=; b=ZSk7ynszlmcHXEGcIrU4x/NpC22JImSKU8CYysFKVABo/cqj9srsIJd62na1MHNOec 0DPNWx5s1ddzuaZzAGz0IjFPIjpnoBgq2B/K9YxwxDM7E1sjZ8B1hOu5vu8S3WWnjso0 9d0VvuI7pPJE/vwWXkeKA5A5Cx5PazhYQqTzK8A5M+FTkCKrs3OJmZcHGBliaEO33ftJ /FWnzk5up1a0VVo0wpu7k9Vz6wCDznogXLRQlaJL/CKGywUMl9MrQIRf6iVLF3FUDKgI 5FnP6vEpijTvVOkBPgooUnyRggUYa8Fd1ppDBYUAoMBDVrdlgMsdd9Aa3AwwdWI7w8Be tM7w== MIME-Version: 1.0 X-Received: by 10.49.105.1 with SMTP id gi1mr54249631qeb.8.1379428590749; Tue, 17 Sep 2013 07:36:30 -0700 (PDT) Sender: asomers@gmail.com Received: by 10.49.39.97 with HTTP; Tue, 17 Sep 2013 07:36:30 -0700 (PDT) In-Reply-To: <20130917102110.GK4574@glebius.int.ru> References: <20130917102110.GK4574@glebius.int.ru> Date: Tue, 17 Sep 2013 08:36:30 -0600 X-Google-Sender-Auth: WCX01DwKovnGg6Ezft41_Oq9chc Message-ID: Subject: Re: ipmi patch for review From: Alan Somers To: Gleb Smirnoff Content-Type: text/plain; charset=ISO-8859-1 Cc: current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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: Tue, 17 Sep 2013 14:36:33 -0000 I ran into a very similar problem on stable/9. During a reboot, the system paniced because the watchdog slept when called from the syncer. I solved it by dropping the sync mutex in the syncer before patting the watchdog. It might be a more general solution that would also solve your problem. My patch and stack trace below. Syncing disks, vnodes remaining...7 7 7 5 Sleeping thread (tid 100145, pid 23) owns a non-sleepable lock KDB: stack backtrace of thread 100145: sched_switch() at 0xffffffff8091086d = sched_switch+0x13d mi_switch() at 0xffffffff808ee276 = mi_switch+0x196 sleepq_wait() at 0xffffffff80929672 = sleepq_wait+0x42 _sleep() at 0xffffffff808eeae8 = _sleep+0x3a8 ipmi_submit_driver_request() at 0xffffffff80c0df6f = ipmi_submit_driver_request+0xbf ipmi_set_watchdog() at 0xffffffff80c0e571 = ipmi_set_watchdog+0xb1 ipmi_wd_event() at 0xffffffff80c0e6bf = ipmi_wd_event+0x8f kern_do_pat() at 0xffffffff807d763f = kern_do_pat+0x9f sched_sync() at 0xffffffff8098779f = sched_sync+0x1df fork_exit() at 0xffffffff808b21af = fork_exit+0x11f fork_trampoline() at 0xffffffff80bd9ebe = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff88ce6a4bb0, rbp = 0 --- panic: sleeping thread ==== //SpectraBSD/stable/sys/kern/vfs_subr.c#3 (text) ==== @@ -1869,8 +1869,15 @@ continue; } - if (first_printf == 0) + if (first_printf == 0) { + /* + * Drop the sync mutex, because some watchdog + * drivers need to sleep while patting + */ + mtx_unlock(&sync_mtx); wdog_kern_pat(WD_LASTVAL); + mtx_lock(&sync_mtx); + } } if (!LIST_EMPTY(gslp)) { On Tue, Sep 17, 2013 at 4:21 AM, Gleb Smirnoff wrote: > Hi! > > When system is writing a kernel core dump, it issues watchdog > pat wdog_kern_pat(WD_LASTVAL). If ipmi is in action, it registers > ipmi_wd_event() as event for watchdog. Thus ipmi_wd_event() is > called in dumping context. > > The problem is that ipmi_wd_event() calls into ipmi_set_watchdog(), > that calls into ipmi_alloc_request(), which uses M_WAITOK and > thus sleeps. This is a smaller problem, since can be converted to > M_NOWAIT. But ipmi_set_watchdog() then calls into > ipmi_submit_driver_request(), which calls msleep() any time. > > The attached patch allows me to successfully write cores in > presence of IPMI. > > -- > Totus tuus, Glebius. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"