"Fatal trap 12: page fault while in kernel mode" with latest -CURRENT

[David Taylor]

I've been getting this occasionally (a few times a day) since I upgraded
to -CURRENT yesterday.  I tried installing Bosko's Intel Data Corruption
patch today, to see if that changed anything, but it doesn't appear to
have worked.

I've currently only got access to one dump, as I changed my kernel earlier
today, but if it crashes again I'll add any more information I can get.

Here's the panic message/backtrace:

Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x2006218
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc0572ac6
stack pointer           = 0x10:0xd56bc904
frame pointer           = 0x10:0xd56bc91c
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1138 (mutt)
Dumping 256 MB
ata0: resetting devices ..
done
 16 32 48 64 80 96 112 128 144 160 176 192 208 224[CTRL-C to abort]  240
---
#0  doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1  0xc0452bb5 in db_fncall (dummy1=0x0, dummy2=0x0, dummy3=0x0,
    dummy4=0xd56bc6f8 "\200\026sÀ\f") at /usr/src/sys/ddb/db_command.c:548
#2  0xc0452902 in db_command (last_cmdp=0xc0730d20, cmd_table=0x0,
    aux_cmd_tablep=0xc06e43c0, aux_cmd_tablep_end=0xc06e43c4)
    at /usr/src/sys/ddb/db_command.c:346
#3  0xc0452a45 in db_command_loop () at /usr/src/sys/ddb/db_command.c:472
#4  0xc0455a45 in db_trap (type=0xc, code=0x0) at /usr/src/sys/ddb/db_trap.c:73
#5  0xc067719c in kdb_trap (type=0xc, code=0x0, regs=0xd56bc8c4)
    at /usr/src/sys/i386/i386/db_interface.c:172
#6  0xc0688826 in trap_fatal (frame=0xd56bc8c4, eva=0x0)
    at /usr/src/sys/i386/i386/trap.c:816
#7  0xc06884f2 in trap_pfault (frame=0xd56bc8c4, usermode=0x0,
eva=0x2006218)
    at /usr/src/sys/i386/i386/trap.c:735
#8  0xc06880ad in trap (frame=
      {tf_fs = 0x18, tf_es = 0x10, tf_ds = 0x10, tf_edi = 0xd56bcc00, tf_esi = 0xc497eb68, tf_ebp = 0xd56bc91c, tf_isp = 0xd56bc8f0, tf_ebx = 0x2006200, tf_edx = 0x4806, tf_ecx = 0xc497ec64, tf_eax = 0xc42bb000, tf_trapno = 0xc, tf_err = 0x0, tf_eip = 0xc0572ac6, tf_cs = 0x8, tf_eflags = 0x10206, tf_esp = 0xc497eb68, tf_ss = 0xc497eb68}) at /usr/src/sys/i386/i386/trap.c:420
#9  0xc0678b48 in calltrap () at {standard input}:102
#10 0xc0573137 in vfs_cache_lookup (ap=0x0)
    at /usr/src/sys/kern/vfs_cache.c:607
#11 0xc062b1a8 in ufs_vnoperate (ap=0x0)
    at /usr/src/sys/ufs/ufs/ufs_vnops.c:2792
#12 0xc05781f2 in lookup (ndp=0xd56bcbd8) at vnode_if.h:52
#13 0xc0577bde in namei (ndp=0xd56bcbd8) at /usr/src/sys/kern/vfs_lookup.c:183
#14 0xc058a143 in vn_open_cred (ndp=0xd56bcbd8, flagp=0xd56bccd8,
cmode=0x180, cred=0xc47d5980, fdidx=0x0) at /usr/src/sys/kern/vfs_vnops.c:193
#15 0xc0589ed0 in vn_open (ndp=0x0, flagp=0x0, cmode=0x0, fdidx=0x0)
    at /usr/src/sys/kern/vfs_vnops.c:93
#16 0xc05833a0 in kern_open (td=0xc47df980, path=0x0, pathseg=UIO_USERSPACE, flags=0x1, mode=0x1b6) at /usr/src/sys/kern/vfs_syscalls.c:688
#17 0xc0583250 in open (td=0x0, uap=0x0)
    at /usr/src/sys/kern/vfs_syscalls.c:654
#18 0xc0688b43 in syscall (frame= 
      {tf_fs = 0x2f, tf_es = 0x2f, tf_ds = 0xbfbf002f, tf_edi = 0x4, tf_esi = 0x2843dae0, tf_ebp = 0xbfbfef88, tf_isp = 0xd56bcd74, tf_ebx = 0x2842b804, tf_edx = 0x0, tf_ecx = 0x80ba3d7, tf_eax = 0x5, tf_trapno = 0x0, tf_err = 0x2, tf_eip = 0x283af90f, tf_cs = 0x1f, tf_eflags = 0x202, tf_esp = 0xbfbfef5c, tf_ss = 0x2f}) at /usr/src/sys/i386/i386/trap.c:1008
#19 0xc0678b9d in Xint0x80_syscall () at {standard input}:144

If anyone wants any more info from the dump, just ask...

-- 
David Taylor
davidt at yadt.co.uk
"The future just ain't what it used to be"