- 08 Jul, 2008 40 commits
-
-
Ingo Molnar authored
Conflicts: arch/x86/mm/init_64.c Signed-off-by:Ingo Molnar <mingo@elte.hu>
-
Ingo Molnar authored
-
Cliff Wickman authored
Someone could write 0 bytes to /proc/sgi_uv/ptc_statistics, causing optstr[count - 1] = '\0'; to write to who-knows-where. (Andi Kleen noticed this need from a patch I sent for similar code in the ia64 world (sn2_ptc_proc_write()).) (count less than zero is not possible here, as count is unsigned) Signed-off-by:
Cliff Wickman <cpw@sgi.com> Signed-off-by:
-
Cliff Wickman authored
v6: 6/19 close the security hole in uv_ptc_proc_write()) > Found a potential security hole while doing that: > static ssize_t uv_ptc_proc_write(struct file *file, const char __user *user, > size_t count, loff_t *data) > if (copy_from_user(optstr, user, count)) > return -EFAULT; > > is count guaranteed to never be larger than 64? is fixed below. It adds tlb_uv.o to the Makefile. Signed-off-by:
-
Jack Steiner authored
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. Signed-off-by:
Jack Steiner <steiner@sgi.com> Signed-off-by:
-
Jack Steiner authored
physid_mask_of_physid() causes a huge stack (12k) to be created if the number of APICS is large. Replace physid_mask_of_physid() with a new function that does not create large stacks. This is a problem only on large x86_64 systems. this paves the way to increase MAX_APICS. Signed-off-by:
-
Ingo Molnar authored
fix: arch/x86/kernel/tlb_uv.c: In function ‘uv_table_bases_init': arch/x86/kernel/tlb_uv.c:612: error: ‘bau_tabsp' undeclared (first use in this function) arch/x86/kernel/tlb_uv.c:612: error: (Each undeclared identifier is reported only once arch/x86/kernel/tlb_uv.c:612: error: for each function it appears in.) Signed-off-by: -
Ingo Molnar authored
Signed-off-by: -
Ingo Molnar authored
TLB shootdown for SGI UV. v5: 6/12 corrections/improvements per Ingo's second review Signed-off-by:
-
Cliff Wickman authored
TLB shootdown for SGI UV. v1: 6/2 original v2: 6/3 corrections/improvements per Ingo's review v3: 6/4 split atomic operations off to a separate patch (Jeremy's review) v4: 6/12 include <mach_apic.h> rather than <asm/mach-bigsmp/mach_apic.h> (fixes a !SMP build problem that Ingo found) fix the index on uv_table_bases[blade] Signed-off-by: -
Cliff Wickman authored
Provide atomic operations for increment of a 16-bit integer and logical OR into a 64-bit integer. Signed-off-by:
Jeremy Fitzhardinge <jeremy@goop.org> Signed-off-by:
-
Cliff Wickman authored
TLB shootdown for SGI UV. Depends on patch (in tip/x86/irq): x86-update-macros-used-by-uv-platform.patch Jack Steiner May 29 This patch provides the ability to flush TLB's in cpu's that are not on the local node. The hardware mechanism for distributing the flush messages is the UV's "broadcast assist unit". The hook to intercept TLB shootdown requests is a 2-line change to native_flush_tlb_others() (arch/x86/kernel/tlb_64.c). This code has been tested on a hardware simulator. The real hardware is not yet available. The shootdown statistics are provided through /proc/sgi_uv/ptc_statistics. The use of /sys was considered, but would have required the use of many /sys files. The debugfs was also considered, but these statistics should be available on an ongoing basis, not just for debugging. Issues to be fixed later: - The IRQ for the messaging interrupt is currently hardcoded as 200 (see UV_BAU_MESSAGE). It should be dynamically assigned in the future. - The use of appropriate udelay()'s is untested, as they are a problem in the simulator. Signed-off-by:
-
Ingo Molnar authored
-
Ingo Molnar authored
Conflicts: arch/x86/kernel/nmi.c arch/x86/kernel/nmi_32.c Signed-off-by: -
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: -
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:
-
