_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/