Quoting r. Linus Torvalds <torvalds@xxxxxxxx>: > Subject: Re: 2.6.19-rc3: known unfixed regressions (v3) > > > > 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. I will, just maybe not today. > 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). Yes. > 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 > > Linus, I agree something fishy is going on, I'm just not sure how to debug. It kind of looks like some memory corruption, or something. I plan double-checking sometime later. 2 points I'd like to clarify: 1. When I git-bisected, I tested ACPI after suspend/resume, this is much faster to test but might be a separate issue. I really tested several times, and unless I repeated same mistake several times just switching between commit above and its parent made ACPI after resume work/not work. 2. When I test kernel compile, I do git clone -s ~/scm/linux-2.6 cd linux-2.6 make defconfig make -j 4 so the build I do in testing is repeatable. -- MST - 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
