From: "Nish Aravamudan" <nish.aravamudan@xxxxxxxxx> Date: Tue, 13 Mar 2007 17:29:17 -0700 > Ok, truly bizarre, I found that I was not running stock 2.6.20.3, but > had your small hugetlb patch on top. > > So I went back and patched 2.6.20.1 with your patch, rebooted, got a > soft lockup. Went back to stock 2.6.20.1 and did not. > > I don't see how your patch (C&P below for reference) could make any > difference...Especially because no hugepages were in use at the time. > On patched 2.6.20.1, I was just trying to check if my source tree had > your patch applied (by `patch -p1 < davem.patch`) and got the > soft-lockup I saw in 2.6.20.3 with the patch applied. I am going to > try a clean 2.6.20.3 as well, now. 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 :-) - To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
