LKML Archive on lore.kernel.org help / color / mirror / Atom feed
* [PATCH] fix ACPI induced voyager compile failure @ 2008-10-30 21:01 James Bottomley 2008-10-30 21:58 ` Ingo Molnar 0 siblings, 1 reply; 6+ messages in thread From: James Bottomley @ 2008-10-30 21:01 UTC (permalink / raw) To: Ingo Molnar, Thomas Gleixner; +Cc: linux-kernel >From c339b7cdc39399855ec07dfbff67304f9c7fa49a Mon Sep 17 00:00:00 2001 From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: Wed, 29 Oct 2008 10:58:13 -0500 Subject: [VOYAGER] x86: don't pull asm/acpi.h into fixmap_32.h If it's not needed it causes compile failures. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> --- arch/x86/include/asm/fixmap_32.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/x86/include/asm/fixmap_32.h b/arch/x86/include/asm/fixmap_32.h index 09f29ab..c3302ee 100644 --- a/arch/x86/include/asm/fixmap_32.h +++ b/arch/x86/include/asm/fixmap_32.h @@ -25,7 +25,9 @@ extern unsigned long __FIXADDR_TOP; #ifndef __ASSEMBLY__ #include <linux/kernel.h> +#ifdef CONFIG_ACPI #include <asm/acpi.h> +#endif #include <asm/apicdef.h> #include <asm/page.h> #ifdef CONFIG_HIGHMEM -- 1.5.6.5 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fix ACPI induced voyager compile failure 2008-10-30 21:01 [PATCH] fix ACPI induced voyager compile failure James Bottomley @ 2008-10-30 21:58 ` Ingo Molnar 2008-10-30 22:04 ` James Bottomley 0 siblings, 1 reply; 6+ messages in thread From: Ingo Molnar @ 2008-10-30 21:58 UTC (permalink / raw) To: James Bottomley; +Cc: Thomas Gleixner, linux-kernel * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > >From c339b7cdc39399855ec07dfbff67304f9c7fa49a Mon Sep 17 00:00:00 2001 > From: James Bottomley <James.Bottomley@HansenPartnership.com> > Date: Wed, 29 Oct 2008 10:58:13 -0500 > Subject: [VOYAGER] x86: don't pull asm/acpi.h into fixmap_32.h > > If it's not needed it causes compile failures. > > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> > --- > arch/x86/include/asm/fixmap_32.h | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/x86/include/asm/fixmap_32.h b/arch/x86/include/asm/fixmap_32.h > index 09f29ab..c3302ee 100644 > --- a/arch/x86/include/asm/fixmap_32.h > +++ b/arch/x86/include/asm/fixmap_32.h > @@ -25,7 +25,9 @@ extern unsigned long __FIXADDR_TOP; > > #ifndef __ASSEMBLY__ > #include <linux/kernel.h> > +#ifdef CONFIG_ACPI > #include <asm/acpi.h> > +#endif hm, that's quite ugly - such headers are supposed to be safe even if CONFIG_APIC is not turned on. What kind of compiler failures are you getting, could you send the .config that triggers it? I'm curious what the real cause of the build failure is - the #ifdef you are adding seems to fix a symptom, not a real bug - and maybe we can do a better fix. Thanks, Ingo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fix ACPI induced voyager compile failure 2008-10-30 21:58 ` Ingo Molnar @ 2008-10-30 22:04 ` James Bottomley 2008-10-30 22:16 ` Ingo Molnar 0 siblings, 1 reply; 6+ messages in thread From: James Bottomley @ 2008-10-30 22:04 UTC (permalink / raw) To: Ingo Molnar; +Cc: Thomas Gleixner, linux-kernel On Thu, 2008-10-30 at 22:58 +0100, Ingo Molnar wrote: > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > >From c339b7cdc39399855ec07dfbff67304f9c7fa49a Mon Sep 17 00:00:00 2001 > > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > Date: Wed, 29 Oct 2008 10:58:13 -0500 > > Subject: [VOYAGER] x86: don't pull asm/acpi.h into fixmap_32.h > > > > If it's not needed it causes compile failures. > > > > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> > > --- > > arch/x86/include/asm/fixmap_32.h | 2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/arch/x86/include/asm/fixmap_32.h b/arch/x86/include/asm/fixmap_32.h > > index 09f29ab..c3302ee 100644 > > --- a/arch/x86/include/asm/fixmap_32.h > > +++ b/arch/x86/include/asm/fixmap_32.h > > @@ -25,7 +25,9 @@ extern unsigned long __FIXADDR_TOP; > > > > #ifndef __ASSEMBLY__ > > #include <linux/kernel.h> > > +#ifdef CONFIG_ACPI > > #include <asm/acpi.h> > > +#endif > > hm, that's quite ugly - such headers are supposed to be safe even if > CONFIG_APIC is not turned on. > > What kind of compiler failures are you getting, could you send the > .config that triggers it? I'm curious what the real cause of the build > failure is - the #ifdef you are adding seems to fix a symptom, not a > real bug - and maybe we can do a better fix. It's the problem of voyager wanting its own definition of phys_cpu_present_map. acpi.h pulls in mpspec.h which contaminates the voyager_smp.c build. Realistically, I was surprised that's the only problem, since mpspec.h contains an awful lot of apic related stuff. It was you who did this with: commit 4c1cbafb88490757a38119c41229251369bcecbc Author: Ingo Molnar <mingo@elte.hu> Date: Tue Jun 3 09:28:52 2008 +0200 x86 mpparse: build fix James ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fix ACPI induced voyager compile failure 2008-10-30 22:04 ` James Bottomley @ 2008-10-30 22:16 ` Ingo Molnar 2008-10-31 17:42 ` James Bottomley 0 siblings, 1 reply; 6+ messages in thread From: Ingo Molnar @ 2008-10-30 22:16 UTC (permalink / raw) To: James Bottomley; +Cc: Thomas Gleixner, linux-kernel * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > On Thu, 2008-10-30 at 22:58 +0100, Ingo Molnar wrote: > > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > > > >From c339b7cdc39399855ec07dfbff67304f9c7fa49a Mon Sep 17 00:00:00 2001 > > > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > > Date: Wed, 29 Oct 2008 10:58:13 -0500 > > > Subject: [VOYAGER] x86: don't pull asm/acpi.h into fixmap_32.h > > > > > > If it's not needed it causes compile failures. > > > > > > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> > > > --- > > > arch/x86/include/asm/fixmap_32.h | 2 ++ > > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > > > diff --git a/arch/x86/include/asm/fixmap_32.h b/arch/x86/include/asm/fixmap_32.h > > > index 09f29ab..c3302ee 100644 > > > --- a/arch/x86/include/asm/fixmap_32.h > > > +++ b/arch/x86/include/asm/fixmap_32.h > > > @@ -25,7 +25,9 @@ extern unsigned long __FIXADDR_TOP; > > > > > > #ifndef __ASSEMBLY__ > > > #include <linux/kernel.h> > > > +#ifdef CONFIG_ACPI > > > #include <asm/acpi.h> > > > +#endif > > > > hm, that's quite ugly - such headers are supposed to be safe even if > > CONFIG_APIC is not turned on. > > > > What kind of compiler failures are you getting, could you send the > > .config that triggers it? I'm curious what the real cause of the build > > failure is - the #ifdef you are adding seems to fix a symptom, not a > > real bug - and maybe we can do a better fix. > > It's the problem of voyager wanting its own definition of > phys_cpu_present_map. acpi.h pulls in mpspec.h which contaminates the > voyager_smp.c build. i guess voyager could use physid_mask_t just fine? physid_mask_t is MAX_APICS derived - but it should work out fine because AFAICS voyager has a maximum of 4 cpus (but definitely less than say 32), while MAX_APICS never goes below 256. Ingo ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fix ACPI induced voyager compile failure 2008-10-30 22:16 ` Ingo Molnar @ 2008-10-31 17:42 ` James Bottomley 2008-11-03 10:02 ` Ingo Molnar 0 siblings, 1 reply; 6+ messages in thread From: James Bottomley @ 2008-10-31 17:42 UTC (permalink / raw) To: Ingo Molnar; +Cc: Thomas Gleixner, linux-kernel On Thu, 2008-10-30 at 23:16 +0100, Ingo Molnar wrote: > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > On Thu, 2008-10-30 at 22:58 +0100, Ingo Molnar wrote: > > > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > > > > > >From c339b7cdc39399855ec07dfbff67304f9c7fa49a Mon Sep 17 00:00:00 2001 > > > > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > > > Date: Wed, 29 Oct 2008 10:58:13 -0500 > > > > Subject: [VOYAGER] x86: don't pull asm/acpi.h into fixmap_32.h > > > > > > > > If it's not needed it causes compile failures. > > > > > > > > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> > > > > --- > > > > arch/x86/include/asm/fixmap_32.h | 2 ++ > > > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > > > > > diff --git a/arch/x86/include/asm/fixmap_32.h b/arch/x86/include/asm/fixmap_32.h > > > > index 09f29ab..c3302ee 100644 > > > > --- a/arch/x86/include/asm/fixmap_32.h > > > > +++ b/arch/x86/include/asm/fixmap_32.h > > > > @@ -25,7 +25,9 @@ extern unsigned long __FIXADDR_TOP; > > > > > > > > #ifndef __ASSEMBLY__ > > > > #include <linux/kernel.h> > > > > +#ifdef CONFIG_ACPI > > > > #include <asm/acpi.h> > > > > +#endif > > > > > > hm, that's quite ugly - such headers are supposed to be safe even if > > > CONFIG_APIC is not turned on. > > > > > > What kind of compiler failures are you getting, could you send the > > > .config that triggers it? I'm curious what the real cause of the build > > > failure is - the #ifdef you are adding seems to fix a symptom, not a > > > real bug - and maybe we can do a better fix. > > > > It's the problem of voyager wanting its own definition of > > phys_cpu_present_map. acpi.h pulls in mpspec.h which contaminates the > > voyager_smp.c build. > > i guess voyager could use physid_mask_t just fine? > > physid_mask_t is MAX_APICS derived - but it should work out fine > because AFAICS voyager has a maximum of 4 cpus (but definitely less > than say 32), while MAX_APICS never goes below 256. Voyager has a max of 32 actually. The CPU numbering is also fixed and identifies the processor position (for FRU replacement), so the physical map is what we use throughout the code. The problem with the definition is that it makes a rather pointless distinction between physical and logical map types ... so there'd be a lot of code churn. It would be really nice if physmask_t and cpumask_t could become the same type ... then we could do all this and no-one would notice. James ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] fix ACPI induced voyager compile failure 2008-10-31 17:42 ` James Bottomley @ 2008-11-03 10:02 ` Ingo Molnar 0 siblings, 0 replies; 6+ messages in thread From: Ingo Molnar @ 2008-11-03 10:02 UTC (permalink / raw) To: James Bottomley, Yinghai Lu, H. Peter Anvin; +Cc: Thomas Gleixner, linux-kernel * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > On Thu, 2008-10-30 at 23:16 +0100, Ingo Molnar wrote: > > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > > > On Thu, 2008-10-30 at 22:58 +0100, Ingo Molnar wrote: > > > > * James Bottomley <James.Bottomley@HansenPartnership.com> wrote: > > > > > > > > > >From c339b7cdc39399855ec07dfbff67304f9c7fa49a Mon Sep 17 00:00:00 2001 > > > > > From: James Bottomley <James.Bottomley@HansenPartnership.com> > > > > > Date: Wed, 29 Oct 2008 10:58:13 -0500 > > > > > Subject: [VOYAGER] x86: don't pull asm/acpi.h into fixmap_32.h > > > > > > > > > > If it's not needed it causes compile failures. > > > > > > > > > > Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> > > > > > --- > > > > > arch/x86/include/asm/fixmap_32.h | 2 ++ > > > > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > > > > > > > diff --git a/arch/x86/include/asm/fixmap_32.h b/arch/x86/include/asm/fixmap_32.h > > > > > index 09f29ab..c3302ee 100644 > > > > > --- a/arch/x86/include/asm/fixmap_32.h > > > > > +++ b/arch/x86/include/asm/fixmap_32.h > > > > > @@ -25,7 +25,9 @@ extern unsigned long __FIXADDR_TOP; > > > > > > > > > > #ifndef __ASSEMBLY__ > > > > > #include <linux/kernel.h> > > > > > +#ifdef CONFIG_ACPI > > > > > #include <asm/acpi.h> > > > > > +#endif > > > > > > > > hm, that's quite ugly - such headers are supposed to be safe even if > > > > CONFIG_APIC is not turned on. > > > > > > > > What kind of compiler failures are you getting, could you send the > > > > .config that triggers it? I'm curious what the real cause of the build > > > > failure is - the #ifdef you are adding seems to fix a symptom, not a > > > > real bug - and maybe we can do a better fix. > > > > > > It's the problem of voyager wanting its own definition of > > > phys_cpu_present_map. acpi.h pulls in mpspec.h which contaminates the > > > voyager_smp.c build. > > > > i guess voyager could use physid_mask_t just fine? > > > > physid_mask_t is MAX_APICS derived - but it should work out fine > > because AFAICS voyager has a maximum of 4 cpus (but definitely less > > than say 32), while MAX_APICS never goes below 256. > > Voyager has a max of 32 actually. [...] (yes, <= 32 is what i meant.) > [...] The CPU numbering is also fixed and identifies the processor > position (for FRU replacement), so the physical map is what we use > throughout the code. The problem with the definition is that it > makes a rather pointless distinction between physical and logical > map types ... so there'd be a lot of code churn. It would be really > nice if physmask_t and cpumask_t could become the same type ... then > we could do all this and no-one would notice. if you mean physid_mask_t, i agree that it would be a tempting simplification if we got rid of the physid_mask_t distinction and made it equal to cpumask_t. If the largest APIC ID in the bootup gets larger than NR_CPUS we should just clip it and print a warning about it in the syslog. (it would likely not boot up though, if that ID is an ioapic's ID) OTOH, right now there's some practical complications: even on small systems we can easily get a relatively large APIC ID, needlessly driving up the NR_CPUS limit. Yinghai, Peter, what do you think? Ingo ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-11-03 10:02 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-10-30 21:01 [PATCH] fix ACPI induced voyager compile failure James Bottomley 2008-10-30 21:58 ` Ingo Molnar 2008-10-30 22:04 ` James Bottomley 2008-10-30 22:16 ` Ingo Molnar 2008-10-31 17:42 ` James Bottomley 2008-11-03 10:02 ` Ingo Molnar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).