Re: next Feb 10: mm/slqb build break

Re: next Feb 10: mm/slqb build break

[Pekka Enberg]

On Tue, Feb 10, 2009 at 11:54 AM, Sachin P. Sant <sachinp@in.ibm.com> wrote=
:
> Sachin P. Sant wrote:
>>
>> Hi Stephen,
>>
>> Todays next randconfig build on powerpc fails with
>>
>> =A0CC =A0 =A0 =A0mm/slqb.o
>> mm/slqb.c: In function __slab_free:
>> mm/slqb.c:1648: error: implicit declaration of function
>> slab_free_to_remote
>> mm/slqb.c: In function kmem_cache_open:
>> mm/slqb.c:2174: error: implicit declaration of function
>> kmem_cache_dyn_array_free
>> mm/slqb.c:2175: warning: label error_cpu_array defined but not used
>> mm/slqb.c: In function kmem_cache_destroy:
>> mm/slqb.c:2294: error: implicit declaration of function
>> claim_remote_free_list
>> mm/slqb.c: In function kmem_cache_reap_percpu:
>> mm/slqb.c:2547: error: implicit declaration of function
>> flush_remote_free_cache
>> mm/slqb.c: In function kmem_cache_init:
>> mm/slqb.c:2783: error: per_cpu__kmem_cpu_nodes undeclared (first use in
>> this function)
>> mm/slqb.c:2783: error: (Each undeclared identifier is reported only once
>> mm/slqb.c:2783: error: for each function it appears in.)
>> mm/slqb.c:2784: error: kmem_cpu_cache undeclared (first use in this
>> function)
>> make[1]: *** [mm/slqb.o] Error 1
>> make: *** [mm] Error 2
>
> CONFIG_SMP is not set hence the failure.

Actually, that's not the root cause here. You seem to have CONFIG_SMP
disabled but CONFIG_NUMA enabled. That's not possible on x86 which
makes me think it's a ppc kconfig bug. Hmm?

                                                     Pekka

Re: next Feb 10: mm/slqb build break

[Nick Piggin]

On Tue, Feb 10, 2009 at 01:53:51PM +0200, Pekka Enberg wrote:
> On Tue, Feb 10, 2009 at 11:54 AM, Sachin P. Sant <sachinp@in.ibm.com> wrote:
> > Sachin P. Sant wrote:
> >>
> >> Hi Stephen,
> >>
> >> Todays next randconfig build on powerpc fails with
> >>
> >>  CC      mm/slqb.o
> >> mm/slqb.c: In function __slab_free:
> >> mm/slqb.c:1648: error: implicit declaration of function
> >> slab_free_to_remote
> >> mm/slqb.c: In function kmem_cache_open:
> >> mm/slqb.c:2174: error: implicit declaration of function
> >> kmem_cache_dyn_array_free
> >> mm/slqb.c:2175: warning: label error_cpu_array defined but not used
> >> mm/slqb.c: In function kmem_cache_destroy:
> >> mm/slqb.c:2294: error: implicit declaration of function
> >> claim_remote_free_list
> >> mm/slqb.c: In function kmem_cache_reap_percpu:
> >> mm/slqb.c:2547: error: implicit declaration of function
> >> flush_remote_free_cache
> >> mm/slqb.c: In function kmem_cache_init:
> >> mm/slqb.c:2783: error: per_cpu__kmem_cpu_nodes undeclared (first use in
> >> this function)
> >> mm/slqb.c:2783: error: (Each undeclared identifier is reported only once
> >> mm/slqb.c:2783: error: for each function it appears in.)
> >> mm/slqb.c:2784: error: kmem_cpu_cache undeclared (first use in this
> >> function)
> >> make[1]: *** [mm/slqb.o] Error 1
> >> make: *** [mm] Error 2
> >
> > CONFIG_SMP is not set hence the failure.
> 
> Actually, that's not the root cause here. You seem to have CONFIG_SMP
> disabled but CONFIG_NUMA enabled. That's not possible on x86 which
> makes me think it's a ppc kconfig bug. Hmm?

If it is really a valid config, then we should be able to make
slqb build with it...

Re: next Feb 10: mm/slqb build break

[David Miller]

From: Nick Piggin <npiggin@suse.de>
Date: Thu, 12 Feb 2009 02:45:03 +0100

> On Tue, Feb 10, 2009 at 01:53:51PM +0200, Pekka Enberg wrote:
> > Actually, that's not the root cause here. You seem to have CONFIG_SMP
> > disabled but CONFIG_NUMA enabled. That's not possible on x86 which
> > makes me think it's a ppc kconfig bug. Hmm?
> 
> If it is really a valid config, then we should be able to make
> slqb build with it...

FWIW I only allow NUMA with SMP on sparc64, just like x86.

Although it seems IA64, like powerpc, does not have this restriction.
Hmmm...

Re: next Feb 10: mm/slqb build break

[Sachin P. Sant]

Nick Piggin wrote:
>> Actually, that's not the root cause here. You seem to have CONFIG_SMP
>> disabled but CONFIG_NUMA enabled. That's not possible on x86 which
>> makes me think it's a ppc kconfig bug. Hmm?
>>     
>
> If it is really a valid config, then we should be able to make
> slqb build with it...
I am not sure if this is a valid config. According to arch/powerpc/Kconfig
NUMA depends on PPC64 and defaults to y if SMP & PPC_PSERIES is set.

If this is not a valid config then may be the make randconfig rules
need to be changed accordingly.

Ben should know. Ben ??

Thanks
-Sachin

-- 

---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------