We've seen cases in the past where something benign like this
triggers a bug because it moves the data/bss/etc. sections
around.
For example, if the used parts of the kernel image end up extending
into another page, this can influence the bootup memory detection
logic.
The softlockup in your first trace shows it spinning in the journaling
code. Perhaps what is happening is that it is looping endlessly over
some data structure which is in a corrupted state. This could happen
if the bootup code erroneously frees up pages it should not have.
I would recommend figuring out exactly what the journaling code is
stuck on, then try to trace the life of that page of memory from
early bootup until it is allocated.
I hope this can help you figure out this bug as I can't reproduce it
here at all, and I did merge the hugetlb fix into Linus's tree
already (and that is the right thing to do as we certainly have some
unrelated bug here).
On the flip side, I bet removing some kernel config option might make
the heisenbug go away if you're just eager to test the hugetlb patch
:-)
-
