[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130912203358.GE32644@gmail.com>
Date: Thu, 12 Sep 2013 22:33:58 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...radead.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] perf fixes
* Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Thu, Sep 12, 2013 at 11:10 AM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > But at least the "make install" problem is repeatable, though.
>
> And now this new problem is repeatable too:
>
> # On a fully built kernel tree
> perf record -g -e cycles:pp make -j
>
> results in
>
> [ perf record: Woken up 27 times to write data ]
> [ perf record: Captured and wrote 7.980 MB perf.data (~348659 samples) ]
> 0x1b4e0 [0]: failed to process type: -1970637019
>
> where that number changes randomly, ie I get
>
> 0x28dc58 [0]: failed to process type: 99257493
> 0x4100 [0]: failed to process type: -1144359783
> 0x29050 [0]: failed to process type: -972156963
> ..
>
> looks like perhaps some uninitialized variable somewhere?
>
> Recording performance profiles of other (simpler?) loads still seems to
> work. So it's something about that "make -j" that makes it crap out
> (note that the tree is fully built, so not a lot actually gets *done*,
> and the thing only takes a few seconds)
Hm, just to make sure, are you running a (very fresh) kernel that has this
fix included:
d008d5258e9c perf: Fix up MMAP2 buffer space reservation
?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists