Messages in this thread | | | Subject | Re: [BUG] kernel freezes with latest tree | From | Eric Dumazet <> | Date | Wed, 11 Jan 2012 09:22:07 +0100 |
| |
Le mardi 10 janvier 2012 à 15:44 -0800, Linus Torvalds a écrit : > 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. >
Thanks Linus for all the input.
I'll redo extensive bisection today, waiting at least 30 minutes before telling a point is good (or not).
Maybe bug can sometime hide a long time before triggering.
[ I'll first make sure 3.2 is rock solid ]
-- 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/
| |