# Help with Kernel crashes



## beddo (Jun 3, 2009)

Hi folks,
My server (FreeBSD 7.0-RELEASE-p12) has been rebooting itself every few days for a while so I got round to building a debug kernel (cvsup done on source just prior to building) and just caught a dump on the latest one.

This seems to happen at all sorts of times of the day and I do from time to time see the following in /var/messages but it doesn't tend to correlated with crashes.


```
+mpt0: mpt_cam_event: 0x21
```

I'm told these are status update events from the array controller but FreeBSD doesn't have software capable of interpreting them. The event codes are normally 12 and 16, its only the last couple of months that I've seen 21 crop up (3 times in total)

Here's about all I know what to do with the debug, can anyone point me in the right direction?


```
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address   = 0x0
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc050f308
stack pointer           = 0x28:0xe8df7b34
frame pointer           = 0x28:0xe8df7b58
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         = 70914 (perl5.10.0)
trap number             = 12
panic: page fault
cpuid = 1
Uptime: 3d5h14m19s
Physical memory: 3318 MB
Dumping 288 MB: 273 257 241 225 209 193 177 161 145 129 113 97 81 65 49 33 17 1

#0  doadump () at pcpu.h:195
195             __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc050f308
0xc050f308 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));
(kgdb) backtrace
#0  doadump () at pcpu.h:195
#1  0xc05667b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2  0xc0566a79 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:563
#3  0xc06fa2bc in trap_fatal (frame=0xe8df7af4, eva=0)
    at /usr/src/sys/i386/i386/trap.c:899
#4  0xc06fa520 in trap_pfault (frame=0xe8df7af4, usermode=0, eva=0)
    at /usr/src/sys/i386/i386/trap.c:812
#5  0xc06faea2 in trap (frame=0xe8df7af4) at /usr/src/sys/i386/i386/trap.c:490
#6  0xc06e182b in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc050f308 in pfs_ioctl (va=0xe8df7b88)
    at /usr/src/sys/fs/pseudofs/pseudofs_vnops.c:247
#8  0xc070ec52 in VOP_IOCTL_APV (vop=0xc0767680, a=0xe8df7b88)
    at vnode_if.c:795
#9  0xc05ed16d in vn_ioctl (fp=0xc6720000, com=1076655123, data=0xc6ab6880,
    active_cred=0xc88b7200, td=0xc6d09630) at vnode_if.h:437
#10 0xc05996a5 in kern_ioctl (td=0xc6d09630, fd=3, com=1076655123,
    data=0xc6ab6880 "") at file.h:266
#11 0xc0599804 in ioctl (td=0xc6d09630, uap=0xe8df7cfc)
    at /usr/src/sys/kern/sys_generic.c:570
#12 0xc06fa875 in syscall (frame=0xe8df7d38)
    at /usr/src/sys/i386/i386/trap.c:1035
#13 0xc06e1890 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:196
#14 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
```


----------



## SirDice (Jun 3, 2009)

Page faults are a pain... Are you sure your memory is still OK?


----------



## roddierod (Jun 3, 2009)

I had an onboard LSI SCSI that was an mpt device and when it started to go bad, my machine would reboot at random times.

You may want to check that also.


----------



## beddo (Jun 4, 2009)

Thanks for the replies, the server is only about 6 months old. I know that doesn't exclude hardware problems but its not an antique..I'll have to ask the hosts who are responsible.

I take it there's not much in the dump that could help?


----------



## beddo (Jun 4, 2009)

I'm starting to suspect there is something up with cpanel seen as that is the main perl thing running on the server and in both instances it has been a perl process causing exactly the same error (it happened again overnight).

Off to the cpanel forums..


----------

