Messages in this thread | | | Date | Fri, 24 Sep 1999 16:36:24 -0500 | From | Brandon L Black <> | Subject | 2.2.12 myterious crashes |
| |
(Sorry if I'm not threading in correctly, I'm reading on the web and composing new to post replies)...
_my_ 2.2.12 problems:
I wrote earlier about having OOM on bootup problems, and then also (when it didn't OOM on decompress) the kernel hanging at random times, easily triggered with a few attempts to fsck a large filesystem.....
Recommendations included the HEAP_SIZE and gzip -3 methods of preventing OOM on decompress, and using ikd to trace the other issue (I figured the EIP on video ram thing would have been perfect for tracking this down).
Well... I'm still in limbo on this problem. Once I've fixed HEAP_SIZE and/or switched to gzip -3, in order to not run out of heap space during the decompress... I can't reproduce the later kernel hang.... so that leads me to the following question:
Is there any way that HEAP_SIZE in arch/i386/boot/compressed/misc.c and/or using gzip -3 to reduce HEAP_SIZE requirements could possibly affect the kernel once it is loaded? I'm thinking no off the top of my head... that once the kernel gets decompessed and jumped into, the initial startup stuff probably doesn't matter at all... but my (very flakey) debugging results seem to indicate that I only get crashes in the running kernel when I have the HEAP_SIZE at the smaller (original) value..... I suppose my next step to confirm this is going to be to undo the HEAP_SIZE changes, and build my kernels which were randomly OOM kernels until I get one that doesn't OOM but does cause the bug, which has IKD's EIP trace built into it :) This could be a long trial and error process...... Any thoughts, especially on whether or not it is remotely possible for the HEAP_SIZE thing to affect the kernel proper later in life?
Brandon
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |