From: Stephen Rothwell on
Hi all,

On Tue, 3 Aug 2010 02:23:10 +1000 Stephen Rothwell <sfr(a)canb.auug.org.au> wrote:
>
> Caused by commit 53e16bfaf19346f59b3502e207aa66c61332075c ("memblock:
> Introduce for_each_memblock() and new accessors, and use it") interacting
> with commit 2778f62056ada442414392d7ccd41188bb631619 ("ARM: initial LMB
> trial") and some others from the arm tree.

That same memblock commit broke the sh builds like this:

c1: warnings being treated as errors
arch/sh/mm/init.c: In function 'bootmem_init_one_node':
arch/sh/mm/init.c:227: error: unused variable 'i'
--
Cheers,
Stephen Rothwell sfr(a)canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
From: H. Peter Anvin on
On 08/02/2010 09:28 AM, Russell King wrote:
> On Tue, Aug 03, 2010 at 02:23:10AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> Lots (if not all) of the arm builds failed for next-20100802 with these
>> errors:
>>
>> arch/arm/mm/init.c: In function 'arm_bootmem_init':
>> arch/arm/mm/init.c:184: error: implicit declaration of function 'memblock_start_pfn'
>> arch/arm/mm/init.c:186: error: implicit declaration of function 'memblock_end_pfn'
>> arch/arm/mm/init.c:188: error: implicit declaration of function 'memblock_size_bytes'
>>
>> Caused by commit 53e16bfaf19346f59b3502e207aa66c61332075c ("memblock:
>> Introduce for_each_memblock() and new accessors, and use it") interacting
>> with commit 2778f62056ada442414392d7ccd41188bb631619 ("ARM: initial LMB
>> trial") and some others from the arm tree.
>
> Please, no, don't break the memblock code now. I'm not reworking the
> ARM implementation just as the merge window has opened - especially
> as the ARM implementation has now been pulled into other people's
> trees.
>
> If there's changes to memblock which haven't been in linux-next (which,
> as this is a new failure, that is most definitely the case), then they
> shouldn't be going into this merge window.
>

Ben, what's your tack on this?

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on
On Mon, 2010-08-02 at 09:32 -0700, H. Peter Anvin wrote:
> > Please, no, don't break the memblock code now. I'm not reworking the
> > ARM implementation just as the merge window has opened - especially
> > as the ARM implementation has now been pulled into other people's
> > trees.
> >
> > If there's changes to memblock which haven't been in linux-next (which,
> > as this is a new failure, that is most definitely the case), then they
> > shouldn't be going into this merge window.
> >
>
> Ben, what's your tack on this?

I'm perfectly happy to wait for the next merge window.. or even delay it
a bit til we can make sure ARM stuff is in, then memblock is updated to
also update ARM.

The latest failure is a bit of a concern... it shows that sh and
microblaze have not tested the series when I asked them to a while back
then, but then, I suppose everybody is short on time.

In any case, I'll fixup those glitches in my memblock branch, and we can
look at the ARM situation then and decide what to do.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on

> Please, no, don't break the memblock code now. I'm not reworking the
> ARM implementation just as the merge window has opened - especially
> as the ARM implementation has now been pulled into other people's
> trees.
>
> If there's changes to memblock which haven't been in linux-next (which,
> as this is a new failure, that is most definitely the case), then they
> shouldn't be going into this merge window.

I'm happy to wait and sit on the memblock churn until after ARM's in.

I can then fixup my patches.

Cheers,
Ben.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on
On 08/02/2010 06:42 PM, Benjamin Herrenschmidt wrote:
>
> I'm happy to wait and sit on the memblock churn until after ARM's in.
>
> I can then fixup my patches.
>

As far as x86 is concerned, I would like to try to get the whole thing
into -tip fairly early in a kernel cycle, so that it can get -tip/-next
testing for a while before merging.

I would much rather smoke out bugs like the qla2xxx failing to implement
..shutdown and therefore doing DMA on random memory than just paper it
over by functionally re-implementing a bunch of the memblock guts in x86.

I still think that the memblock approach of having a separate data
structure for all of memory and one for various used blocks is flawed,
and that it would be a lot better to have a single data structure with
attributes. It would definitely make allocation saner. Given that,
there is a strong reason to keep as little of the guts exposed as possible.

-hpa

--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/