MAX_IO_APICS #ifdef'd wrongly

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

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.

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

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