Voyager phys_cpu_present_map compile error - Kernel

This is a discussion on Voyager phys_cpu_present_map compile error - Kernel ; On Mon, Apr 21, 2008 at 10:29:19PM +0200, Ingo Molnar wrote: > > * Adrian Bunk wrote: > > > On Mon, Apr 21, 2008 at 10:13:52PM +0200, Ingo Molnar wrote: > > > > > > * Adrian Bunk ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 36 of 36

Thread: Voyager phys_cpu_present_map compile error

  1. Re: Voyager phys_cpu_present_map compile error

    On Mon, Apr 21, 2008 at 10:29:19PM +0200, Ingo Molnar wrote:
    >
    > * Adrian Bunk wrote:
    >
    > > On Mon, Apr 21, 2008 at 10:13:52PM +0200, Ingo Molnar wrote:
    > > >
    > > > * Adrian Bunk wrote:
    > > >
    > > > > > ok, that's good enough - that's why i excluded it from the auto-qa
    > > > > > test-space as well. Adrian, could you please remove it from your
    > > > > > config testset as well? If a user enables that config option it wont
    > > > > > boot anyway so it's not a problem in practice.
    > > > >
    > > > > Who said that Voyager won't boot?
    > > >
    > > > Adrian, you build Voyager kernels so just try to boot it once on
    > > > your PC and watch the show ...

    > >
    > > Ingo, an ia64 kernel also won't boot on my computer, and I'll still
    > > compile test my patches for ia64 ...

    >
    > dont be silly... the ia64 kernel is not under arch/x86, it's not even
    > the same instruction format. Voyager runs on x86 CPUs and is part of the
    > x86 architecture tree.


    Your point is?

    I'm compile testing 22 architectures (especially when sending my own
    patches), and whether a kernel would boot on my computer doesn't make
    any difference.

    Why do you as an architecture maintainer want me to no longer spend my
    spare time on compile testing one of the subarchitectures of your
    architecture?

    Other architecture maintainers tend to say "thanks for your bug report"
    and "thanks for your patch" when I'm sending bug reports and patches for
    platforms that have userbases comparable to Voyager...

    > Ingo


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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/

  2. Re: Voyager phys_cpu_present_map compile error


    On Mon, 2008-04-21 at 22:14 +0200, Ingo Molnar wrote:
    > * Adrian Bunk wrote:
    >
    > > > +#ifndef CONFIG_X86_VOYAGER
    > > > /* Bitmask of physically existing CPUs */
    > > > physid_mask_t phys_cpu_present_map;
    > > > +#endif
    > > >...

    > >
    > > Alexey noted that phys_cpu_present_map for Voyager and !Voyager also
    > > have different types and suggested to make the Voyager one static
    > > instead (additional renaming of the Voyager one also makes sense).

    >
    > yep, done by the patch below.


    Hang on; this doesn't looks like such a good idea. Why don't the
    definitions match? CPU type maps are supposed to be of type cpumask_t,
    so why bother reinventing a physid_mask_t which is essentially a cut and
    paste cpumask_t but on MAX_APICS instead of NR_CPUS ... surely we don't
    have to have that duplication ... particularly as m32r has gone and
    copied your definitions.

    I'm guessing you want large sparse phys maps and smaller logical cpumaps
    (although I'm not clear which archs can have a greater physical id than
    they support as cpus)? In which case, it still makes sense for this to
    be generic, using similar code in linux/cpumask.h to avoid further
    duplication?

    James


    --
    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/

  3. Re: Voyager phys_cpu_present_map compile error


    * Adrian Bunk wrote:

    > On Mon, Apr 21, 2008 at 10:29:19PM +0200, Ingo Molnar wrote:
    > >
    > > * Adrian Bunk wrote:
    > >
    > > > On Mon, Apr 21, 2008 at 10:13:52PM +0200, Ingo Molnar wrote:
    > > > >
    > > > > * Adrian Bunk wrote:
    > > > >
    > > > > > > ok, that's good enough - that's why i excluded it from the
    > > > > > > auto-qa test-space as well. Adrian, could you please remove
    > > > > > > it from your config testset as well? If a user enables that
    > > > > > > config option it wont boot anyway so it's not a problem in
    > > > > > > practice.
    > > > > >
    > > > > > Who said that Voyager won't boot?
    > > > >
    > > > > Adrian, you build Voyager kernels so just try to boot it once on
    > > > > your PC and watch the show ...
    > > >
    > > > Ingo, an ia64 kernel also won't boot on my computer, and I'll
    > > > still compile test my patches for ia64 ...

    > >
    > > dont be silly... the ia64 kernel is not under arch/x86, it's not
    > > even the same instruction format. Voyager runs on x86 CPUs and is
    > > part of the x86 architecture tree.

    >
    > Your point is?


    my point is what i said and which you apparently did not understand:

    | Adrian, could you please remove it from your config testset as well?
    | If a user enables that config option it wont boot anyway so it's not a
    | problem in practice.

    > I'm compile testing 22 architectures (especially when sending my own
    > patches), and whether a kernel would boot on my computer doesn't make
    > any difference.


    a user wont 'accidentally' install a crosscompiler toolchain to create
    an unbootable kernel...

    Ingo
    --
    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/

  4. Re: Status of SGI 320/540 (Visual Workstation) support?

    On 112, 04 21, 2008 at 05:10:58PM +0300, Adrian Bunk wrote:
    > On Mon, Apr 21, 2008 at 08:55:36AM -0400, H. Peter Anvin wrote:
    > >...
    > > VISWS is another matter. It's entirely possible I have the only
    > > remaining VISWS in my garage; we have at least not been able to locate
    > > another. Not that we have tried all that hard.
    > >
    > > If there are no VISWS' left, we should just unload the code.

    >
    > Googling a bit around 320/540 hardware does not seem to have completely
    > vanished from the earth, and there are still people who'd like to
    > install Linux on them.
    >
    > Looking through the archives of the mailing list in MAINTAINERS there
    > seem to be some older 2.6 kernels that worked on some Visual
    > Workstations, but no indication that recent kernels work.
    >
    > Andrey, what is the status of recent 2.6 kernels on the SGI 320/540?


    Right now it doesn't work, but there is a hope. I recovered my SGI 320
    recently and I plan to start hacking kernel on it Real Soon Now.

    --
    Andrey Panin | Linux and UNIX system administrator
    pazke@donpac.ru | PGP key: wwwkeys.pgp.net

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)

    iD8DBQFIDYNYIWZCBzwS8mkRAq83AKC1S14PtytEeSf08jpqne nfhp7y4wCfUeff
    yd8Uc2wg4P3EaaKlkaUc4Fk=
    =NfGK
    -----END PGP SIGNATURE-----


  5. Re: Voyager phys_cpu_present_map compile error

    > On Mon, 21 Apr 2008 08:55:36 -0400 "H. Peter Anvin" wrote:
    >
    > If there are no VISWS' left, we should just unload the code.


    yup, it's a desirable objective.

    I have a suspicion that there are no NUMAQs left either. Andy, would it be
    missed?

    --
    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/

  6. Re: Voyager phys_cpu_present_map compile error

    On Tue, Apr 22, 2008 at 06:29:27AM -0700, Andrew Morton wrote:
    > > On Mon, 21 Apr 2008 08:55:36 -0400 "H. Peter Anvin" wrote:
    > >
    > > If there are no VISWS' left, we should just unload the code.

    >
    > yup, it's a desirable objective.
    >
    > I have a suspicion that there are no NUMAQs left either. Andy, would it be
    > missed?


    Cirtainly these boxes are getting near end-of-life. I am not sure how
    many are out there beyond our the ones we have in the lab. We do
    maintain regular testing on them, even reporting them to TKO.

    The main reason we bother keeping them working is that they have a large
    numa ratio and tend to show up issues with other things, like the numa
    scheduler issues when we got that latest re-write.

    I has always been a shame that support wasn't included in generic, and
    as a result we have ended up with this three way split "generic, voyager,
    and numaq". It made sense at the time for developers, but never did for
    those down the food chain; particularly for distros.

    -apw
    --
    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/

  7. Re: Voyager phys_cpu_present_map compile error

    On Mon 2008-04-21 22:11:29, Ingo Molnar wrote:
    >
    > * H. Peter Anvin wrote:
    >
    > > Ingo Molnar wrote:
    > >>
    > >> sure - but no need to be rude and mark it BROKEN when we've got this much
    > >> better tool named "email". BROKEN is really just for cases where there's
    > >> no-one willing to fix things.

    > >
    > > I'm not trying to be rude, I'm just trying to avoid putting an
    > > unnecessary burden on testers and just let Kconfig know not to pick
    > > this particular random path. Obviously, Kconfig doesn't care, but
    > > it's clear BROKEN has negative associations; besides, it really is
    > > unnecessarily strong.
    > >
    > > Perhaps what we need is NORAND?

    >
    > yep, i was thinking about CONFIG_BROKEN2 already :-)
    >
    > then i came up with: CONFIG_NON_GENERIC. All code that can break a
    > normal bootup should be marked with that. Such as CONFIG_ROOT_NFS=y
    > [panics on bootup] or CONFIG_EUROTECH_WDT=y [crashes on bootup] or
    > CONFIG_SND_MTPAV [hangs on bootup] and the dozens of other config
    > options i had to map when trying to bring up an allyesconfig kernel for
    > the first time ;-)


    You certainly have my vote here. There's really big difference between
    'this breaks boot when y (NFS_ROOT)' and 'this is mostly harmless when
    y (any sane driver)'.

    Actually in nfsroot case, we should probably fix the code so that it
    is a nop w/out commandline option.

    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    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/

  8. Re: Voyager phys_cpu_present_map compile error

    On Mon, 2008-04-21 at 22:14 +0200, Ingo Molnar wrote:
    > * Adrian Bunk wrote:
    >
    > > > +#ifndef CONFIG_X86_VOYAGER
    > > > /* Bitmask of physically existing CPUs */
    > > > physid_mask_t phys_cpu_present_map;
    > > > +#endif
    > > >...

    > >
    > > Alexey noted that phys_cpu_present_map for Voyager and !Voyager also
    > > have different types and suggested to make the Voyager one static
    > > instead (additional renaming of the Voyager one also makes sense).

    >
    > yep, done by the patch below.


    Actually, this isn't the right patch. The point is not to avoid the
    symbol clash, it's to let voyager identify correctly that you have a
    leaking symbol. In this case phys_cpu_present_map is exposed outside of
    SMP. The correct fix (and one which sweeps op other storage for
    unnecessary symbols is this):

    James

    ---

    diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
    index c0c68c1..d68aa53 100644
    --- a/arch/x86/kernel/setup.c
    +++ b/arch/x86/kernel/setup.c
    @@ -12,6 +12,7 @@
    #include
    #include

    +#ifdef CONIFG_X86_SMP
    unsigned int num_processors;
    unsigned disabled_cpus __cpuinitdata;
    /* Processor that is doing the boot up */
    @@ -23,8 +24,9 @@ EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);

    /* Bitmask of physically existing CPUs */
    physid_mask_t phys_cpu_present_map;
    +#endif

    -#if defined(CONFIG_HAVE_SETUP_PER_CPU_AREA) && defined(CONFIG_SMP)
    +#if defined(CONFIG_HAVE_SETUP_PER_CPU_AREA) && defined(CONFIG_X86_SMP)
    /*
    * Copy data used in early init routines from the initial arrays to the
    * per cpu data areas. These arrays then become expendable and the


    --
    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/

  9. Re: Voyager phys_cpu_present_map compile error

    On Fri, Apr 25, 2008 at 09:50:43AM -0500, James Bottomley wrote:
    > On Mon, 2008-04-21 at 22:14 +0200, Ingo Molnar wrote:
    > > * Adrian Bunk wrote:
    > >
    > > > > +#ifndef CONFIG_X86_VOYAGER
    > > > > /* Bitmask of physically existing CPUs */
    > > > > physid_mask_t phys_cpu_present_map;
    > > > > +#endif
    > > > >...
    > > >
    > > > Alexey noted that phys_cpu_present_map for Voyager and !Voyager also
    > > > have different types and suggested to make the Voyager one static
    > > > instead (additional renaming of the Voyager one also makes sense).

    > >
    > > yep, done by the patch below.

    >
    > Actually, this isn't the right patch. The point is not to avoid the
    > symbol clash, it's to let voyager identify correctly that you have a
    > leaking symbol. In this case phys_cpu_present_map is exposed outside of
    > SMP. The correct fix (and one which sweeps op other storage for
    > unnecessary symbols is this):
    >
    > James
    >
    > ---
    >
    > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
    > index c0c68c1..d68aa53 100644
    > --- a/arch/x86/kernel/setup.c
    > +++ b/arch/x86/kernel/setup.c
    > @@ -12,6 +12,7 @@
    > #include
    > #include
    >
    > +#ifdef CONIFG_X86_SMP
    >...


    tpyo

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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/

  10. Re: Voyager phys_cpu_present_map compile error

    On Fri, 2008-04-25 at 19:17 +0300, Adrian Bunk wrote:
    > On Fri, Apr 25, 2008 at 09:50:43AM -0500, James Bottomley wrote:
    > > On Mon, 2008-04-21 at 22:14 +0200, Ingo Molnar wrote:
    > > > * Adrian Bunk wrote:
    > > >
    > > > > > +#ifndef CONFIG_X86_VOYAGER
    > > > > > /* Bitmask of physically existing CPUs */
    > > > > > physid_mask_t phys_cpu_present_map;
    > > > > > +#endif
    > > > > >...
    > > > >
    > > > > Alexey noted that phys_cpu_present_map for Voyager and !Voyager also
    > > > > have different types and suggested to make the Voyager one static
    > > > > instead (additional renaming of the Voyager one also makes sense).
    > > >
    > > > yep, done by the patch below.

    > >
    > > Actually, this isn't the right patch. The point is not to avoid the
    > > symbol clash, it's to let voyager identify correctly that you have a
    > > leaking symbol. In this case phys_cpu_present_map is exposed outside of
    > > SMP. The correct fix (and one which sweeps op other storage for
    > > unnecessary symbols is this):
    > >
    > > James
    > >
    > > ---
    > >
    > > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
    > > index c0c68c1..d68aa53 100644
    > > --- a/arch/x86/kernel/setup.c
    > > +++ b/arch/x86/kernel/setup.c
    > > @@ -12,6 +12,7 @@
    > > #include
    > > #include
    > >
    > > +#ifdef CONIFG_X86_SMP
    > >...

    >
    > tpyo


    Oh ... oops ... unfortunately one I wouldn't spot in a voyager build.

    This should be the corrected patch; thanks.

    James

    ---

    diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
    index c0c68c1..13ea170 100644
    --- a/arch/x86/kernel/setup.c
    +++ b/arch/x86/kernel/setup.c
    @@ -12,6 +12,7 @@
    #include
    #include

    +#ifdef CONFIG_X86_SMP
    unsigned int num_processors;
    unsigned disabled_cpus __cpuinitdata;
    /* Processor that is doing the boot up */
    @@ -23,8 +24,9 @@ EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);

    /* Bitmask of physically existing CPUs */
    physid_mask_t phys_cpu_present_map;
    +#endif

    -#if defined(CONFIG_HAVE_SETUP_PER_CPU_AREA) && defined(CONFIG_SMP)
    +#if defined(CONFIG_HAVE_SETUP_PER_CPU_AREA) && defined(CONFIG_X86_SMP)
    /*
    * Copy data used in early init routines from the initial arrays to the
    * per cpu data areas. These arrays then become expendable and the


    --
    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/

  11. Re: Voyager phys_cpu_present_map compile error

    Hi!

    > > > > > > Who said that Voyager won't boot?
    > > > > >
    > > > > > Adrian, you build Voyager kernels so just try to boot it once on
    > > > > > your PC and watch the show ...
    > > > >
    > > > > Ingo, an ia64 kernel also won't boot on my computer, and I'll
    > > > > still compile test my patches for ia64 ...
    > > >
    > > > dont be silly... the ia64 kernel is not under arch/x86, it's not
    > > > even the same instruction format. Voyager runs on x86 CPUs and is
    > > > part of the x86 architecture tree.

    > >
    > > Your point is?

    >
    > my point is what i said and which you apparently did not understand:
    >
    > | Adrian, could you please remove it from your config testset as well?
    > | If a user enables that config option it wont boot anyway so it's not a
    > | problem in practice.
    >
    > > I'm compile testing 22 architectures (especially when sending my own
    > > patches), and whether a kernel would boot on my computer doesn't make
    > > any difference.

    >
    > a user wont 'accidentally' install a crosscompiler toolchain to create
    > an unbootable kernel...


    I guess Adrian is trying to say:

    'That code is in tree, so it should compile and run. He can't verify
    it runs, but he's trying to make sure it at least compiles.'

    For 'normal' users it is not a problem.
    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    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/

  12. Re: Voyager phys_cpu_present_map compile error

    Pavel Machek wrote:
    >
    > I guess Adrian is trying to say:
    >
    > 'That code is in tree, so it should compile and run. He can't verify
    > it runs, but he's trying to make sure it at least compiles.'
    >
    > For 'normal' users it is not a problem.
    > Pavel


    This is fine, except it is an unreasonable request when there are fewer
    existing machines than people contributing to this tree. For a lot of
    people, compile bandwidth is what is limiting their ability to contribute.

    James has offered to fix up Voyager breakage a posteori, and that is the
    appropriate action for a niche architecture like this.

    -hpa
    --
    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/

  13. Re: Voyager phys_cpu_present_map compile error

    On Sat, Apr 26, 2008 at 05:44:26PM -0700, H. Peter Anvin wrote:
    > Pavel Machek wrote:
    >>
    >> I guess Adrian is trying to say:
    >>
    >> 'That code is in tree, so it should compile and run. He can't verify
    >> it runs, but he's trying to make sure it at least compiles.'
    >>
    >> For 'normal' users it is not a problem.
    >> Pavel

    >
    > This is fine, except it is an unreasonable request when there are fewer
    > existing machines than people contributing to this tree. For a lot of
    > people, compile bandwidth is what is limiting their ability to
    > contribute.


    I'm not claiming it was the end of the world if someone accidentally
    breaks Voyager.

    But Ingo wanted me to stop to sometimes compile test Voyager.

    > James has offered to fix up Voyager breakage a posteori, and that is the
    > appropriate action for a niche architecture like this.


    I'm still not getting the point why we should ever wait for James for
    doing things like
    - select HAVE_ARCH_KGDB
    + select HAVE_ARCH_KGDB if !X86_VOYAGER

    And the other compile breakages we had recently weren't much worse.

    I fully agree that it makes sense that Voyager problems should not be
    showstoppers and that James is the one capable and responsible of fixing
    non-trivial issues.

    > -hpa


    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

    --
    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/

  14. Re: Voyager phys_cpu_present_map compile error

    Adrian Bunk wrote:
    >
    > I'm not claiming it was the end of the world if someone accidentally
    > breaks Voyager.
    >
    > But Ingo wanted me to stop to sometimes compile test Voyager.
    >


    It would be good if "make randconfig" didn't go down this or other
    "secondary" paths.

    >> James has offered to fix up Voyager breakage a posteori, and that is the
    >> appropriate action for a niche architecture like this.

    >
    > I'm still not getting the point why we should ever wait for James for
    > doing things like
    > - select HAVE_ARCH_KGDB
    > + select HAVE_ARCH_KGDB if !X86_VOYAGER
    >
    > And the other compile breakages we had recently weren't much worse.
    >
    > I fully agree that it makes sense that Voyager problems should not be
    > showstoppers and that James is the one capable and responsible of fixing
    > non-trivial issues.


    That's fine, IMHO, just don't require *other* people to worry about it.

    -hpa
    --
    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/

  15. Re: Voyager phys_cpu_present_map compile error


    * James Bottomley wrote:

    > Oh ... oops ... unfortunately one I wouldn't spot in a voyager build.
    >
    > This should be the corrected patch; thanks.


    randconfig testing on x86.git found the build breakage below, i bisected
    it down to your patch. The config is:

    http://redhat.com/~mingo/misc/config..._CEST_2008.bad

    reverted the patch for now.

    Ingo

    ------------>
    arch/x86/kernel/built-in.o: In function `physflat_cpu_mask_to_apicid':
    genapic_flat_64.c.text+0x14373): undefined reference to `per_cpu__x86_cpu_to_apicid'
    arch/x86/kernel/built-in.o: In function `physflat_send_IPI_mask':
    genapic_flat_64.c.text+0x1447f): undefined reference to `per_cpu__x86_cpu_to_apicid'
    arch/x86/kernel/built-in.o: In function `flat_apic_id_registered':
    genapic_flat_64.c.text+0x14558): undefined reference to `phys_cpu_present_map'
    genapic_flat_64.c.text+0x1455f): undefined reference to `phys_cpu_present_map'
    arch/x86/kernel/built-in.o: In function `uv_cpu_mask_to_apicid':
    genx2apic_uv_x.c.text+0x14627): undefined reference to `per_cpu__x86_cpu_to_apicid'
    arch/x86/kernel/built-in.o: In function `uv_send_IPI_mask':
    genx2apic_uv_x.c.text+0x14658): undefined reference to `per_cpu__x86_cpu_to_apicid'
    arch/x86/kernel/built-in.o: In function `acpi_register_lapic_address':
    boot.c.init.text+0x3b1b): undefined reference to `boot_cpu_physical_apicid'
    boot.c.init.text+0x3b2c): undefined reference to `boot_cpu_physical_apicid'
    arch/x86/kernel/built-in.o: In function `__get_smp_config':
    mpparse.c.init.text+0x53ad): undefined reference to `num_processors'
    mpparse.c.init.text+0x53c4): undefined reference to `num_processors'
    mpparse.c.init.text+0x543c): undefined reference to `num_processors'
    arch/x86/kernel/built-in.o: In function `init_apic_mappings':
    : undefined reference to `boot_cpu_physical_apicid'
    arch/x86/kernel/built-in.o: In function `init_apic_mappings':
    : undefined reference to `boot_cpu_physical_apicid'
    arch/x86/kernel/built-in.o: In function `APIC_init_uniprocessor':
    : undefined reference to `boot_cpu_physical_apicid'
    arch/x86/kernel/built-in.o: In function `APIC_init_uniprocessor':
    : undefined reference to `phys_cpu_present_map'
    arch/x86/kernel/built-in.o: In function `APIC_init_uniprocessor':
    : undefined reference to `boot_cpu_physical_apicid'
    arch/x86/kernel/built-in.o: In function `early_init_lapic_mapping':
    : undefined reference to `boot_cpu_physical_apicid'
    arch/x86/kernel/built-in.o: In function `acpi_register_lapic':
    boot.c.cpuinit.text+0x177a): undefined reference to `disabled_cpus'
    arch/x86/kernel/built-in.o: In function `MP_processor_info':
    mpparse.c.cpuinit.text+0x179d): undefined reference to `disabled_cpus'
    mpparse.c.cpuinit.text+0x17b4): undefined reference to `boot_cpu_physical_apicid'
    arch/x86/kernel/built-in.o: In function `setup_secondary_APIC_clock':
    : undefined reference to `boot_cpu_physical_apicid'
    arch/x86/kernel/built-in.o: In function `generic_processor_info':
    : undefined reference to `num_processors'
    arch/x86/kernel/built-in.o: In function `generic_processor_info':
    : undefined reference to `num_processors'
    arch/x86/kernel/built-in.o: In function `generic_processor_info':
    : undefined reference to `phys_cpu_present_map'
    arch/x86/kernel/built-in.o: In function `generic_processor_info':
    : undefined reference to `per_cpu__x86_cpu_to_apicid'
    arch/x86/kernel/built-in.o: In function `uv_cpu_init':
    : undefined reference to `per_cpu__x86_cpu_to_apicid'
    arch/x86/kernel/built-in.o: In function `uv_cpu_init':
    : undefined reference to `per_cpu__x86_cpu_to_apicid'
    arch/x86/kernel/built-in.o: In function `uv_cpu_init':
    : undefined reference to `per_cpu__x86_cpu_to_apicid'

    --
    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/

  16. Re: Voyager phys_cpu_present_map compile error


    On Mon, 2008-04-28 at 19:59 +0200, Ingo Molnar wrote:
    > * James Bottomley wrote:
    >
    > > Oh ... oops ... unfortunately one I wouldn't spot in a voyager build.
    > >
    > > This should be the corrected patch; thanks.

    >
    > randconfig testing on x86.git found the build breakage below, i bisected
    > it down to your patch. The config is:
    >
    > http://redhat.com/~mingo/misc/config..._CEST_2008.bad
    >
    > reverted the patch for now.
    >
    > Ingo
    >
    > ------------>
    > arch/x86/kernel/built-in.o: In function `physflat_cpu_mask_to_apicid':
    > genapic_flat_64.c.text+0x14373): undefined reference to `per_cpu__x86_cpu_to_apicid'
    > arch/x86/kernel/built-in.o: In function `physflat_send_IPI_mask':
    > genapic_flat_64.c.text+0x1447f): undefined reference to `per_cpu__x86_cpu_to_apicid'
    > arch/x86/kernel/built-in.o: In function `flat_apic_id_registered':
    > genapic_flat_64.c.text+0x14558): undefined reference to `phys_cpu_present_map'
    > genapic_flat_64.c.text+0x1455f): undefined reference to `phys_cpu_present_map'
    > arch/x86/kernel/built-in.o: In function `uv_cpu_mask_to_apicid':
    > genx2apic_uv_x.c.text+0x14627): undefined reference to `per_cpu__x86_cpu_to_apicid'
    > arch/x86/kernel/built-in.o: In function `uv_send_IPI_mask':
    > genx2apic_uv_x.c.text+0x14658): undefined reference to `per_cpu__x86_cpu_to_apicid'
    > arch/x86/kernel/built-in.o: In function `acpi_register_lapic_address':
    > boot.c.init.text+0x3b1b): undefined reference to `boot_cpu_physical_apicid'
    > boot.c.init.text+0x3b2c): undefined reference to `boot_cpu_physical_apicid'
    > arch/x86/kernel/built-in.o: In function `__get_smp_config':
    > mpparse.c.init.text+0x53ad): undefined reference to `num_processors'
    > mpparse.c.init.text+0x53c4): undefined reference to `num_processors'
    > mpparse.c.init.text+0x543c): undefined reference to `num_processors'
    > arch/x86/kernel/built-in.o: In function `init_apic_mappings':
    > : undefined reference to `boot_cpu_physical_apicid'
    > arch/x86/kernel/built-in.o: In function `init_apic_mappings':
    > : undefined reference to `boot_cpu_physical_apicid'
    > arch/x86/kernel/built-in.o: In function `APIC_init_uniprocessor':
    > : undefined reference to `boot_cpu_physical_apicid'
    > arch/x86/kernel/built-in.o: In function `APIC_init_uniprocessor':
    > : undefined reference to `phys_cpu_present_map'
    > arch/x86/kernel/built-in.o: In function `APIC_init_uniprocessor':
    > : undefined reference to `boot_cpu_physical_apicid'
    > arch/x86/kernel/built-in.o: In function `early_init_lapic_mapping':
    > : undefined reference to `boot_cpu_physical_apicid'
    > arch/x86/kernel/built-in.o: In function `acpi_register_lapic':
    > boot.c.cpuinit.text+0x177a): undefined reference to `disabled_cpus'
    > arch/x86/kernel/built-in.o: In function `MP_processor_info':
    > mpparse.c.cpuinit.text+0x179d): undefined reference to `disabled_cpus'
    > mpparse.c.cpuinit.text+0x17b4): undefined reference to `boot_cpu_physical_apicid'
    > arch/x86/kernel/built-in.o: In function `setup_secondary_APIC_clock':
    > : undefined reference to `boot_cpu_physical_apicid'
    > arch/x86/kernel/built-in.o: In function `generic_processor_info':
    > : undefined reference to `num_processors'
    > arch/x86/kernel/built-in.o: In function `generic_processor_info':
    > : undefined reference to `num_processors'
    > arch/x86/kernel/built-in.o: In function `generic_processor_info':
    > : undefined reference to `phys_cpu_present_map'
    > arch/x86/kernel/built-in.o: In function `generic_processor_info':
    > : undefined reference to `per_cpu__x86_cpu_to_apicid'
    > arch/x86/kernel/built-in.o: In function `uv_cpu_init':
    > : undefined reference to `per_cpu__x86_cpu_to_apicid'
    > arch/x86/kernel/built-in.o: In function `uv_cpu_init':
    > : undefined reference to `per_cpu__x86_cpu_to_apicid'
    > arch/x86/kernel/built-in.o: In function `uv_cpu_init':
    > : undefined reference to `per_cpu__x86_cpu_to_apicid'



    Hmm, that's nasty. What it's showing is that the non-SMP local APIC
    configuration pulls in large numbers of SMP variables. This was all
    working right a while ago ... as in you need mpparse and the apic files
    but not the SMP ones or the SMP variables. The quickest fix is probably
    this one, since in these days of multi-core I suspect optimising the
    non-SMP but use APIC case for size has a lot less relevance.

    James

    ---

    diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
    index c0c68c1..808daf1 100644
    --- a/arch/x86/kernel/setup.c
    +++ b/arch/x86/kernel/setup.c
    @@ -12,6 +12,7 @@
    #include
    #include

    +#ifdef CONFIG_X86_MPPARSE
    unsigned int num_processors;
    unsigned disabled_cpus __cpuinitdata;
    /* Processor that is doing the boot up */
    @@ -23,8 +24,9 @@ EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);

    /* Bitmask of physically existing CPUs */
    physid_mask_t phys_cpu_present_map;
    +#endif

    -#if defined(CONFIG_HAVE_SETUP_PER_CPU_AREA) && defined(CONFIG_SMP)
    +#if defined(CONFIG_HAVE_SETUP_PER_CPU_AREA) && defined(CONFIG_X86_SMP)
    /*
    * Copy data used in early init routines from the initial arrays to the
    * per cpu data areas. These arrays then become expendable and the


    --
    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/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2