From owner-freebsd-stable@FreeBSD.ORG Fri May 1 19:18:40 2009 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1682A1065676; Fri, 1 May 2009 19:18:40 +0000 (UTC) (envelope-from amesbury@umn.edu) Received: from mta-m3.tc.umn.edu (mta-m3.tc.umn.edu [134.84.135.123]) by mx1.freebsd.org (Postfix) with ESMTP id CFC3D8FC08; Fri, 1 May 2009 19:18:39 +0000 (UTC) (envelope-from amesbury@umn.edu) Received: from [160.94.247.212] (optimator.oitsec.umn.edu [160.94.247.212]) by mta-m3.tc.umn.edu (UMN smtpd) with ESMTP Fri, 1 May 2009 14:18:38 -0500 (CDT) X-Umn-Remote-Mta: [N] optimator.oitsec.umn.edu [160.94.247.212] #+LO+TS+AU+HN X-Umn-Classification: local Message-ID: <49FB4B0E.4060902@umn.edu> Date: Fri, 01 May 2009 14:18:38 -0500 From: Alan Amesbury User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: John Baldwin References: <49F8B859.7060908@umn.edu> <200905010947.54855.jhb@freebsd.org> <49FB2847.406@umn.edu> <200905011501.40083.jhb@freebsd.org> In-Reply-To: <200905011501.40083.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Garbled output from kgdb? 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: Fri, 01 May 2009 19:18:40 -0000 John Baldwin wrote: > This is odd. [snip] > The trace actually ends here. There is nothing super bad here but there is a > big problem actually in that the idle threads cannot block on a lock, so it > is a problem for the ACPI code to be acquiring a mutex here. Perhaps the > locks protecting the idle registers need to use spin locks instead. The > problem with blocking in the idle thread is that the scheduler assumes (even > requires) that the idle thread is _always_ runnable. I'm a bit out of my depth when it comes to kernel debugging. That said, if you can think of anything I can do or provide which might help narrow down the scope and nature of the bug (ACPI code in the host's firmware, an error in FreeBSD's ACPI support, etc.), let me know what needs to be done. I'll provide it to the list. It's a production host, so I'd like to keep disruptions to a minimum. That said, it's panicked more than once, so I think I can justify using it towards elimination of the cause of that panic if necessary. I appreciate you taking the time to look at it this far! Thanks! -- Alan Amesbury OIT Security and Assurance University of Minnesota