page fault

[Dan]

Kostik Belousov wrote:
> On Tue, Jul 28, 2009 at 10:33:16AM -0400, Dan wrote:
>> Hi,
>>
>> One of my servers running 7.2-RELEASE-p2 is crashing about every 2 or 3 
>> days with the following backtrace.  This particular one is from July 
>> 24.I still have all the vmcores available if any further info is required.
>>
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 0; apic id = 00
>> fault virtual address   = 0x0
>> fault code              = supervisor read, page not present
>> instruction pointer     = 0x20:0xc077b9e8
>> stack pointer           = 0x28:0xe846ab34
>> frame pointer           = 0x28:0xe846ab58
>> 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         = 42384 (perl5.10.0)
>> trap number             = 12
>> panic: page fault
>> cpuid = 1
>> Uptime: 1d23h35m17s
>> Physical memory: 2023 MB
>> Dumping 257 MB: 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2
>>
>> Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from 
>> /boot/kernel/accf_http.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/accf_http.ko
>> Reading symbols from /boot/kernel/acpi.ko...Reading symbols from 
>> /boot/kernel/acpi.ko.symbols...done.
>> done.
>> Loaded symbols for /boot/kernel/acpi.ko
>> #0  doadump () at pcpu.h:196
>> 196             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
>> (kgdb)
>>
>> (kgdb) where
>> #0  doadump () at pcpu.h:196
>> #1  0xc07ddbe7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
>> #2  0xc07ddeb9 in panic (fmt=Variable "fmt" is not available.
>> ) at /usr/src/sys/kern/kern_shutdown.c:574
>> #3  0xc0a818ac in trap_fatal (frame=0xe846aaf4, eva=0)
>>     at /usr/src/sys/i386/i386/trap.c:939
>> #4  0xc0a81b10 in trap_pfault (frame=0xe846aaf4, usermode=0, eva=0)
>>     at /usr/src/sys/i386/i386/trap.c:852
>> #5  0xc0a82492 in trap (frame=0xe846aaf4) at 
>> /usr/src/sys/i386/i386/trap.c:530
>> #6  0xc0a675ab in calltrap () at /usr/src/sys/i386/i386/exception.s:159
>> #7  0xc077b9e8 in pfs_ioctl (va=0xe846ab88)
>>     at /usr/src/sys/fs/pseudofs/pseudofs_vnops.c:247
>> #8  0xc0a965e2 in VOP_IOCTL_APV (vop=0xc0be6200, a=0xe846ab88)
>>     at vnode_if.c:795
>> #9  0xc086d68d in vn_ioctl (fp=0xc58d45f0, com=1076655123, data=0xc61b0440,
>>     active_cred=0xcb9d8500, td=0xc5e5e000) at vnode_if.h:437
>> #10 0xc0816a05 in kern_ioctl (td=0xc5e5e000, fd=3, com=1076655123,
>>     data=0xc61b0440 "") at file.h:269
>> #11 0xc0816b64 in ioctl (td=0xc5e5e000, uap=0xe846acfc)
>>     at /usr/src/sys/kern/sys_generic.c:571
>> #12 0xc0a81e65 in syscall (frame=0xe846ad38)
>>     at /usr/src/sys/i386/i386/trap.c:1090
>> #13 0xc0a67610 in Xint0x80_syscall () at 
>> /usr/src/sys/i386/i386/exception.s:255
>> #14 0x00000033 in ?? ()
>> Previous frame inner to this frame (corrupt stack?)
>> (kgdb)
>>
>> (kgdb) l *0xc077b9e8
>> 0xc077b9e8 is in pfs_ioctl (/usr/src/sys/fs/pseudofs/pseudofs_vnops.c:248).
>> 243     static int
>> 244     pfs_ioctl(struct vop_ioctl_args *va)
>> 245     {
>> 246             struct vnode *vn = va->a_vp;
>> 247             struct pfs_vdata *pvd = vn->v_data;
>> 248             struct pfs_node *pn = pvd->pvd_pn;
>> 249             struct proc *proc;
>> 250             int error;
>> 251
>> 252             PFS_TRACE(("%s: %lx", pn->pn_name, va->a_command));
> 
> I highly suspect that your problem was fixed by r194815.

Will this fix work on a release, or would it be best to upgrade to the 
stable branch.