On Mon, 30 Oct 2006, Jun'ichi Nomura wrote: > > Please revert the patch. I'll fix the wrong error handling. > > I'm not sure reverting the patch solves the ACPI problem > because Michael's kernel seems not having any user of > bd_claim_by_kobject. Yeah, doing a grep does seem to imply that there is no way that those changes could matter. Michael, can you double-check? I think Jun'ichi is right - in your kernel, according to the config posted on bugzilla, I don't think there should be a single caller of bd_claim_by_disk, since CONFIG_MD is disabled. So it does seem strange. But if you bisected to that patch, and it reliably does _not_ have problems with the patch reverted, maybe there is some strange preprocessor thing that makes "grep" not find the caller. Michael, you also reported: > Reset to d7dd8fd9557840162b724a8ac1366dd78a12dff seems to hide part of > the issue (I have ACPI after kernel build, but not after > suspend/resume). Both reverting this patch, and reset to the parent of > this patch seem to solve (or at least, hide) both problems for me (no > ACPI after suspend/resume and no ACPI after kernel build). (where that "d7dd8f.." is actually missing the initial "4" - I think you cut-and-pasted things incorrectly). So I wonder.. You still had ACPI working _after_ the kernel build even with that patch in place, and it seems that suspend/resume is the real issue. Martin Lorenz reports on the same bugzilla entry, and he only has problems with suspend/resume. I assume that "compile the kernel" just triggers some magic ACPI event (probably fan-related due to heat), and I wonder if the bisection faked you out because once you get "close enough" the differences are small enough that the kernel compile is quick and the heat event doesn't actually trigger? See what I'm saying? Maybe the act of bisecting itself changed the results, and then when you just revert the patch, you end up in the same situation: you only recompile a small part (you only recompile that particular file), and the problem doesn't occur, so you'd think that the revert "fixed" it. If it's heat-related, it should probably trigger by anything that does a lot of CPU (and perhaps disk) accesses, not just kernel builds. It might be good to try to find another test-case for it than a kernel recompile, one that doesn't depend on how much changed in the kernel.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
