Re: It's happening again (panic early in boot)

> 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 _at_ %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 _at_ ../../..
/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