lkml.org 
[lkml]   [2012]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [BUG] kernel freezes with latest tree
    On Tue, Jan 10, 2012 at 2:23 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
    >
    > Maybe a recent change in NMI handling, or perf events ?

    Unlikely. And it shouldn't show up in the merge commit anyway, those
    things should be pretty independent.

    > No idea why the bisection (I redid it carefully : same result) points to the above commit.

    Ok, so the bisect is almost certainly correct. But just to be anal and
    really careful, can you independently check both parents of the merge,
    and then re-check the merge itself, and verify that the two parent
    commits never hang, and that the merged state hangs.

    Just to take any bisection issues out of the picture, and just verify
    those three commits by hand.

    But in the meantime, we should assume that it's the merge that is the problem.

    I added Frederic to the cc, because he did the
    tick_nohz_idle_enter_norcu(), so maybe he can tell if there is
    something in that merge that looks suspicious (Frederic - see the
    history of the thread on lkml. I thought maybe it was the lack of
    irq-disable around set_cpu_sd_state_idle(), but Eric already tested
    that). And Suresh because he worked on the whole nohz/nr_busy_cpus.
    Maybe you guys see some obvious semantic clash..

    Anybody? Any ideas? Clearly there can be a merge problem that doesn't
    actually show as a real data conflict, just some semantic conflict,
    but I don't see what such issues would be brouht in by the scheduler
    merge anyway.

    Linus


    \
     
     \ /
      Last update: 2012-01-11 00:47    [W:0.021 / U:1.884 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site