Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 19 Jul 2008 22:12:35 +0200
From:      Kris Kennaway <kris@FreeBSD.org>
To:        Michael Grant <mgrant@grant.org>
Cc:        FreeBSD Questions <freebsd-questions@freebsd.org>
Subject:   Re: panic
Message-ID:  <48824AB3.7050402@FreeBSD.org>
In-Reply-To: <62b856460807191254j35bc302fncaecc2171c55f609@mail.gmail.com>
References:  <62b856460807151331h42ad6c4ahc548b08c90ee2934@mail.gmail.com>	<487D0C4B.60402@FreeBSD.org> <62b856460807191254j35bc302fncaecc2171c55f609@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Michael Grant wrote:
> On Tue, Jul 15, 2008 at 10:44 PM, Kris Kennaway <kris@freebsd.org> 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.
>>
>> Kris
>>
>>
> 
> 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.

Kris



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48824AB3.7050402>