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.250 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site