lkml.org 
[lkml]   [2012]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BUG] kernel freezes with latest tree
On Tue, Jan 10, 2012 at 03:44:38PM -0800, Linus Torvalds wrote:
> 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..

As the thread evolved I guess we found the issue or at least we
got more clues.

But just in case, I double checked the merge but nothing looked
suspicious to me.

Thanks.

>
> 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 15:23    [from the cache]
©2003-2011 Jasper Spaans