From owner-freebsd-current@FreeBSD.ORG Mon Jan 23 13:07:45 2012 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A0F01065675; Mon, 23 Jan 2012 13:07:45 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id 9EE328FC12; Mon, 23 Jan 2012 13:07:44 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id q0ND7h63037552; Mon, 23 Jan 2012 17:07:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q0ND7hZd037551; Mon, 23 Jan 2012 17:07:43 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 23 Jan 2012 17:07:43 +0400 From: Gleb Smirnoff To: Andriy Gapon Message-ID: <20120123130743.GI16676@glebius.int.ru> References: <20120117110242.GD12760@glebius.int.ru> <20120120154158.GD16676@FreeBSD.org> <4F1ABFF3.9090305@FreeBSD.org> <20120122163539.GF16676@glebius.int.ru> <4F1D18A5.8010006@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4F1D18A5.8010006@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: current@FreeBSD.org Subject: Re: new panic in cpu_reset() with WITNESS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Jan 2012 13:07:45 -0000 On Mon, Jan 23, 2012 at 10:21:57AM +0200, Andriy Gapon wrote: A> > I can confirm that I can reboot succesfully with a new kernel A> > and kern.stop_scheduler_on_panic=0. A> A> This is very puzzling. You observation means that stop_scheduler_on_panic has A> an effect on the code outside the panic path. I reviewed the A> SCHEDULER_STOPPED() changes and I still can not see how that could be possible A> (modulo compiler bugs). A> A> Unfortunately, I also can not reproduce the problem here - without A> WITNESS_SKIPSPIN I am running into a panic[*] during boot. I suppose your patch (the one in other post) should help against this panic on boot. A> BTW, do you get any other LOR reports _before_ you do a reboot? I have some, but I don't think they are related. A> Can you try to change printfs in witness to db_printfs? Perhaps this will allow A> to get the details of the LOR in uart_cnputc. Maybe that will reveal some A> important additional details. Should I do s/printf/db_printf/ throughout entire subr_witness.c, or only in special places? A> Finally, can you try the patch from my other post? Yes, it works. -- Totus tuus, Glebius.