- 08 Jul, 2008 40 commits
-
-
Ingo Molnar authored
Conflicts: arch/x86/Kconfig arch/x86/kernel/e820.c arch/x86/kernel/efi_64.c arch/x86/kernel/mpparse.c arch/x86/kernel/setup.c arch/x86/kernel/setup_32.c arch/x86/mm/init_64.c include/asm-x86/proto.h Signed-off-by:Ingo Molnar <mingo@elte.hu>
-
Bernhard Walle authored
This patch uses reserve_bootmem_generic() instead of reserve_bootmem() to reserve the crashkernel memory on x86_64. That's necessary for NUMA machines, see 00212fef: [PATCH] Fix kdump Crash Kernel boot memory reservation for NUMA machines This patch will fix a boot memory reservation bug that trashes memory on the ES7000 when loading the kdump crash kernel. The code in arch/x86_64/kernel/setup.c to reserve boot memory for the crash kernel uses the non-numa aware "reserve_bootmem" function instead of the NUMA aware "reserve_bootmem_generic". I checked to make sure that no other function was using "reserve_bootmem" and found none, except the ones that had NUMA ifdef'ed out. I have tested this patch only on an ES7000 with NUMA on and off (numa=off) in a single (non-NUMA) and multi-cell (NUMA) configurations. Signed-off-by:
Amul Shah <amul.shah@unisys.com> Looks-good-to: Vivek Goyal <vgoyal@in.ibm.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org> The switch-back to reserve_bootmem() was accidentally introduced in 5c3391f9 when adding the BOOTMEM_EXCLUSIVE parameter. Signed-off-by:
Bernhard Walle <bwalle@suse.de> Signed-off-by:
-
Bernhard Walle authored
This patch adds a 'flags' parameter to reserve_bootmem_generic() like it already has been added in reserve_bootmem() with commit 72a7fe39. It also changes all users to use BOOTMEM_DEFAULT, which doesn't effectively change the behaviour. Since the change is x86-specific, I don't think it's necessary to add a new API for migration. There are only 4 users of that function. The change is necessary for the next patch, using reserve_bootmem_generic() for crashkernel reservation. Signed-off-by:
-
Randy Dunlap authored
Fix setup.c printk format warning: linux-next-20080605/arch/x86/kernel/setup.c: In function 'setup_per_cpu_areas': linux-next-20080605/arch/x86/kernel/setup.c:173: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'ssize_t' Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Vegard Nossum authored
Signed-off-by:
Vegard Nossum <vegard.nossum@gmail.com> Signed-off-by:
-
Mike Travis authored
* Replace usages of MAX_NUMNODES with nr_node_ids in kernel/sched.c, where appropriate. This saves some allocated space as well as many wasted cycles going through node entries that are non-existent. Signed-off-by:Mike Travis <travis@sgi.com> Signed-off-by:
-
Thomas Gleixner authored
sparse mutters: arch/x86/mm/numa_64.c:195:27: warning: symbol 'end_pfn' shadows an earlier one Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Thomas Gleixner authored
plat_node_bdata, cmdline, nodemap_addr, nodemap_size are local to numa_64.c. Make them static Signed-off-by:
-
Jeremy Fitzhardinge authored
Without this patch, my link fails with: arch/x86/kernel/built-in.o(.cpuinit.text+0x3c6e): In function `get_local_pda': : undefined reference to `_cpu_pda' arch/x86/kernel/built-in.o(.cpuinit.text+0x3cd1): In function `get_local_pda': : undefined reference to `after_bootmem' arch/x86/kernel/built-in.o(.cpuinit.text+0x3cec): In function `get_local_pda': : undefined reference to `_cpu_pda' make[2]: *** [.tmp_vmlinux1] Error 1 Caused by commit 766da892634694f795b18b9538407816896fc470 x86: remove static boot_cpu_pda array v2 Signed-off-by: -
Mike Travis authored
Ingo Molnar wrote: ... > they crashed after about 3 randconfig iterations with: > > early res: 4 [8000-afff] PGTABLE > early res: 5 [b000-b87f] MEMNODEMAP > PANIC: early exception 0e rip 10:ffffffff8077a150 error 2 cr2 37 > Pid: 0, comm: swapper Not tainted 2.6.25-sched-devel.git-x86-latest.git #14 > > Call Trace: > [<ffffffff81466196>] early_idt_handler+0x56/0x6a > [<ffffffff8077a150>] ? numa_set_node+0x30/0x60 > [<ffffffff8077a129>] ? numa_set_node+0x9/0x60 > [<ffffffff8147a543>] numa_init_array+0x93/0xf0 > [<ffffffff8147b039>] acpi_scan_nodes+0x3b9/0x3f0 > [<ffffffff8147a496>] numa_initmem_init+0x136/0x150 > [<ffffffff8146da5f>] setup_arch+0x48f/0x700 > [<ffffffff802566ea>] ? clockevents_register_notifier+0x3a/0x50 > [<ffffffff81466a87>] start_kernel+0xd7/0x440 > [<ffffffff81466422>] x86_64_start_kernel+0x222/0x280 ... Here's the fixup... This one should follow the previous patches. Thanks, Mike Signed-off-by:
-
Mike Travis authored
* Remove the boot_cpu_pda array and pointer table from the data section. Allocate the pointer table and array during init. do_boot_cpu() will reallocate the pda in node local memory and if the cpu is being brought up before the bootmem array is released (after_bootmem = 0), then it will free the initial pda. This will happen for all cpus present at system startup. This removes 512k + 32k bytes from the data section. For inclusion into sched-devel/latest tree. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + sched-devel/latest .../mingo/linux-2.6-sched-devel.git Signed-off-by: -
Mike Travis authored
* Consolidate node_to_cpumask operations and remove the 256k byte node_to_cpumask_map. This is done by allocating the node_to_cpumask_map array after the number of possible nodes (nr_node_ids) is known. * Debug printouts when CONFIG_DEBUG_PER_CPU_MAPS is active have been increased. It now shows faults when calling node_to_cpumask() and node_to_cpumask_ptr(). For inclusion into sched-devel/latest tree. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + sched-devel/latest .../mingo/linux-2.6-sched-devel.git Signed-off-by: -
Mike Travis authored
* Restore the nodenumber field in the x86_64 pda. This field is slightly different than the x86_cpu_to_node_map mainly because it's a static indication of which node the cpu is on while the cpu to node map is a dyanamic mapping that may get reset if the cpu goes offline. This also simplifies the numa_node_id() macro. For inclusion into sched-devel/latest tree. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + sched-devel/latest .../mingo/linux-2.6-sched-devel.git Signed-off-by: -
Mike Travis authored
* Introduce a new PER_CPU macro called "EARLY_PER_CPU". This is used by some per_cpu variables that are initialized and accessed before there are per_cpu areas allocated. ["Early" in respect to per_cpu variables is "earlier than the per_cpu areas have been setup".] This patchset adds these new macros: DEFINE_EARLY_PER_CPU(_type, _name, _initvalue) EXPORT_EARLY_PER_CPU_SYMBOL(_name) DECLARE_EARLY_PER_CPU(_type, _name) early_per_cpu_ptr(_name) early_per_cpu_map(_name, _idx) early_per_cpu(_name, _cpu) The DEFINE macro defines the per_cpu variable as well as the early map and pointer. It also initializes the per_cpu variable and map elements to "_initvalue". The early_* macros provide access to the initial map (usually setup during system init) and the early pointer. This pointer is initialized to point to the early map but is then NULL'ed when the actual per_cpu areas are setup. After that the per_cpu variable is the correct access to the variable. The early_per_cpu() macro is not very efficient but does show how to access the variable if you have a function that can be called both "early" and "late". It tests the early ptr to be NULL, and if not then it's still valid. Otherwise, the per_cpu variable is used instead: #define early_per_cpu(_name, _cpu) \ (early_per_cpu_ptr(_name) ? \ early_per_cpu_ptr(_name)[_cpu] : \ per_cpu(_name, _cpu)) A better method is to actually check the pointer manually. In the case below, numa_set_node can be called both "early" and "late": void __cpuinit numa_set_node(int cpu, int node) { int *cpu_to_node_map = early_per_cpu_ptr(x86_cpu_to_node_map); if (cpu_to_node_map) cpu_to_node_map[cpu] = node; else per_cpu(x86_cpu_to_node_map, cpu) = node; } * Add a flag "arch_provides_topology_pointers" that indicates pointers to topology cpumask_t maps are available. Otherwise, use the function returning the cpumask_t value. This is useful if cpumask_t set size is very large to avoid copying data on to/off of the stack. * The coverage of CONFIG_DEBUG_PER_CPU_MAPS has been increased while the non-debug case has been optimized a bit. * Remove an unreferenced compiler warning in drivers/base/topology.c * Clean up #ifdef in setup.c For inclusion into sched-devel/latest tree. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + sched-devel/latest .../mingo/linux-2.6-sched-devel.git Signed-off-by: -
Mike Travis authored
* Increase the limit of NR_CPUS to 4096 and introduce a boolean called "MAXSMP" which when set (e.g. "allyesconfig"), will set NR_CPUS = 4096 and NODES_SHIFT = 9 (512). * Changed max setting for NODES_SHIFT from 15 to 9 to accurately reflect the real limit. Signed-off-by: -
Mike Travis authored
Mike Travis wrote: > Ingo Molnar wrote: >> * Mike Travis <travis@sgi.com> wrote: >> >>> [Ingo - please replace "PATCH 07/11" with this one.] > >>> * Remove 544k bytes from the kernel by removing the boot_cpu_pda > >>> array from the data section and allocating it during startup. >>> Fixed panic in setup_per_cpu_areas when HOTPLUG_CPU not set. >>> >>> For inclusion into sched-devel/latest tree. >> sched-devel.git randconfig testing found another crash with your queue: >> >> [ 0.111060] Brought up 1 CPUs >> [ 0.111986] Total of 1 processors activated (4022.73 BogoMIPS). >> [ 0.112987] Testing NMI watchdog ... <1>BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 >> [ 0.114982] IP: [<ffffffff8180d4a0>] check_nmi_watchdog+0xb0/0x210 >> [ 0.114982] PGD 0 >> [ 0.114982] Oops: 0000 [1] SMP >> [ 0.114982] CPU 0 >> [............] >> >> http://redhat.com/~mingo/misc/config-Mon_Apr_28_23_25_25_CEST_2008.bad >> http://redhat.com/~mingo/misc/log-Mon_Apr_28_23_25_25_CEST_2008.bad >> >> Ingo > > Hi Ingo, > > I need a bit more information on your hardware configuration. Building a > kernel with the above config file started up fine on both the Intel and AMD > boxes. > > Based on the above output it looks like it might be a UP machine? ... Ok, I think I found it. In check_nmi_watchdog(): for (cpu = 0; cpu < NR_CPUS; cpu++) prev_nmi_count[cpu] = cpu_pda(cpu)->__nmi_count; As I mentioned it works fine on both of my systems so could you try it out? Thanks! Mike -- * Change function check_nmi_watchdog() to use nr_cpu_ids instead of NR_CPUS. Based on: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + sched-devel/latest .../mingo/linux-2.6-sched-devel.git Signed-off-by:
-
Yinghai Lu authored
also make bus_numa work even if ACPI_NUMA is not defined. don't call pxm_to_node again, and use node directly. Signed-off-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Yinghai Lu authored
a numa system (with multi HT chains) may return node without ram. Aka it is not online. Try to get an online node, otherwise return -1. Signed-off-by:
Yinghai Lu <yinghai.lu@sun.com> Signed-off-by:
-
Ingo Molnar authored
Conflicts: arch/x86/Kconfig arch/x86/kernel/io_apic_32.c arch/x86/kernel/setup_64.c arch/x86/mm/init_32.c Signed-off-by: -
Matthew Garrett authored
Some HP laptops have a problem with their DSDT reporting as HP/SB400/10000, which includes some code which overrides all temperature trip points to 16C if the INTIN2 input of the I/O APIC is enabled. This input is incorrectly designated the ISA IRQ 0 via an interrupt source override even though it is wired to the output of the master 8259A and INTIN0 is not connected at all. So far two models have been identified, namely nx6125 and nx6325. Use a knob provided by the I/O APIC interrupt registration code to abandon any attempts to route IRQ 0 through the I/O APIC for these systems. Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Cc: Len Brown <lenb@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Signed-off-by:
-
Maciej W. Rozycki authored
As discovered recently some systems exhibit problems when the 8254 timer IRQ is routed through the I/O APIC. These problems do not affect the timer IRQ itself and therefore cannot be detected when the correctness of operation of the interrupt is verified in check_timer(). Therefore the I/O APIC path of the timer IRQ has to be disabled entirely. This is a change that lets platforms ask for the timer IRQ not to be registered in the I/O APIC interrupt tables. The local APIC and ExtINTA paths are unaffected. This request is only taken into account for ACPI platforms as MP table systems seem unaffected so far. Signed-off-by:
-
Yinghai Lu authored
"Maciej W. Rozycki" <macro@linux-mips.org> said: > Given X86_64 selects X86_LOCAL_APIC I am not sure the redundancy seen >above does not actually obscure the logic behind... I think: > > depends on X86_LOCAL_APIC && !X86_VISWS > >would be clearer and get the same. Suggested-by:
-
Ingo Molnar authored
Signed-off-by: -
Yinghai Lu authored
Signed-off-by:
-
Yinghai Lu authored
v2: seperate "fix for compiling when MPPARSE is not set" to another patch make X86_MPPARSE to be selectable only when acpi is set and X86_MPPARSE will be set if acpi is not set. Signed-off-by: -
Yinghai Lu authored
if the system doesn't have ioapic, we don't need to store entries for mptable update also let mp_config_acpi_gsi not call func in mpparse so later could decouple mpparse with acpi more easily Reported-by:
Daniel Exner <dex@dragonslave.de> Signed-off-by:
-
Yinghai Lu authored
1. let 64bit support 88 and e801 too 2. introduce default_machine_specific_memory_setup, and reuse it for voyager v2: fix 64 bit compiling Signed-off-by:
-
Yinghai Lu authored
we don't need those mach_mpspec.h files now. Signed-off-by:
-
Yinghai Lu authored
seperate SRAT finding and parsing from get_memcfg_from_srat, and let getmemcfg_from_srat only handle array from previous step. Signed-off-by:
-
Yinghai Lu authored
we already have summit and etc depends on genericarch, so use genericarch only. Signed-off-by:
-
Yinghai Lu authored
... to make it more like 64-bit. Signed-off-by:
-
Yinghai Lu authored
... and kill e820_32/64.c and e820_32/64.h Signed-off-by:
-
Yinghai Lu authored
so don't punish all other cpus without that problem when init highmem Signed-off-by:
-
Yinghai Lu authored
and make 32-bit resource registration more like 64 bit. also move probe_roms back to setup_32.c Signed-off-by:
-
Huang, Ying authored
Because of the size limits of struct boot_params (zero page), the maximum number of E820 memory map entries can be passed to kernel is 128. As pointed by Paul Jackson, there is some machine produced by SGI with so many nodes that the number of E820 memory map entries is more than 128. To enabling Linux kernel on these system, a new setup data type named SETUP_E820_EXT is defined to pass additional memory map entries to Linux kernel. This patch is based on x86/auto-latest branch of git-x86 tree and has been tested on x86_64 and i386 platform. Signed-off-by:
Huang Ying <ying.huang@intel.com> Signed-off-by:
-
Yinghai Lu authored
use early_node_map to init high pages, so we can remove page_is_ram() and page_is_reserved_early() in the big loop with add_one_highpage also remove page_is_reserved_early(), it is not needed anymore. v2: fix the build of other platforms Signed-off-by:
-
Yinghai Lu authored
rename update_memory_range to e820_update_range rename add_memory_region to e820_add_region to make it more clear that they are about e820 map operations. Signed-off-by:
-
Yinghai Lu authored
so we don't get the same value multiple times. also make mp_config_acpi_legacy_irqs more readable by moving assignments together. Signed-off-by:
-
Yinghai Lu authored
Daniel Exner reported IO-APIC enumeration breakage in linux-next. Alexey Starikovskiy found out that it might be related to commit 2944e16b "x86: update mptable". use enable_update_mptable to decide if need check before add mp_irqs array. Reported-by:
Daniel Exner <webmaster@dragonslave.de> Signed-off-by:
-
Yinghai Lu authored
1. move that before zone_sizes_init ... 2. add free_early for one old one, otherwise it will be be reserved again when we init highmem. Signed-off-by:
-
