public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* MAX_IO_APICS #ifdef'd wrongly
@ 2003-01-17  9:00 William Lee Irwin III
  2003-01-17 15:53 ` Martin J. Bligh
  0 siblings, 1 reply; 4+ messages in thread
From: William Lee Irwin III @ 2003-01-17  9:00 UTC (permalink / raw)
  To: Martin.Bligh; +Cc: akpm, linux-kernel

CONFIG_X86_NUMA no longer exists. This changes the MAX_IO_APICS
definition to 32, where it is required to be so large on NUMA-Q
in order to boot.


diff -urpN linux-2.5.59/include/asm-i386/apicdef.h ioapic-2.5.59/include/asm-i386/apicdef.h
--- linux-2.5.59/include/asm-i386/apicdef.h	2003-01-16 18:22:15.000000000 -0800
+++ ioapic-2.5.59/include/asm-i386/apicdef.h	2003-01-17 00:58:04.000000000 -0800
@@ -115,7 +115,7 @@
 
 #define APIC_BASE (fix_to_virt(FIX_APIC_BASE))
 
-#ifdef CONFIG_X86_NUMA
+#ifdef CONFIG_X86_NUMAQ
  #define MAX_IO_APICS 32
 #else
  #define MAX_IO_APICS 8

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: MAX_IO_APICS #ifdef'd wrongly
  2003-01-17  9:00 MAX_IO_APICS #ifdef'd wrongly William Lee Irwin III
@ 2003-01-17 15:53 ` Martin J. Bligh
  2003-01-17 23:14   ` William Lee Irwin III
  0 siblings, 1 reply; 4+ messages in thread
From: Martin J. Bligh @ 2003-01-17 15:53 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: akpm, linux-kernel

Summit needs this too, so it should really be CONFIG_NUMA at least.
Ideally this would go into subarch if we can move it cleanly (hint, hint ;-))
But other than that, yes ... I'll merge it.

Thanks,

M.

--On Friday, January 17, 2003 01:00:31 -0800 William Lee Irwin III <wli@holomorphy.com> wrote:

> CONFIG_X86_NUMA no longer exists. This changes the MAX_IO_APICS
> definition to 32, where it is required to be so large on NUMA-Q
> in order to boot.
> 
> 
> diff -urpN linux-2.5.59/include/asm-i386/apicdef.h ioapic-2.5.59/include/asm-i386/apicdef.h
> --- linux-2.5.59/include/asm-i386/apicdef.h	2003-01-16 18:22:15.000000000 -0800
> +++ ioapic-2.5.59/include/asm-i386/apicdef.h	2003-01-17 00:58:04.000000000 -0800
> @@ -115,7 +115,7 @@
>  
>  #define APIC_BASE (fix_to_virt(FIX_APIC_BASE))
>  
> -#ifdef CONFIG_X86_NUMA
> +#ifdef CONFIG_X86_NUMAQ
>   #define MAX_IO_APICS 32
>  #else
>   #define MAX_IO_APICS 8
> 
> 



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: MAX_IO_APICS #ifdef'd wrongly
  2003-01-17 15:53 ` Martin J. Bligh
@ 2003-01-17 23:14   ` William Lee Irwin III
  2003-01-18  0:52     ` Martin J. Bligh
  0 siblings, 1 reply; 4+ messages in thread
From: William Lee Irwin III @ 2003-01-17 23:14 UTC (permalink / raw)
  To: Martin J. Bligh; +Cc: akpm, linux-kernel

On Fri, Jan 17, 2003 at 07:53:41AM -0800, Martin J. Bligh wrote:
> Summit needs this too, so it should really be CONFIG_NUMA at least.
> Ideally this would go into subarch if we can move it cleanly (hint, hint ;-))
> But other than that, yes ... I'll merge it.
> Thanks,

I shot for the one liner that fixed the case I could test. Shoving it
into subarch is cleaner, but needs more code movement and changes the
prior semantics. The prior semantics were broken for larger Summit
configurations, hmm. Maybe _all_ the array sizes should go into some
kind of subarch analogue of param.h, e.g. mach_param.h

The only one I can think of that doesn't fly is NR_IRQS; once there
are more interrupt sources than FIRST_SYSTEM_VECTOR - FIRST_DEVICE_VECTOR
the whole of arch/i386/ appears to explode.

Someone somewhere should probably take notice of that.


Bill

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: MAX_IO_APICS #ifdef'd wrongly
  2003-01-17 23:14   ` William Lee Irwin III
@ 2003-01-18  0:52     ` Martin J. Bligh
  0 siblings, 0 replies; 4+ messages in thread
From: Martin J. Bligh @ 2003-01-18  0:52 UTC (permalink / raw)
  To: William Lee Irwin III; +Cc: akpm, linux-kernel

> I shot for the one liner that fixed the case I could test. Shoving it
> into subarch is cleaner, but needs more code movement and changes the
> prior semantics. The prior semantics were broken for larger Summit
> configurations, hmm. Maybe _all_ the array sizes should go into some
> kind of subarch analogue of param.h, e.g. mach_param.h

That sounds like the right thing to do longer-term ... let's change it 
to the defn below for now, so people's trees work, then have a proper 
think about to organise subarch to make this stuff work easily 
(no doubt there's other gremlins there to be fixed at the same time).

M.

diff -urpN -X /home/fletch/.diff.exclude virgin/include/asm-i386/apicdef.h max_io_apics/include/asm-i386/apicdef.h
--- virgin/include/asm-i386/apicdef.h	Fri Jan 17 09:18:31 2003
+++ max_io_apics/include/asm-i386/apicdef.h	Fri Jan 17 16:49:41 2003
@@ -115,7 +115,7 @@
 
 #define APIC_BASE (fix_to_virt(FIX_APIC_BASE))
 
-#ifdef CONFIG_X86_NUMA
+#ifdef CONFIG_NUMA
  #define MAX_IO_APICS 32
 #else
  #define MAX_IO_APICS 8


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-01-18  0:43 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-17  9:00 MAX_IO_APICS #ifdef'd wrongly William Lee Irwin III
2003-01-17 15:53 ` Martin J. Bligh
2003-01-17 23:14   ` William Lee Irwin III
2003-01-18  0:52     ` Martin J. Bligh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox