Hi!
Last few days I have this problem with my system. Is there any ideas about it?
Can it be a hardware problem?
I have serial console configured on this host, but same happen with
general (keyboard/screen) console only.
Details:
-----------------------------------------------------------------------------------------
Version:
FreeBSD 5.3-STABLE #5: Thu Dec 30 17:43:07 EST 2004
------------------
cvsup'ed:
Dec 20, 2004
------------------
Console message (mostly the same every time): ///////////////////////////////
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc5cebc64
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc04a383f
stack pointer = 0x10:0xc581cc24
frame pointer = 0x10:0xc581cc44
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, def32, gran 1
processor eflags = resume, IOPL = 0
current process = 26 (swi5: clock sio)
trap number = 12
panic: page fault
------------------
Last screen before hung of "top" output (from remote console):
//////////////
last pid: 505; load averages: 1.85, 1.16, 0.54 up 0+00:05:47 15:06:45
24 processes: 3 running, 21 sleeping
CPU states: 0.8% user, 57.7% nice, 40.0% system, 1.5% interrupt, 0.0% idle
Mem: 34M Active, 19M Wired, 1796K Cache, 14M Buf, 2460K Free
Swap: 256M Total, 10M Used, 246M Free, 4% Inuse, 20K In
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
503 www 132 4 25164K 22300K RUN 0:04 28.68% 13.72% httpd
504 www 132 4 15672K 12860K RUN 0:02 29.99% 6.64% httpd
452 mysql 20 4 29620K 752K kserel 0:03 0.00% 0.00% mysqld
460 root 96 0 2388K 564K RUN 0:02 0.00% 0.00% top
397 root 111 4 5072K 704K select 0:00 0.00% 0.00% httpd
456 root 100 4 6436K 448K select 0:00 0.00% 0.00% sshd
458 root 20 0 2608K 12K pause 0:00 0.00% 0.00% csh
472 root 5 0 2612K 12K ttyin 0:00 0.00% 0.00% csh
470 root 100 4 6436K 12K select 0:00 0.00% 0.00% sshd
253 root 100 4 1412K 252K select 0:00 0.00% 0.00% syslogd
365 root 100 4 3732K 400K select 0:00 0.00% 0.00% sendmail
343 root 100 4 3176K 384K select 0:00 0.00% 0.00% ntpd
400 root 8 4 1768K 12K wait 0:00 0.00% 0.00% sh
383 root 8 4 1448K 56K nanslp 0:00 0.00% 0.00% cron
447 root 5 0 1372K 12K ttyin 0:00 0.00% 0.00% getty
359 root 100 4 3676K 12K select 0:00 0.00% 0.00% sshd
448 root 5 0 1368K 12K siodcd 0:00 0.00% 0.00% getty
371 smmsp 20 4 3632K 12K pause 0:00 0.00% 0.00% sendmail
505 www 4 4 5072K 1352K accept 0:00 0.00% 0.00% httpd
233 root 113 4 548K 12K select 0:00 0.00% 0.00% devd
------------------
Syslog messages:
............
Jan 26 13:55:53 delta kernel: pid 673 (httpd), uid 80: exited on signal 4
Jan 26 13:55:53 delta kernel: Jan 26 13:55:53 delta kernel: pid 673 (httpd), uid
80: exited on signal 4
Jan 26 13:55:57 delta kernel: pid 674 (httpd), uid 80: exited on signal 4
Jan 26 13:55:57 delta kernel: Jan 26 13:55:57 delta kernel: pid 674 (httpd), uid
80: exited on signal 4
Jan 26 13:56:05 delta kernel: pid 676 (httpd), uid 80: exited on signal 4
............
-----------------------------------------------------------------------------------------
There are problems with httpd (php scripts), but this kind of problems should
not kill the server.
Thank you.
Vlad.
At 05:03 PM 26/01/2005, Vlad wrote:>------------------ > >Syslog messages: >............ >Jan 26 13:55:53 delta kernel: pid 673 (httpd), uid 80: exited on signal 4 >Jan 26 13:55:53 delta kernel: Jan 26 13:55:53 delta kernel: pid 673 >(httpd), uid 80: exited on signal 4 >Jan 26 13:55:57 delta kernel: pid 674 (httpd), uid 80: exited on signal 4 >Jan 26 13:55:57 delta kernel: Jan 26 13:55:57 delta kernel: pid 674 >(httpd), uid 80: exited on signal 4 >Jan 26 13:56:05 delta kernel: pid 676 (httpd), uid 80: exited on signal 4 >............Did you compile your system with any particular CPU flags ? The signal 4 indicates an illegal instruction. e.g. if you compiled for i686, but are running on an older C3 that does not support all of the i686 instruction set. ---Mike
There are only two flags (make.conf): CPUTYPE=p3 CFLAGS= -O -pipe and as I found (on this host) process gets signal 4 after reach limits from /etc/login.conf usualy before system dies I see about hundred thiS kind of messages in logs. Vlad.> From mike@sentex.net Wed Jan 26 17:08:33 2005 > Date: Wed, 26 Jan 2005 17:09:18 -0500 > To: Vlad <m@alpha.VL7.net>, stable@freebsd.org > From: Mike Tancsa <mike@sentex.net> > Subject: Re: system panic > > At 05:03 PM 26/01/2005, Vlad wrote: > >------------------ > > > >Syslog messages: > >............ > >Jan 26 13:55:53 delta kernel: pid 673 (httpd), uid 80: exited on signal 4 > >Jan 26 13:55:53 delta kernel: Jan 26 13:55:53 delta kernel: pid 673 > >(httpd), uid 80: exited on signal 4 > >Jan 26 13:55:57 delta kernel: pid 674 (httpd), uid 80: exited on signal 4 > >Jan 26 13:55:57 delta kernel: Jan 26 13:55:57 delta kernel: pid 674 > >(httpd), uid 80: exited on signal 4 > >Jan 26 13:56:05 delta kernel: pid 676 (httpd), uid 80: exited on signal 4 > >............ > > > Did you compile your system with any particular CPU flags ? The signal 4 > indicates an illegal instruction. e.g. if you compiled for i686, but are > running on an older C3 that does not support all of the i686 instruction set. > > ---Mike > >
On Wed, 26 Jan 2005, Vlad wrote:> Console message (mostly the same every time): /////////////////////////////// > > kernel trap 12 with interrupts disabled > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xc5cebc64 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc04a383f > stack pointer = 0x10:0xc581cc24 > frame pointer = 0x10:0xc581cc44 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32, gran 1 > processor eflags = resume, IOPL = 0 > current process = 26 (swi5: clock sio) > trap number = 12 > panic: page faultLooks like one of the timer callouts may be dereferencing an invalid pointer. The question really is which. If you have a version of the kernel compiled with debugging symbols, could you use gdb to convert the instruction pointer above to a file, line number, and function? It would also be useful if you could use DDB to generate a stack trace. There are detailed instructions on setting up for post-mortem debugging in the handbook, if you're not familiar with that. Robert N M Watson