7.0-STABLE amd64 kernel trap during boot-time device probe

[Jeff Blank]

On Sun, Mar 02, 2008 at 09:56:46AM +1100, Peter Jeremy wrote:
> On Sat, Mar 01, 2008 at 02:44:04PM -0500, Jeff Blank wrote:
> >/boot/loader.conf (XXX_load=YES).  It seems to occur near the end of
> >device probing, just before it detects the disks.
> This is likely to be when the loaded modules get probed.

For what it's worth, this now (as opposed to in December/BETA4) seems
to happen for only 'sound' and 'netgraph' of the modules I normally
load at boot time.  The modules I use that are not those two and do
not depend on them, atapicam and geom_journal, do not cause the
trap/panic.  To be clear, I use 'sound' and 'netgraph' only because
'snd_ich' and 'ng_ubt' require them, but even if I only load 'sound'
or 'netgraph' in loader.conf and not the modules that depend on them,
the trap still occurs.

> Doing a verbose boot would probably also help.

I'll do that when I get a chance to capture output better.

For now, here's a stack trace from 'boot -D':

KDB: stack backtrace:
db_trace_self_wrapper() at 0xffffffff801bec2a = db_trace_self_wrapper+0x2a
panic() at 0xffffffff8048946a = panic+0x17a
trap_fatal() at 0xffffffff80747abf = trap_fatal+0x29f
trap_pfault() at 0xffffffff80747ea4 = trap_pfault+0x294
trap() at 0xffffffff8074886a = trap+0x2fa
calltrap() at 0xffffffff8072daee = calltrap+0x8
--- trap 0xc, rip = 0xffffffff8047d77e, rsp = 0xffffffffa062eb40, rbp = 0xffffffffa062eb60 ---
_mtx_lock_sleep() at 0xffffffff8047d77e = _mtx_lock_sleep+0x4e
ata_interrupt() at 0xffffffff80234184 = ata_interrupt+0x164
ata_generic_intr() at 0xffffffff80234e5f = ata_generic_intr+0x2f
ithread_loop() at 0xffffffff8046ccf0 = ithread_loop+0x180
fork_exit() at 0xffffffff8046987e = fork_exit+0x11e
fork_trampoline() at 0xffffffff8072debe = fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffffffa062ed30, rbp = 0 ---

/boot/loader.conf:

sound_load=YES
atapicam_load=YES
geom_journal_load=YES

This is a hand transcription (with checked and double-checked
addresses), as I don't have an available device for capturing serial
console output at the moment.  Is this what you need, or is there
something else I should do?

Thanks,
Jeff