Voyager phys_cpu_present_map compile error - Kernel

This is a discussion on Voyager phys_cpu_present_map compile error - Kernel ; Commit 2fe60147570231cde0d1f14711d2e34ccdf54b65 (x86: move up & smp variables to setup.c) broke Voyager: .... LD vmlinux.o arch/x86/mach-voyager/built-in.o .bss+0x30): multiple definition of `phys_cpu_present_map' arch/x86/kernel/built-in.o .bss+0x13c8): first defined here ld: Warning: size of symbol `phys_cpu_present_map' changed from 32 in arch/x86/kernel/built-in.o to 8 in ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 36

Thread: Voyager phys_cpu_present_map compile error

  1. Voyager phys_cpu_present_map compile error

    Commit 2fe60147570231cde0d1f14711d2e34ccdf54b65
    (x86: move up & smp variables to setup.c) broke Voyager:

    <-- snip -->

    ....
    LD vmlinux.o
    arch/x86/mach-voyager/built-in.o.bss+0x30): multiple definition of `phys_cpu_present_map'
    arch/x86/kernel/built-in.o.bss+0x13c8): first defined here
    ld: Warning: size of symbol `phys_cpu_present_map' changed from 32 in
    arch/x86/kernel/built-in.o to 8 in arch/x86/mach-voyager/built-in.o
    make[1]: *** [vmlinux.o] Error 1

    <-- snip -->

    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

    I shouldn't send bug reports at 3 in the morning...

    Attached is the .config for both Voyager build errors I reported.

    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



  3. Re: Voyager phys_cpu_present_map compile error


    * Adrian Bunk wrote:

    > I shouldn't send bug reports at 3 in the morning...
    >
    > Attached is the .config for both Voyager build errors I reported.


    thanks, the three patches below should fix it.

    i ended up excluding Voyager configs from our test space some time ago
    (and VISWS as well - there's one more visws fix in x86.git), that's how
    this broke. These subarchitectures seem not to be used at all and the
    code wont boot on normal PCs. We could mark it BROKEN but the fix seems
    simple in any case.

    Ingo

    ---------------------->
    Subject: x86: voyager fix
    From: Ingo Molnar
    Date: Mon Apr 21 13:39:53 CEST 2008

    Reported-by: Adrian Bunk
    Signed-off-by: Ingo Molnar
    ---
    arch/x86/Kconfig | 2 +-
    arch/x86/kernel/setup.c | 2 ++
    arch/x86/mach-voyager/voyager_smp.c | 17 -----------------
    3 files changed, 3 insertions(+), 18 deletions(-)

    Index: linux-x86.q/arch/x86/Kconfig
    ================================================== =================
    --- linux-x86.q.orig/arch/x86/Kconfig
    +++ linux-x86.q/arch/x86/Kconfig
    @@ -23,7 +23,7 @@ config X86
    select HAVE_KPROBES
    select HAVE_KRETPROBES
    select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
    - select HAVE_ARCH_KGDB
    + select HAVE_ARCH_KGDB if !X86_VOYAGER


    config GENERIC_LOCKBREAK
    Index: linux-x86.q/arch/x86/kernel/setup.c
    ================================================== =================
    --- linux-x86.q.orig/arch/x86/kernel/setup.c
    +++ linux-x86.q/arch/x86/kernel/setup.c
    @@ -21,8 +21,10 @@ EXPORT_SYMBOL(boot_cpu_physical_apicid);
    DEFINE_PER_CPU(u16, x86_cpu_to_apicid) = BAD_APICID;
    EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);

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

    #if defined(CONFIG_HAVE_SETUP_PER_CPU_AREA) && defined(CONFIG_SMP)
    /*
    Index: linux-x86.q/arch/x86/mach-voyager/voyager_smp.c
    ================================================== =================
    --- linux-x86.q.orig/arch/x86/mach-voyager/voyager_smp.c
    +++ linux-x86.q/arch/x86/mach-voyager/voyager_smp.c
    @@ -208,11 +208,6 @@ static struct irq_chip vic_chip = {
    /* used to count up as CPUs are brought on line (starts at 0) */
    static int cpucount = 0;

    -/* steal a page from the bottom of memory for the trampoline and
    - * squirrel its address away here. This will be in kernel virtual
    - * space */
    -unsigned char *trampoline_base;
    -
    /* The per cpu profile stuff - used in smp_local_timer_interrupt */
    static DEFINE_PER_CPU(int, prof_multiplier) = 1;
    static DEFINE_PER_CPU(int, prof_old_multiplier) = 1;
    @@ -429,18 +424,6 @@ void __init smp_store_cpu_info(int id)
    identify_secondary_cpu(c);
    }

    -/* set up the trampoline and return the physical address of the code */
    -unsigned long __init setup_trampoline(void)
    -{
    - /* these two are global symbols in trampoline.S */
    - extern const __u8 trampoline_end[];
    - extern const __u8 trampoline_data[];
    -
    - memcpy(trampoline_base, trampoline_data,
    - trampoline_end - trampoline_data);
    - return virt_to_phys(trampoline_base);
    -}
    -
    /* Routine initially called when a non-boot CPU is brought online */
    static void __init start_secondary(void *unused)
    {

    Subject: x86: Drop duplicate from setup.c
    From: Alexey Starikovskiy
    Date: Mon, 21 Apr 2008 13:31:55 +0400

    Signed-off-by: Alexey Starikovskiy
    Signed-off-by: Ingo Molnar
    ---
    arch/x86/kernel/setup.c | 2 --
    1 file changed, 2 deletions(-)

    Index: linux-x86.q/arch/x86/kernel/setup.c
    ================================================== =================
    --- linux-x86.q.orig/arch/x86/kernel/setup.c
    +++ linux-x86.q/arch/x86/kernel/setup.c
    @@ -18,8 +18,6 @@ unsigned disabled_cpus __cpuinitdata;
    unsigned int boot_cpu_physical_apicid = -1U;
    EXPORT_SYMBOL(boot_cpu_physical_apicid);

    -physid_mask_t phys_cpu_present_map;
    -
    DEFINE_PER_CPU(u16, x86_cpu_to_apicid) = BAD_APICID;
    EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);

    Subject: x86: fix compilation error in VisWS
    From: Alexey Starikovskiy
    Date: Mon, 21 Apr 2008 13:32:01 +0400

    Signed-off-by: Alexey Starikovskiy
    Signed-off-by: Ingo Molnar
    ---
    arch/x86/mach-visws/mpparse.c | 15 +--------------
    1 file changed, 1 insertion(+), 14 deletions(-)

    Index: linux-x86.q/arch/x86/mach-visws/mpparse.c
    ================================================== =================
    --- linux-x86.q.orig/arch/x86/mach-visws/mpparse.c
    +++ linux-x86.q/arch/x86/mach-visws/mpparse.c
    @@ -11,22 +11,9 @@
    /* Have we found an MP table */
    int smp_found_config;

    -/*
    - * Various Linux-internal data structures created from the
    - * MP-table.
    - */
    -int apic_version [MAX_APICS];
    -
    int pic_mode;
    -unsigned long mp_lapic_addr;
    -
    -/* Processor that is doing the boot up */
    -unsigned int boot_cpu_physical_apicid = -1U;
    -
    -/* Bitmask of physically existing CPUs */
    -physid_mask_t phys_cpu_present_map;

    -unsigned int __initdata maxcpus = NR_CPUS;
    +extern unsigned int __cpuinitdata maxcpus;

    /*
    * The Visual Workstation is Intel MP compliant in the hardware
    --
    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: Voyager phys_cpu_present_map compile error

    On Mon, Apr 21, 2008 at 02:00:54PM +0200, Ingo Molnar wrote:
    >
    > * Adrian Bunk wrote:
    >
    > > I shouldn't send bug reports at 3 in the morning...
    > >
    > > Attached is the .config for both Voyager build errors I reported.

    >
    > thanks, the three patches below should fix it.
    >...
    > Ingo
    >...
    > --- linux-x86.q.orig/arch/x86/kernel/setup.c
    > +++ linux-x86.q/arch/x86/kernel/setup.c
    > @@ -21,8 +21,10 @@ EXPORT_SYMBOL(boot_cpu_physical_apicid);
    > DEFINE_PER_CPU(u16, x86_cpu_to_apicid) = BAD_APICID;
    > EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);
    >
    > +#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).

    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/

  5. Re: Voyager phys_cpu_present_map compile error

    Ingo Molnar wrote:
    > * Adrian Bunk wrote:
    >
    >> I shouldn't send bug reports at 3 in the morning...
    >>
    >> Attached is the .config for both Voyager build errors I reported.

    >
    > thanks, the three patches below should fix it.
    >
    > i ended up excluding Voyager configs from our test space some time ago
    > (and VISWS as well - there's one more visws fix in x86.git), that's how
    > this broke. These subarchitectures seem not to be used at all and the
    > code wont boot on normal PCs. We could mark it BROKEN but the fix seems
    > simple in any case.
    >


    I talked to jejb about this, and pretty much the consensus was that if
    it breaks, mark it BROKEN, and let him come back and catch up. Under
    those conditions, I'm willing to keep it in the tree.

    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.

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

  6. Re: Voyager phys_cpu_present_map compile error

    Ingo Molnar wrote:
    > * Adrian Bunk wrote:
    >
    >> I shouldn't send bug reports at 3 in the morning...
    >>
    >> Attached is the .config for both Voyager build errors I reported.

    >
    > thanks, the three patches below should fix it.
    >
    > i ended up excluding Voyager configs from our test space some time ago
    > (and VISWS as well - there's one more visws fix in x86.git), that's how
    > this broke. These subarchitectures seem not to be used at all and the
    > code wont boot on normal PCs. We could mark it BROKEN but the fix seems
    > simple in any case.
    >


    I talked to jejb about this, and pretty much the consensus was that if
    it breaks, mark it BROKEN, and let him come back and catch up. Under
    those conditions, I'm willing to keep it in the tree.

    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.

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

  7. Status of SGI 320/540 (Visual Workstation) support?

    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?

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

  8. Re: Voyager phys_cpu_present_map compile error

    On Mon, 2008-04-21 at 09:00 -0400, H. Peter Anvin wrote:
    > Ingo Molnar wrote:
    > > * Adrian Bunk wrote:
    > >
    > >> I shouldn't send bug reports at 3 in the morning...
    > >>
    > >> Attached is the .config for both Voyager build errors I reported.

    > >
    > > thanks, the three patches below should fix it.
    > >
    > > i ended up excluding Voyager configs from our test space some time ago
    > > (and VISWS as well - there's one more visws fix in x86.git), that's how
    > > this broke. These subarchitectures seem not to be used at all and the
    > > code wont boot on normal PCs. We could mark it BROKEN but the fix seems
    > > simple in any case.


    I did actually try to avoid these problems by booting the -mc tree on
    voyager, but I note that none of these issues showed up in that tree the
    last time I did this (admittedly about 3 weeks ago because of various
    conferences etc).

    > I talked to jejb about this, and pretty much the consensus was that if
    > it breaks, mark it BROKEN, and let him come back and catch up. Under
    > those conditions, I'm willing to keep it in the tree.


    I didn't say mark it as BROKEN ... I did say I'd catch up. However,
    it's usually best to begin trying to fix voyager around the -rc1 phase
    since that's when the tree becomes stable again.

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


    I certainly don't have one. I just designed the subarchitectures to be
    able to support it because it was a bit far away from x86 references,
    and Andrey Panin was interested in supporting it at the time ... if he's
    no longer doing that, then it can be removed.

    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/

  9. Re: Voyager phys_cpu_present_map compile error

    On Mon, 2008-04-21 at 14:00 +0200, Ingo Molnar wrote:
    > * Adrian Bunk wrote:
    >
    > > I shouldn't send bug reports at 3 in the morning...
    > >
    > > Attached is the .config for both Voyager build errors I reported.

    >
    > thanks, the three patches below should fix it.
    >
    > i ended up excluding Voyager configs from our test space some time ago
    > (and VISWS as well - there's one more visws fix in x86.git), that's how
    > this broke. These subarchitectures seem not to be used at all and the
    > code wont boot on normal PCs. We could mark it BROKEN but the fix seems
    > simple in any case.


    The voyager pieces of this code look fine to me. I can't test at the
    moment because we're having the carpets cleaned and I can't get down
    into the cellar where the systems are, but I'll do so shortly.

    James


    > Ingo
    >
    > ---------------------->
    > Subject: x86: voyager fix
    > From: Ingo Molnar
    > Date: Mon Apr 21 13:39:53 CEST 2008
    >
    > Reported-by: Adrian Bunk
    > Signed-off-by: Ingo Molnar
    > ---
    > arch/x86/Kconfig | 2 +-
    > arch/x86/kernel/setup.c | 2 ++
    > arch/x86/mach-voyager/voyager_smp.c | 17 -----------------
    > 3 files changed, 3 insertions(+), 18 deletions(-)
    >
    > Index: linux-x86.q/arch/x86/Kconfig
    > ================================================== =================
    > --- linux-x86.q.orig/arch/x86/Kconfig
    > +++ linux-x86.q/arch/x86/Kconfig
    > @@ -23,7 +23,7 @@ config X86
    > select HAVE_KPROBES
    > select HAVE_KRETPROBES
    > select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
    > - select HAVE_ARCH_KGDB
    > + select HAVE_ARCH_KGDB if !X86_VOYAGER
    >
    >
    > config GENERIC_LOCKBREAK
    > Index: linux-x86.q/arch/x86/kernel/setup.c
    > ================================================== =================
    > --- linux-x86.q.orig/arch/x86/kernel/setup.c
    > +++ linux-x86.q/arch/x86/kernel/setup.c
    > @@ -21,8 +21,10 @@ EXPORT_SYMBOL(boot_cpu_physical_apicid);
    > DEFINE_PER_CPU(u16, x86_cpu_to_apicid) = BAD_APICID;
    > EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);
    >
    > +#ifndef CONFIG_X86_VOYAGER
    > /* Bitmask of physically existing CPUs */
    > physid_mask_t phys_cpu_present_map;
    > +#endif
    >
    > #if defined(CONFIG_HAVE_SETUP_PER_CPU_AREA) && defined(CONFIG_SMP)
    > /*
    > Index: linux-x86.q/arch/x86/mach-voyager/voyager_smp.c
    > ================================================== =================
    > --- linux-x86.q.orig/arch/x86/mach-voyager/voyager_smp.c
    > +++ linux-x86.q/arch/x86/mach-voyager/voyager_smp.c
    > @@ -208,11 +208,6 @@ static struct irq_chip vic_chip = {
    > /* used to count up as CPUs are brought on line (starts at 0) */
    > static int cpucount = 0;
    >
    > -/* steal a page from the bottom of memory for the trampoline and
    > - * squirrel its address away here. This will be in kernel virtual
    > - * space */
    > -unsigned char *trampoline_base;
    > -
    > /* The per cpu profile stuff - used in smp_local_timer_interrupt */
    > static DEFINE_PER_CPU(int, prof_multiplier) = 1;
    > static DEFINE_PER_CPU(int, prof_old_multiplier) = 1;
    > @@ -429,18 +424,6 @@ void __init smp_store_cpu_info(int id)
    > identify_secondary_cpu(c);
    > }
    >
    > -/* set up the trampoline and return the physical address of the code */
    > -unsigned long __init setup_trampoline(void)
    > -{
    > - /* these two are global symbols in trampoline.S */
    > - extern const __u8 trampoline_end[];
    > - extern const __u8 trampoline_data[];
    > -
    > - memcpy(trampoline_base, trampoline_data,
    > - trampoline_end - trampoline_data);
    > - return virt_to_phys(trampoline_base);
    > -}
    > -
    > /* Routine initially called when a non-boot CPU is brought online */
    > static void __init start_secondary(void *unused)
    > {
    >
    > Subject: x86: Drop duplicate from setup.c
    > From: Alexey Starikovskiy
    > Date: Mon, 21 Apr 2008 13:31:55 +0400
    >
    > Signed-off-by: Alexey Starikovskiy
    > Signed-off-by: Ingo Molnar
    > ---
    > arch/x86/kernel/setup.c | 2 --
    > 1 file changed, 2 deletions(-)
    >
    > Index: linux-x86.q/arch/x86/kernel/setup.c
    > ================================================== =================
    > --- linux-x86.q.orig/arch/x86/kernel/setup.c
    > +++ linux-x86.q/arch/x86/kernel/setup.c
    > @@ -18,8 +18,6 @@ unsigned disabled_cpus __cpuinitdata;
    > unsigned int boot_cpu_physical_apicid = -1U;
    > EXPORT_SYMBOL(boot_cpu_physical_apicid);
    >
    > -physid_mask_t phys_cpu_present_map;
    > -
    > DEFINE_PER_CPU(u16, x86_cpu_to_apicid) = BAD_APICID;
    > EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);
    >
    > Subject: x86: fix compilation error in VisWS
    > From: Alexey Starikovskiy
    > Date: Mon, 21 Apr 2008 13:32:01 +0400
    >
    > Signed-off-by: Alexey Starikovskiy
    > Signed-off-by: Ingo Molnar
    > ---
    > arch/x86/mach-visws/mpparse.c | 15 +--------------
    > 1 file changed, 1 insertion(+), 14 deletions(-)
    >
    > Index: linux-x86.q/arch/x86/mach-visws/mpparse.c
    > ================================================== =================
    > --- linux-x86.q.orig/arch/x86/mach-visws/mpparse.c
    > +++ linux-x86.q/arch/x86/mach-visws/mpparse.c
    > @@ -11,22 +11,9 @@
    > /* Have we found an MP table */
    > int smp_found_config;
    >
    > -/*
    > - * Various Linux-internal data structures created from the
    > - * MP-table.
    > - */
    > -int apic_version [MAX_APICS];
    > -
    > int pic_mode;
    > -unsigned long mp_lapic_addr;
    > -
    > -/* Processor that is doing the boot up */
    > -unsigned int boot_cpu_physical_apicid = -1U;
    > -
    > -/* Bitmask of physically existing CPUs */
    > -physid_mask_t phys_cpu_present_map;
    >
    > -unsigned int __initdata maxcpus = NR_CPUS;
    > +extern unsigned int __cpuinitdata maxcpus;
    >
    > /*
    > * The Visual Workstation is Intel MP compliant in the hardware


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


    * James Bottomley wrote:

    > > thanks, the three patches below should fix it.
    > >
    > > i ended up excluding Voyager configs from our test space some time
    > > ago (and VISWS as well - there's one more visws fix in x86.git),
    > > that's how this broke. These subarchitectures seem not to be used at
    > > all and the code wont boot on normal PCs. We could mark it BROKEN
    > > but the fix seems simple in any case.

    >
    > The voyager pieces of this code look fine to me. I can't test at the
    > moment because we're having the carpets cleaned and I can't get down
    > into the cellar where the systems are, but I'll do so shortly.


    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.

    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/

  11. Re: Voyager phys_cpu_present_map compile error


    * H. Peter Anvin wrote:

    >> thanks, the three patches below should fix it.
    >>
    >> i ended up excluding Voyager configs from our test space some time
    >> ago (and VISWS as well - there's one more visws fix in x86.git),
    >> that's how this broke. These subarchitectures seem not to be used at
    >> all and the code wont boot on normal PCs. We could mark it BROKEN but
    >> the fix seems simple in any case.

    >
    > I talked to jejb about this, and pretty much the consensus was that if
    > it breaks, mark it BROKEN, and let him come back and catch up. Under
    > those conditions, I'm willing to keep it in the tree.


    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.

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


    ok, but there we should first mark it BROKEN, and after 1-2 kernel
    releases remove it so that there's adequate notice.

    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/

  12. Re: Voyager phys_cpu_present_map compile error


    * James Bottomley wrote:

    > > > i ended up excluding Voyager configs from our test space some time
    > > > ago (and VISWS as well - there's one more visws fix in x86.git),
    > > > that's how this broke. These subarchitectures seem not to be used
    > > > at all and the code wont boot on normal PCs. We could mark it
    > > > BROKEN but the fix seems simple in any case.

    >
    > I did actually try to avoid these problems by booting the -mc tree on
    > voyager, but I note that none of these issues showed up in that tree
    > the last time I did this (admittedly about 3 weeks ago because of
    > various conferences etc).


    btw., any chance to turn it into a quirk space thing? Voyagers are
    almost-PCs, right? Most of the Voyager specialities appears to be
    abstracted away already via smp_ops. I.e. we could have Voyager support
    in a plain x86 kernel, if CONFIG_X86_VOYAGER is turned on.

    quirks we can let survive almost forever - we've still got the math-emu
    code for example. It's the subarch code we'd like to eliminate
    eventually. (there are much better abstractions for achieving the same
    thing: quirks and the genapic code)

    OTOH, i just had a look at it, and it seems a rather special thing - it
    tries to do like a PC but without actually being a PC. Almost as if it
    had no or just a little bit of BIOS - the whole Voyager kernel seems to
    run on the bare metal. Not much point in upsetting that code base i
    suspect.

    let us know if you run into any difficulties with making it to boot
    again ... nothing truly fundamental should have changed to break it,
    other that this moving around of SMP code.

    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/

  13. Re: Voyager phys_cpu_present_map compile error

    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?

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

  14. Re: Voyager phys_cpu_present_map compile error


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

    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 ;-)
    >
    > auto-tests could then still build-test NON_GENERIC kernels but would not
    > attempt to boot them up.
    >


    Well, that's slightly different. I don't think it's fair to impose even
    compile-testing Voyager on the entire x86 development community.

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

  16. Re: Voyager phys_cpu_present_map compile error


    * 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 ;-)

    auto-tests could then still build-test NON_GENERIC kernels but would not
    attempt to boot them up.

    hm?

    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/

  17. Re: Voyager phys_cpu_present_map compile error


    * 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.

    Ingo

    ------------>
    Subject: x86: make phys_cpu_present_map static in Voyager
    From: Alexey Starikovskiy
    Date: Tue, 22 Apr 2008 00:03:14 +0400

    Signed-off-by: Alexey Starikovskiy
    Signed-off-by: Ingo Molnar
    ---
    arch/x86/mach-voyager/voyager_smp.c | 24 ++++++++++++------------
    1 file changed, 12 insertions(+), 12 deletions(-)

    Index: linux-x86.q/arch/x86/mach-voyager/voyager_smp.c
    ================================================== =================
    --- linux-x86.q.orig/arch/x86/mach-voyager/voyager_smp.c
    +++ linux-x86.q/arch/x86/mach-voyager/voyager_smp.c
    @@ -74,7 +74,7 @@ EXPORT_SYMBOL(cpu_online_map);

    /* Bitmask of CPUs present in the system - exported by i386_syms.c, used
    * by scheduler but indexed physically */
    -cpumask_t phys_cpu_present_map = CPU_MASK_NONE;
    +static cpumask_t voyager_phys_cpu_present_map = CPU_MASK_NONE;

    /* The internal functions */
    static void send_CPI(__u32 cpuset, __u8 cpi);
    @@ -378,19 +378,19 @@ void __init find_smp_config(void)
    /* set up everything for just this CPU, we can alter
    * this as we start the other CPUs later */
    /* now get the CPU disposition from the extended CMOS */
    - cpus_addr(phys_cpu_present_map)[0] =
    + cpus_addr(voyager_phys_cpu_present_map)[0] =
    voyager_extended_cmos_read(VOYAGER_PROCESSOR_PRESE NT_MASK);
    - cpus_addr(phys_cpu_present_map)[0] |=
    + cpus_addr(voyager_phys_cpu_present_map)[0] |=
    voyager_extended_cmos_read(VOYAGER_PROCESSOR_PRESE NT_MASK + 1) << 8;
    - cpus_addr(phys_cpu_present_map)[0] |=
    + cpus_addr(voyager_phys_cpu_present_map)[0] |=
    voyager_extended_cmos_read(VOYAGER_PROCESSOR_PRESE NT_MASK +
    2) << 16;
    - cpus_addr(phys_cpu_present_map)[0] |=
    + cpus_addr(voyager_phys_cpu_present_map)[0] |=
    voyager_extended_cmos_read(VOYAGER_PROCESSOR_PRESE NT_MASK +
    3) << 24;
    - cpu_possible_map = phys_cpu_present_map;
    - printk("VOYAGER SMP: phys_cpu_present_map = 0x%lx\n",
    - cpus_addr(phys_cpu_present_map)[0]);
    + cpu_possible_map = voyager_phys_cpu_present_map;
    + printk("VOYAGER SMP: voyager_phys_cpu_present_map = 0x%lx\n",
    + cpus_addr(voyager_phys_cpu_present_map)[0]);
    /* Here we set up the VIC to enable SMP */
    /* enable the CPIs by writing the base vector to their register */
    outb(VIC_DEFAULT_CPI_BASE, VIC_CPI_BASE_REGISTER);
    @@ -649,15 +649,15 @@ void __init smp_boot_cpus(void)
    /* now that the cat has probed the Voyager System Bus, sanity
    * check the cpu map */
    if (((voyager_quad_processors | voyager_extended_vic_processors)
    - & cpus_addr(phys_cpu_present_map)[0]) !=
    - cpus_addr(phys_cpu_present_map)[0]) {
    + & cpus_addr(voyager_phys_cpu_present_map)[0]) !=
    + cpus_addr(voyager_phys_cpu_present_map)[0]) {
    /* should panic */
    printk("\n\n***WARNING*** "
    "Sanity check of CPU present map FAILED\n");
    }
    } else if (voyager_level == 4)
    voyager_extended_vic_processors =
    - cpus_addr(phys_cpu_present_map)[0];
    + cpus_addr(voyager_phys_cpu_present_map)[0];

    /* this sets up the idle task to run on the current cpu */
    voyager_extended_cpus = 1;
    @@ -689,7 +689,7 @@ void __init smp_boot_cpus(void)
    /* loop over all the extended VIC CPUs and boot them. The
    * Quad CPUs must be bootstrapped by their extended VIC cpu */
    for (i = 0; i < NR_CPUS; i++) {
    - if (i == boot_cpu_id || !cpu_isset(i, phys_cpu_present_map))
    + if (i == boot_cpu_id || !cpu_isset(i, voyager_phys_cpu_present_map))
    continue;
    do_boot_cpu(i);
    /* This udelay seems to be needed for the Quad boots
    --
    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/

  18. Re: Voyager phys_cpu_present_map compile error

    On Mon, Apr 21, 2008 at 09:51:48PM +0200, Ingo Molnar wrote:
    >
    > * James Bottomley wrote:
    >
    > > > thanks, the three patches below should fix it.
    > > >
    > > > i ended up excluding Voyager configs from our test space some time
    > > > ago (and VISWS as well - there's one more visws fix in x86.git),
    > > > that's how this broke. These subarchitectures seem not to be used at
    > > > all and the code wont boot on normal PCs. We could mark it BROKEN
    > > > but the fix seems simple in any case.

    > >
    > > The voyager pieces of this code look fine to me. I can't test at the
    > > moment because we're having the carpets cleaned and I can't get down
    > > into the cellar where the systems are, but I'll do so shortly.

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

    And I'm the first to remove non-working code, but as long as we
    ship it it should be in the best possible state.

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

  19. Re: Voyager phys_cpu_present_map compile error

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

    There goes your strawman.

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

  20. Re: Voyager phys_cpu_present_map compile error


    * 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.

    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/

+ Reply to Thread
Page 1 of 2 1 2 LastLast