Skip to contentSkip to conversation

- Increase MAX_APICS for very large x86_64 configs

PATCH Applied Jack Steiner 2 participants 6 messages Jun 16, 2008 – Jun 19, 2008

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 - Increase MAX_APICS for very large x86_64 configs

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

---

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(-)
include/asm-x86/mpspec_def.h +5 -4
Index: linux/include/asm-x86/mpspec_def.h
===================================================================
@@ -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 {
Applied
#1 lore raw
Quoted 4 lines · Jack Steiner

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

applied to tip/x86/uv - thanks Jack.

Quoted 7 lines

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

#2 lore raw
Quoted 8 lines · Ingo Molnar
Quoted 7 lines

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.

Quoted 7 lines

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

#3 lore raw
Quoted 13 lines · Ingo Molnar
Quoted 10 lines · Ingo Molnar
Quoted 7 lines

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:

Quoted 9 lines
Quoted 5 lines

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

#4 lore raw
Quoted 5 lines · Jack Steiner
Quoted 2 lines

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.

Quoted 1 line

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

#5 lore raw
Quoted 9 lines · Ingo Molnar
Quoted 5 lines · Jack Steiner
Quoted 2 lines

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