Michael Grant wrote:
On Tue, Jul 15, 2008 at 10:44 PM, Kris Kennaway <[EMAIL PROTECTED]> wrote:
Michael Grant wrote:
I have been having panics on one of my machines, roughly every week or
so.  I was running 6.3 pre-release and then I updated to 6.3 p2 and I
still have the panic, here's the message that appears on the console:

panic: kmem_kernel trap 12 with interrupts disabled

Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 06
fault virtual address   = 0x2c
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc06c5a5a
stack pointer           = 0x28:0xe6ea49ec
frame pointer           = 0x28:0xe6ea4a00
code segment            = base 0x0, limit 0xfffff, type 0x1b
                       = DPL 0, pres 1, def32 1, gran 1
processor eflags        = resume, IOPL = 0
current process         = 14 (swi1: net)
trap number             = 12

Is this possibly a hardware problem?
Yes, but who can say? :)  To complete your bug report please submit a
backtrace.  See the developers handbook for details.


Another crash:

panic: kmem_malloc(16384): kmem_map too small: 335527936 total allocated
cpuid = 0
Uptime: 3d22h55m59s
Dumping 3327 MB (2 chunks)
  chunk 0: 1MB (151 pages) ... ok
  chunk 1: 3327MB (851568 pages) 3311 <--- hangs here

I waited about a half hour before pulling the plug.

Then, during reboot:
savecore: error reading last dump header at offset 10005032448 in
/dev/ad1s1b: Input/output error
savecore: no dumps found
Jul 19 15:50:19 charm savecore: error reading last dump header at
offset 10005032448 in /dev/ad1s1b: Input/output error

I will wait and see if the next time it crashes I get a better dump,
but in the mean time, still no ideas?

You still didn't get the backtrace I requested (if dump is failing for you then try minidumps or compile in DDB and use that -- again, please read the developers handbook), but this particular panic has an obvious explanation: your kernel ran out of memory. Set the vm.kmem_size tunable to some larger value than 320M, or modify your workload to use less kernel memory.

freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to