# FreeBSD 7.2 crashes over and over



## asg (Jan 18, 2010)

Hi, 

got a little problem with one server (which I do not have a console for). 

I run a couple of jails on that system (4 of them) with postgresql, apache, postfix,... 

The system is now crashing a couple of times: 


```
Mon Jan 18 18:20:43 CET 2010

FreeBSD encephalon.de 7.2-RELEASE-p5 FreeBSD 7.2-RELEASE-p5 #0: Mon Dec 21 13:28:03 CET 2009     asg@encephalon.de:/usr/obj/usr/src/sy
s/GRUNIX  amd64

panic: page fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code              = supervisor read data, page not present
instruction pointer     = 0x8:0xffffffff807a6811
stack pointer           = 0x10:0xfffffffebebd7690
frame pointer           = 0x10:0xffffff0042b18b38
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 2453 (postgres)
trap number             = 12
panic: page fault
cpuid = 0
Uptime: 19h2m20s
Physical memory: 2003 MB

Dumping 308 MB: 293 277
<6>TCP: [85.10.218.105]:54227 to [85.10.218.105]:5432 tcpflags 0x2<SYN>; tcp_input: Connection attempt to closed port
 261 245 229 213 197 181
<6>TCP: [85.10.218.105]:62736 to [85.10.218.105]:5432 tcpflags 0x2<SYN>; tcp_input: Connection attempt to closed port
 165
<6>TCP: [85.10.218.105]:50885 to [85.10.218.105]:5432 tcpflags 0x2<SYN>; tcp_input: Connection attempt to closed port
 149 133 117 101 85
<6>TCP: [85.10.218.105]:56923 to [85.10.218.105]:5432 tcpflags 0x2<SYN>; tcp_input: Connection attempt to closed port
 69 53 37 21 5

Reading symbols from /boot/kernel/if_tap.ko...Reading symbols from /boot/kernel/if_tap.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_tap.ko
Reading symbols from /boot/kernel/ng_bridge.ko...Reading symbols from /boot/kernel/ng_bridge.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_bridge.ko
Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/netgraph.ko
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/if_bridge.ko...Reading symbols from /boot/kernel/if_bridge.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_bridge.ko
Reading symbols from /boot/kernel/bridgestp.ko...Reading symbols from /boot/kernel/bridgestp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/bridgestp.ko
#0  doadump () at pcpu.h:195
195     pcpu.h: No such file or directory.
        in pcpu.h
[...]
```

Its very odd, because sometimes he systems runs a couple of weeks, sometime just a few others. After all, the system crashs und reboots.


----------



## SirDice (Jan 18, 2010)

Check for hardware errors, mainly memory and bad sectors on disk.

If you've used any CFLAGS in /etc/make.conf remove them and recompile.


----------



## kolbycrouch (Jan 18, 2010)

I have had the same problem.
I can confirm that (in my case) it's not hardware failure.
it happened with old mobo.
new mobo, it happens in amd64 freebsd. not yet in i386
similar problem happens in netbsd-current, netbsd-stable, and opensolaris.

I have absolutely no idea why this happens, but it will continue to happen, and probably more frequently.


----------



## DutchDaemon (Jan 18, 2010)

> ```
> current process         = 2453 (postgres)
> ```



Is the crash happening with random processes, or always with postgres?


----------



## asg (Jan 19, 2010)

Hi, 

@DutchDaemon
About 90% of the crashes its "postgres" which was the current process. But not all the time. I also did an upgrade of postgres, nothing changed. 

This morning another crash and reboot:

```
Tue Jan 19 04:30:58 CET 2010

FreeBSD encephalon.de 7.2-RELEASE-p5  amd64

panic: page fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:


Reading symbols from /boot/kernel/if_tap.ko...Reading symbols from /boot/kernel/if_tap.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_tap.ko
Reading symbols from /boot/kernel/ng_bridge.ko...Reading symbols from /boot/kernel/ng_bridge.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_bridge.ko
Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from /boot/kernel/netgraph.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/netgraph.ko
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/if_bridge.ko...Reading symbols from /boot/kernel/if_bridge.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_bridge.ko
Reading symbols from /boot/kernel/bridgestp.ko...Reading symbols from /boot/kernel/bridgestp.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/bridgestp.ko
#0  doadump () at pcpu.h:195
195     pcpu.h: No such file or directory.
        in pcpu.h
[...]
```

Finally I have disabled bgfsck and enabled fsck=y in rc.conf. If not, The system wont come up again.
I also deleted my gmirror, but the system crashes also...


----------



## asg (Feb 2, 2010)

Ok, last but not least, seemed to be a hardware defect of the NIC and CPU.


----------

