Re: Kernel Panics
Re: Kernel Panics
- Subject: Re: Kernel Panics
- From: Terry Lambert <email@hidden>
- Date: Mon, 6 Aug 2007 13:39:22 -0700
On Aug 5, 2007, at 11:40 AM, Frederick Pearce wrote:
I'm hoping that someone can shed some light on the almost daily
panics I've been getting on my X-Serve Dual G4.
Here's what the panic log indicates:
Sun Aug 5 07:56:34 2007
panic(cpu 1 caller 0x0003FFE8): zalloc: "kalloc.64" (3860160
elements) retry fail 3
Latest stack backtrace for cpu 1:
Backtrace:
0x000952D8 0x000957F0 0x00026898 0x0003FFE8 0x0002BC34
0x0007C284 0x0007C4AC 0x0028B114
0x002A5B18 0x00089D0C 0x00061340 0x00063258 0x000A84F0
0x000AB980
Proceeding back via exception chain:
Exception state (sv=0x2D3F4000)
PC=0x0005B134; MSR=0x4000D030; DAR=0xED2B7000;
DSISR=0x40000000; LR=0x0004F5FC; R1=0xBFFFECF0; XCP=0x00000010
(0x400 - Inst access)
Kernel version:
Darwin Kernel Version 8.10.0: Wed May 23 16:50:59 PDT 2007;
root:xnu-792.21.3~1/RELEASE_PPC
You should report this via bugreporter, ather than to this list.
However...
-
There are no kernel extension address spaces listed in the backtrace,
so this is not a crash in a kernel extension.
However, this specific error generally indicates a problem in a kernel
extension; it's saying that the 64 byte zone has been exhausted by
someone, and the most likely cause is some kernel extension doing 64
byte allocations and never freeing the memory back to the system for
reuse.
Looking at the specific addresses involved, this is an attempt to
create a upl in the page in path for a cluster read as a result of a
page fault.
You will need to take a core of this and file a bug report, or you
will need to engage in two machine debugging.
Again, the most probable cause of this is a third party kext that is
leaking memory.
The second most probably cause of this is running a heavy load on an
unsupported memory configuration; this could either be a machine with
less than the supported amount of RAM for the version of the OS you
are running, or this could be a desktop system that has been manually
tuned toward a server configuration by removal of administrative
limits via sysctl. Note that the primary reasons for the default
desktop limitations are that desktop systems typically ship configured
with far fewer resources than XServe systems.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Kernel Panics (From: Frederick Pearce <email@hidden>) |