From owner-freebsd-current@FreeBSD.ORG  Tue Jun  8 11:54:11 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 6337A16A4CE; Tue,  8 Jun 2004 11:54:11 +0000 (GMT)
Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id A055A43D5A; Tue,  8 Jun 2004 11:54:10 +0000 (GMT)
	(envelope-from ianf@hetzner.co.za)
Received: from localhost ([127.0.0.1])
	by hetzner.co.za with esmtp (Exim 3.36 #1)
	id 1BXfB6-0005ba-00; Tue, 08 Jun 2004 13:54:04 +0200
To: John Baldwin <jhb@FreeBSD.org>, freebsd-current@freebsd.org
From: Ian FREISLICH <if@hetzner.co.za>
In-Reply-To: Message from Ian FREISLICH <if@hetzner.co.za> 
   of "Sat, 05 Jun 2004 23:44:09 +0200."
Date: Tue, 08 Jun 2004 13:54:04 +0200
Sender: ianf@hetzner.co.za
Message-Id: <E1BXfB6-0005ba-00@hetzner.co.za>
Subject: Re: It's happening again (panic early in boot) 
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2004 11:54:11 -0000

> John Baldwin wrote:
> > Hmm, darn inlines. :) Can you compile the kernel with either
> > INVARIANTS or MUTEX_NOINLINE so that mutex ops aren't inlined,
> > reproduce the panic and then do the same lookup using the new faulting
> > IP?
> 
> (kgdb) l * 0xc04b9828
> 0xc04b9828 is in _mtx_lock_flags (../../../kern/kern_mutex.c:247).
> 242     void
> 243     _mtx_lock_flags(struct mtx *m, int opts, const char *file, int line)
> 244     {
> 245
> 246             MPASS(curthread != NULL);
> 247             KASSERT(m->mtx_object.lo_class == &lock_class_mtx_sleep,
> 248                 ("mtx_lock() of spin mutex %s @ %s:%d", m->mtx_object.lo_
name,
> 249                 file, line));
> 250             WITNESS_CHECKORDER(&m->mtx_object, opts | LOP_NEWORDER | LOP_
EXCLUSIVE,
> 251                 file, line);
> 
> 
> Interstingly with INVARIENTS, the panic is exactly the same except
> for this (new) text at the end of the multiple panic:
> 
> panic: page fault
> at line 815 in file ../../../i386/i386/trap.ccpuid = 0; 
> Uptime: 1s
> panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../../..
/vm/vm_map.c:2876
> 
> at line 437 in file ../../../kern/kern_mutex.ccpuid = 0; 
> Uptime: 1s
> panic: _mtx_lock_sleep: recursed on non-rep

Well, this problem went away after I disabled ACPI.  I used to get
these before the latest ACPI merge:

acpi0: <GBT AWRDACPI> on motherboard
    ACPI-0265: *** Error: Hardware never changed modes
    ACPI-0168: *** Error: Could not transition to ACPI mode.
acpi0: Could not enable ACPI: AE_NO_HARDWARE_RESPONSE
device_probe_and_attach: acpi0 attach returned 6

Perhaps it now just blindly assumes that ACPI works and panics as
a result.  An off-line discussion with Nate revealed that this
board's version of ACPI will never be supported (even though it
worked with SMP in the early days - mid 2003 - and still works in
UP).

Ian

--
Ian Freislich