lkml.org 
[lkml]   [2006]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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.

    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-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-11-18 23:46    [W:0.022 / U:0.228 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site