site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi All, - Since this is a G4, I'll bet you are exhausting physical memory. 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On Sep 20, 2007, at 12:13 PM, JanakiRam wrote: 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. 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 ? This email sent to site_archiver@lists.apple.com