Re: Problems with Kernel Extension on Different Mac Configurations
Re: Problems with Kernel Extension on Different Mac Configurations
- Subject: Re: Problems with Kernel Extension on Different Mac Configurations
- From: Terry Lambert <email@hidden>
- Date: Thu, 20 Sep 2007 13:37:55 -0700
On Sep 20, 2007, at 12:13 PM, JanakiRam wrote:
Hi All,
I'm doing maintenance for an application which uses Kernel
Extension as well. I'm observing unpredictable behavior with my
application on different Configurations of Macs. Here are some of
the behaviors.
i) Once my application is started ( kext as well ) , the system
hangs on PowerBook G4 , But on iMac G5 its works without any problem.
It's possible that you didn't turn off autovectorization in the
compiler. This is a kernel extension: avoid using vector processing
or floating point if you can.
ii) _MALLOC calls are getting failed some time after my
application is started. I tried with OSMalloc as well , its also
failing. In which cases _MALLOC Fails ? .
It will fail if you are asking for more memory than is contiguously
available in the kernel virtual address space.
It will fail if you ask for more memory than is physically present in
the machine (all kernel allocations, with one or two irrelevant to you
exceptions, occur in wired, not pageable memory, and MUST have
physical RAM backing them).
It will fail if the allocation is large enough, and the kernel virtual
address space is fragmented, and there are no holes the size of your
allocation or larger in which to stick the amount of memory you are
requesting.
It will fail if your page mappings are exhausted (this usually ends up
as an explicit call to panic in zalloc_canblock(), when the zone-of-
zones is exhausted).
It will fail if the allocation is 8K or less, and you have exhausted
the kalloc.<size> zone limit; for example, if you are trying to do 16
8K allocation, you should probably be using kmem_alloc or something
else that doesn't go through zalloc, and therefore doesn't have the
zone limitations.
It will fail if you are leaking memory; remember that unloading a
KEXT, unlike killing a running program, does not automatically release
the memory back to the system: kernel resources are generally not
resource-tracked by KEXT: if you allocated the memory, it's your job
to free it before you allow yourself to be unloaded.
-
Since this is a G4, I'll bet you are exhausting physical memory.
What is the maximum memory that can be allocated for a Kext ?
Never ask this question; it indicates that you aren't buying into the
kernel philosophy, which is: "use as little memory in the kernel as
you can possibly use, while still being able to get your job done".
Any time you ask "what's the max I can allocate?", you're operating
from a user-space mentality, which means you believe "memory is
free". In user space, it's not quite free, but if you need a lot, you
will be paged out. Needing a lot of memory in user space means
degraded performance, rather than not being able to run at all.
Probably a lot of what you are trying to do here belongs in user
space, if you need a lot of memory to do it. Unlike processes, which
each get their own address space, in kernel space, you are sharing
your address space with the kernel and all the other KEXT writers in
the world.
If you have ever programmed in a very old Mac environment, or on a
Commodore 64 or a Palm Pilot or an MS-DOS machine, where there is no
such thing as memory protection: that's what programming in a kernel
is like.
Are there any debugging tools available to inspect the above
mentioned scenario ?
Two machine debugging + kgmacros:
| zprint Display info about the memory zones
| showioalloc Display info about iokit allocations
...you may want to try "help kgm" from gdb.
-- 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