On 5/16/06, fbsd <[EMAIL PROTECTED]> wrote:
Hello All,
I'm running a home email server and twice in the last week it has
rebooted itself and been unable to restart due to corruption of the
filesystem. I found the following in /var/log/messages
May 16 17:46:07 hpvectra syslogd: kernel boot file is /boot/kernel/kernel
May 16 17:46:07 hpvectra kernel:
May 16 17:46:07 hpvectra kernel:
May 16 17:46:07 hpvectra kernel: Fatal trap 12: page fault while in
kernel mode
May 16 17:46:07 hpvectra kernel: fault virtual address = 0x1c
May 16 17:46:07 hpvectra kernel: fault code = supervisor write,
page not present
May 16 17:46:07 hpvectra kernel: instruction pointer = 0x20:0xc062c5e8
May 16 17:46:07 hpvectra kernel: stack pointer = 0x28:0xe5079c50
May 16 17:46:07 hpvectra kernel: frame pointer = 0x28:0xe5079c64
May 16 17:46:07 hpvectra kernel: code segment = base 0x0, limit
0xfffff, type 0x1b
May 16 17:46:07 hpvectra kernel: = DPL 0, pres 1, def32 1, gran 1
May 16 17:46:07 hpvectra kernel: processor eflags = interrupt
enabled, resume, IOPL = 0
May 16 17:46:07 hpvectra kernel: current process = 52 (vnlru)
May 16 17:46:07 hpvectra kernel: trap number = 12
May 16 17:46:07 hpvectra kernel: panic: page fault
May 16 17:46:07 hpvectra kernel: Uptime: 5d7h4m50s
May 16 17:46:07 hpvectra kernel: Dumping 1023 MB (2 chunks)
May 16 17:46:07 hpvectra kernel: chunk 0: 1MB (159 pages) ... ok
May 16 17:46:07 hpvectra kernel: chunk 1: 1023MB (261872 pages) 1007 991
975 959 943 927 911 895 879 863 847 831 815 799 783 767 751 735 719 703
687 671 655 639 623 607 591 575 559 543 527 511 495 479 463 447 431 415
399 383 367 351 335 319 303 287 271 255 239 223 207 191 175 159 143 127
111 95 79 63 47 31 15 ... ok
May 16 17:46:07 hpvectra kernel:
May 16 17:46:07 hpvectra kernel: Dump complete
May 16 17:46:07 hpvectra kernel: Automatic reboot in 15 seconds - press
a key on the console to abort
May 16 17:46:07 hpvectra kernel: Rebooting...
The only thing I can see (read: understand) is:
the process that caused the kernel panic is "vnlru":
"vnlru flushes and frees vnodes when the system hits the
kern.maxvnodes limit. This kernel thread sits mostly idle, and only
activates if you have a huge amount of RAM and are accessing tens of
thousands of tiny files."
(from http://www.unixguide.net/freebsd/faq/10.31.shtml)
So, consider increasing kern.maxvnodes if your system deals with such
a huge amount of files.
Thanks in advance,
Hope this helps,
Ron
--
Pietro Cerutti
icq #117293691
- ASCII Ribbon Campaign -
against HTML e-mail and
proprietary attachments
www.asciiribbon.org
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
