[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121002150307.GA1161@avionic-0098.mockup.avionic-design.de>
Date: Tue, 2 Oct 2012 17:03:07 +0200
From: Thierry Reding <thierry.reding@...onic-design.de>
To: Mel Gorman <mgorman@...e.de>
Cc: Peter Ujfalusi <peter.ujfalusi@...com>,
Minchan Kim <minchan@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
Michal Nazarewicz <mina86@...a86.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
Kyungmin Park <kyungmin.park@...sung.com>,
Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: CMA broken in next-20120926
On Tue, Oct 02, 2012 at 03:41:35PM +0100, Mel Gorman wrote:
> On Tue, Oct 02, 2012 at 02:48:14PM +0200, Thierry Reding wrote:
> > > So this really isn't all that new, but I just wanted to confirm my
> > > results from last week. We'll see if bisection shows up something
> > > interesting.
> >
> > I just finished bisecting this and git reports:
> >
> > 3750280f8bd0ed01753a72542756a8c82ab27933 is the first bad commit
> >
> > I'm attaching the complete bisection log and a diff of all the changes
> > applied on top of the bad commit to make it compile and run on my board.
> > Most of the patch is probably not important, though. There are two hunks
> > which have the pageblock changes I already posted an two other hunks
> > with the patch you posted earlier.
> >
> > I hope this helps. If you want me to run any other tests, please let me
> > know.
> >
>
> Can you test with this on top please?
That doesn't build on top of the bad commit. Or is it supposed to go on
top of next-20120926?
Note that I've also been doing some more testing on next-20121002 and
things seem to be better. The cmatest module runs successfully. That
seems to be due to commit 061d7cd, which, IIRC, is the correct patch to
fix the build breakage that I tried to fix with #ifdef'ery. For CMA this
allows the allocations to succeed, but with COMPACTION enabled this
should still fail. My test case was always !COMPACTION, though.
However, when I run the original test case, which is allocation of a
framebuffer for HDMI it still fails. The allocation size is 8294400
bytes. Exactly 8 MiB (== 8388608 bytes) and 16 MiB (== 16777216 bytes)
do work properly. 8 MiB + 4 KiB for instance fails as well, while
exactly 10 MiB works again.
Thierry
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists