kernel.git/arch/x86/kernel/apic, branch linux-2.6.30.y

x86: Fix x86_model test in es7000_apic_is_cluster()

2009-09-24T15:27:20Z

commit 005155b1f626d2b2d7932e4afdf4fead168c6888 upstream. For the x86_model to be greater than 6 or less than 12 is logically always true. Signed-off-by: Roel Kluin Cc: Andrew Morton Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: don't send an IPI to the empty set of CPU's

2009-09-09T03:33:15Z

commit 83d349f35e1ae72268c5104dbf9ab2ae635425d4 upstream. The default_send_IPI_mask_logical() function uses the "flat" APIC mode to send an IPI to a set of CPU's at once, but if that set happens to be empty, some older local APIC's will apparently be rather unhappy. So just warn if a caller gives us an empty mask, and ignore it. This fixes a regression in 2.6.30.x, due to commit 4595f9620 ("x86: change flush_tlb_others to take a const struct cpumask"), documented here: http://bugzilla.kernel.org/show_bug.cgi?id=13933 which causes a silent lock-up. It only seems to happen on PPro, P2, P3 and Athlon XP cores. Most developers sadly (or not so sadly, if you're a developer..) have more modern CPU's. Also, on x86-64 we don't use the flat APIC mode, so it would never trigger there even if the APIC didn't like sending an empty IPI mask. Reported-by: Pavel Vilim Reported-and-tested-by: Thomas Björnell Reported-and-tested-by: Martin Rogge Cc: Mike Travis Cc: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

x86/pci: insert ioapic resource before assigning unassigned resources

2009-07-30T21:39:55Z

commit 857fdc53a0a90c3ba7fcf5b1fb4c7a62ae03cf82 upstream. Stephen reported that his DL585 G2 needed noapic after 2.6.22 (?) Dann bisected it down to: commit 30a18d6c3f1e774de656ebd8ff219d53e2ba4029 Date: Tue Feb 19 03:21:20 2008 -0800 x86: multi pci root bus with different io resource range, on 64-bit It turns out that: 1. that AMD-based systems have two HT chains. 2. BIOS doesn't allocate resources for BAR 6 of devices under 8132 etc 3. that multi-peer-root patch will try to split root resources to peer root resources according to PCI conf of NB 4. PCI core assigns unassigned resources, but they overlap with BARs that are used by ioapic addr of io4 and 8132. The reason: at that point ioapic address are not inserted yet. Solution is to insert ioapic resources into the tree a bit earlier. Reported-by: Stephen Frost Reported-and-Tested-by: dann frazier Signed-off-by: Yinghai Lu Signed-off-by: Jesse Barnes Signed-off-by: Greg Kroah-Hartman

x86, UV: Fix macros for multiple coherency domains

2009-07-02T23:49:55Z

commit c4ed3f04ba9defe22aa729d1646f970f791c03d7 upstream. Fix bug in the SGI UV macros that support systems with multiple coherency domains. The macros used for referencing global MMR (chipset registers) are failing to correctly "or" the NASID (node identifier) bits that reside above M+N. These high bits are supplied automatically by the chipset for memory accesses coming from the processor socket. However, the bits must be present for references to the special global MMR space used to map chipset registers. (See uv_hub.h for more details ...) The bug results in references to invalid/incorrect nodes. Signed-off-by: Jack Steiner LKML-Reference: <20090608154405.GA16395@sgi.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: Fix false positive section mismatch warnings in the apic code

2009-05-10T07:26:54Z

[ Impact: reduce kernel image size a bit, annotate away warnings ] Signed-off-by: Sam Ravnborg [ modified and tested it ] Signed-off-by: Rakib Mullick Cc: Marcin Slusarz LKML-Reference: Signed-off-by: Ingo Molnar

Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2009-04-26T17:29:38Z

* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86, hpet: Stop soliciting hpet=force users on ICH4M x86: check boundary in setup_node_bootmem() uv_time: add parameter to uv_read_rtc() x86: hpet: fix periodic mode programming on AMD 81xx x86: more than 8 32-bit CPUs requires X86_BIGSMP x86: avoid theoretical spurious NMI backtraces with CONFIG_CPUMASK_OFFSTACK=y x86: fix boot crash in NMI watchdog with CONFIG_CPUMASK_OFFSTACK=y and flat APIC x86-64: fix FPU corruption with signals and preemption x86/uv: fix for no memory at paddr 0 docs, x86: add nox2apic back to kernel-parameters.txt x86: mm/numa_32.c calculate_numa_remap_pages should use __init x86, kbuild: make "make install" not depend on vmlinux x86/uv: fix init of cpu-less nodes x86/uv: fix init of memory-less nodes

Merge branch 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2009-04-26T17:29:18Z

* 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86/irq: mark NUMA_MIGRATE_IRQ_DESC broken x86, irq: Remove IRQ_DISABLED check in process context IRQ move

x86: avoid theoretical spurious NMI backtraces with CONFIG_CPUMASK_OFFSTACK=y

2009-04-21T08:09:50Z

In theory (though not shown in practice) alloc_cpumask_var() doesn't zero memory, so CPUs might print an "NMI backtrace for cpu %d" once on boot. (Bug introduced in fcef8576d8a64fc603e719c97d423f9f6d4e0e8b). [ Impact: avoid theoretical syslog noise in rare configs ] Signed-off-by: Rusty Russell Cc: Steven Rostedt LKML-Reference: Signed-off-by: Ingo Molnar

x86: fix boot crash in NMI watchdog with CONFIG_CPUMASK_OFFSTACK=y and flat APIC

2009-04-21T08:09:49Z

fcef8576d8a64fc603e719c97d423f9f6d4e0e8b converted backtrace_mask to a cpumask_var_t, and assumed check_nmi_watchdog was called before nmi_watchdog_tick was ever called. Steven's oops shows I was wrong. This is something of a bandaid: I'm not sure we *should* be calling nmi_watchdog_tick before check_nmi_watchdog. Note that gcc eliminates this test for the CONFIG_CPUMASK_OFFSTACK=n case. [ Impact: fix boot crash in rare configs ] Reported-by: Steven Rostedt Signed-off-by: Rusty Russell LKML-Reference: Signed-off-by: Ingo Molnar

x86/uv: fix for no memory at paddr 0

2009-04-20T16:09:18Z

Fix endcase where the memory at physical address 0 does not really exist AND one of the sockets on blade 0 has no active cpus. The memory that _appears_ to be at physical address 0 is actually memory that located at a different address but has been remapped by the chipset so that it appears to be at physical address 0. When determining the UV pnode, the algorithm for determining the pnode incorrectly used the relocated physical address instead of the actual (global) address. [ Impact: boot failure on partitioned systems ] Signed-off-by: Jack Steiner LKML-Reference: <20090420132530.GA23156@sgi.com> Signed-off-by: Ingo Molnar