[PATCH] - Increase MAX_APICS for very large x86_64 configs

[PATCH] - Increase MAX_APICS for very large x86_64 configs

[Jack Steiner]

Increase the maximum number of apics when running very large
configurations. This patch has no affect on most systems.

Signed-off-by: Jack Steiner <steiner@sgi.com>

---

The patch has no effect on any 32-bit kernel. It adds ~4k to the size
of 64-bit kernels but only if NR_CPUS > 255.

This is a repost of an earlier patch (4/16) that  was implicated in
a random-qa failure. I have not been able to reproduce the failure
using the same boot args & config.  Best guess is that some other
patch caused random data corruption & this patch was a victim.



 include/asm-x86/mpspec_def.h |    9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

Index: linux/include/asm-x86/mpspec_def.h
===================================================================
--- linux.orig/include/asm-x86/mpspec_def.h	2008-06-08 09:05:51.140046529 -0500
+++ linux/include/asm-x86/mpspec_def.h	2008-06-08 09:05:55.244550306 -0500
@@ -17,10 +17,11 @@
 # define MAX_MPC_ENTRY 1024
 # define MAX_APICS      256
 #else
-/*
- * A maximum of 255 APICs with the current APIC ID architecture.
- */
-# define MAX_APICS 255
+# if NR_CPUS <= 255
+#  define MAX_APICS     255
+# else
+#  define MAX_APICS   32768
+# endif
 #endif
 
 struct intel_mp_floating {

Re: [PATCH] - Increase MAX_APICS for very large x86_64 configs

[Ingo Molnar]

* Jack Steiner <steiner@sgi.com> wrote:

> Increase the maximum number of apics when running very large 
> configurations. This patch has no affect on most systems.
> 
> Signed-off-by: Jack Steiner <steiner@sgi.com>

applied to tip/x86/uv - thanks Jack.

> The patch has no effect on any 32-bit kernel. It adds ~4k to the size 
> of 64-bit kernels but only if NR_CPUS > 255.
> 
> This is a repost of an earlier patch (4/16) that was implicated in a 
> random-qa failure. I have not been able to reproduce the failure using 
> the same boot args & config.  Best guess is that some other patch 
> caused random data corruption & this patch was a victim.

i have just re-tested the previously failing config on tip/master:

  http://redhat.com/~mingo/misc/config-Thu_Apr_17_10_17_14_CEST_2008.bad
  http://people.redhat.com/mingo/tip.git/README

and the good news is that it does not crash on bootup anymore. Perhaps 
one of Mike's fixes/improvements did the trick?

Nevertheless i'll keep an eye on this change and wont propagate it to 
linux-next for a few days to make sure it's all robust on a wide range 
of x86 testsystems.

	Ingo

Re: [PATCH] - Increase MAX_APICS for very large x86_64 configs

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> > The patch has no effect on any 32-bit kernel. It adds ~4k to the 
> > size of 64-bit kernels but only if NR_CPUS > 255.
> > 
> > This is a repost of an earlier patch (4/16) that was implicated in a 
> > random-qa failure. I have not been able to reproduce the failure 
> > using the same boot args & config.  Best guess is that some other 
> > patch caused random data corruption & this patch was a victim.
> 
> i have just re-tested the previously failing config on tip/master:
> 
>   http://redhat.com/~mingo/misc/config-Thu_Apr_17_10_17_14_CEST_2008.bad
>   http://people.redhat.com/mingo/tip.git/README
> 
> and the good news is that it does not crash on bootup anymore. Perhaps 
> one of Mike's fixes/improvements did the trick?

unfortunately it didnt last long, -tip randconfig auto-testing found 
that your patch causes a bootup crash:

[    0.352022] SMP mode deactivated.
[    0.355356] enabled ExtINT on CPU#0
[    0.358861] SMP disabled
[    0.361829] BUG: unable to handle kernel NULL pointer dereference at 00000000000008b0
[    0.364022] IP: [<ffffffff8028127b>] debug_mutex_add_waiter+0x4e/0x61
[    0.364022] PGD 0
[    0.364022] Thread overran stack, or stack corrupted

config, log and bzImage can be found here:

  http://redhat.com/~mingo/misc/config-Thu_Jun_19_12_10_40_CEST_2008.bad
  http://redhat.com/~mingo/misc/crash-Thu_Jun_19_12_10_40_CEST_2008.log
  http://redhat.com/~mingo/misc/bzImage-Thu_Jun_19_12_10_40_CEST_2008.bad

reverting your patch fixes the crash.

if you have trouble reproducing the problem then you should be able to 
stick the bzImage into any 64-bit PC's /etc/grub.conf (no initrd needed) 
and it should just crash straight away during bootup.

NOTE: -tip auto-testing randomizes various commonly used boot parameters 
as well, you can find them in the bootup log:

root=/dev/sda6 console=ttyS0,115200 earlyprintk=serial,ttyS0,115200 
debug initcall_debug apic=verbose sysrq_always_enabled ignore_loglevel 
selinux=0 maxcpus=1 nosmp no_hz=off highres=0 nmi_watchdog=0 noapic 
nolapic_timer hpet=disable idle=mwait idle=poll highmem=512m nopat notsc 
acpi=off pci=nomsi

this might be material to reproducing the crash.

NOTE2: the bzImage above will have the above boot parameters 
auto-appended, no need for you to configure them. But if you build your 
own kernel from tip/master using the above config you might have to add 
these boot parameters to the 'kernel' line of /etc/grub.conf to 
reproduce the crash.

	Ingo

Re: [PATCH] - Increase MAX_APICS for very large x86_64 configs

[Jack Steiner]

On Thu, Jun 19, 2008 at 12:32:42PM +0200, Ingo Molnar wrote:
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > > The patch has no effect on any 32-bit kernel. It adds ~4k to the 
> > > size of 64-bit kernels but only if NR_CPUS > 255.
> > > 
> > > This is a repost of an earlier patch (4/16) that was implicated in a 
> > > random-qa failure. I have not been able to reproduce the failure 
> > > using the same boot args & config.  Best guess is that some other 
> > > patch caused random data corruption & this patch was a victim.
> > 
> > i have just re-tested the previously failing config on tip/master:
> > 
> >   http://redhat.com/~mingo/misc/config-Thu_Apr_17_10_17_14_CEST_2008.bad
> >   http://people.redhat.com/mingo/tip.git/README
> > 
> > and the good news is that it does not crash on bootup anymore. Perhaps 
> > one of Mike's fixes/improvements did the trick?
> 
> unfortunately it didnt last long, -tip randconfig auto-testing found 
> that your patch causes a bootup crash:
> 

I built a "git-checkout -b tip-latest tip/auto-latest" tree but get compile errors.
Is this the right tree??


Have you seen this before:



In file included from arch/x86/mm/srat_64.c:13:
include/linux/acpi.h:97:1: warning: "NR_NODE_MEMBLKS" redefined
In file included from include/acpi/platform/aclinux.h:59,
                 from include/acpi/platform/acenv.h:140,
                 from include/acpi/acpi.h:54,
                 from include/linux/acpi.h:39,
                 from arch/x86/mm/srat_64.c:13:
include/asm/acpi.h:165:1: warning: this is the location of the previous definition
arch/x86/mm/srat_64.c:101: error: expected identifier or '(' before 'do'
arch/x86/mm/srat_64.c:101: error: expected identifier or '(' before 'while'
arch/x86/mm/srat_64.c:108: error: expected identifier or '(' before 'do'
arch/x86/mm/srat_64.c:108: error: expected identifier or '(' before 'while'
arch/x86/mm/srat_64.c:211: error: expected identifier or '(' before 'do'
arch/x86/mm/srat_64.c:211: error: expected identifier or '(' before 'while'

...


--- jack

Re: [PATCH] - Increase MAX_APICS for very large x86_64 configs

[Ingo Molnar]

* Jack Steiner <steiner@sgi.com> wrote:

> > unfortunately it didnt last long, -tip randconfig auto-testing found 
> > that your patch causes a bootup crash:
> 
> I built a "git-checkout -b tip-latest tip/auto-latest" tree but get 
> compile errors. Is this the right tree??

no, you should check out tip/master.

> Have you seen this before:

yes, the fix for that is in tip/out-of-tree. tip/master is the 
integration of all trees.

	Ingo

Re: [PATCH] - Increase MAX_APICS for very large x86_64 configs

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> * Jack Steiner <steiner@sgi.com> wrote:
> 
> > > unfortunately it didnt last long, -tip randconfig auto-testing found 
> > > that your patch causes a bootup crash:
> > 
> > I built a "git-checkout -b tip-latest tip/auto-latest" tree but get 
> > compile errors. Is this the right tree??
> 
> no, you should check out tip/master.

ah, i see - the readme was suggesting auto-latest - my bad. I've updated 
the readme.

	Ingo