lkml.org 
[lkml]   [2014]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Random panic in load_balance() with 3.16-rc
    On Tue, Jul 22, 2014 at 09:21:40PM -0700, Linus Torvalds wrote:
    > On Tue, Jul 22, 2014 at 8:53 PM, Michel Dänzer <michel@daenzer.net> wrote:
    > >
    > > Just happened again with the same change on top of 3.16-rc6.
    >
    > The (maybe) related bugzilla entry is just odd. Bruno Wolff reports
    > that the BUG_ON() in his added patch triggers:
    >
    > + cpumask_clear(sched_group_cpus(sg));
    > + sg->sgc->capacity = 0;
    > + BUG_ON(!cpumask_empty(sched_group_cpus(sg)));
    >
    > where it *just* did a cpumask_clear(), and now the BUG_ON() triggers
    > that it's no longer empty?
    >
    > That would imply an allocation error, but all the sched groups seem to
    > be properly allocated with the proper addition of cpumask_size().
    >
    > And his config file even has NR_CPUS being 32, so it should be a
    > single word of bitmap, which triggers all the simple code.
    >
    > Completely insane, in other words.

    So we've had this other thread where the same happened:

    lkml.kernel.org/r/20140716145546.GA6922@wolff.to

    (pointed Michel to that earlier)

    And that seems to be sorted now (just found positive feedback in my
    Inbox this morning), it was a question of the arch code supplying
    completely 'broken' topology information, and the scheduler trusting it
    too much.

    The real fix in that thread is:

    lkml.kernel.org/r/20140722133514.GM12054@laptop.lan

    And I'll also add this to make the scheduler less trusting:

    lkml.kernel.org/r/20140722094740.GJ12054@laptop.lan

    Michael, that's not going to tell us what's wrong with your machine, as
    you've not got the ancient dual P4 Xeon Bruno's got. Seeing how your
    cpuinfo says:

    model name : AMD A10-7850K Radeon R7, 12 Compute Cores 4C+8G

    but we can start the same debugging session I suppose.

    Could you run with this patch on top:

    lkml.kernel.org/r/20140718101633.GP9918@twins.programming.kicks-ass.net

    And provide us with the dmesg after boot?
    --
    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: 2014-07-23 09:23    [W:3.886 / U:0.320 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site