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

Fix NULL ptr regression in powernow-k8

2009-10-05T15:28:00Z

commit f0adb134d8dc9993a9998dc50845ec4f6ff4fadc upstream. Fixes bugzilla #13780 From: Kurt Roeckx Signed-off-by: Dave Jones Signed-off-by: Greg Kroah-Hartman

KVM guest: fix bogus wallclock physical address calculation

2009-10-05T15:27:57Z

(cherry picked from commit a20316d2aa41a8f4fd171648bad8f044f6060826) The use of __pa() to calculate the address of a C-visible symbol is wrong, and can lead to unpredictable results. See arch/x86/include/asm/page.h for details. It should be replaced with __pa_symbol(), that does the correct math here, by taking relocations into account. This ensures the correct wallclock data structure physical address is passed to the hypervisor. Signed-off-by: Glauber Costa Signed-off-by: Avi Kivity Signed-off-by: Greg Kroah-Hartman

x86/i386: Make sure stack-protector segment base is cache aligned

2009-09-24T15:27:21Z

commit 1ea0d14e480c245683927eecc03a70faf06e80c8 upstream. The Intel Optimization Reference Guide says: In Intel Atom microarchitecture, the address generation unit assumes that the segment base will be 0 by default. Non-zero segment base will cause load and store operations to experience a delay. - If the segment base isn't aligned to a cache line boundary, the max throughput of memory operations is reduced to one [e]very 9 cycles. [...] Assembly/Compiler Coding Rule 15. (H impact, ML generality) For Intel Atom processors, use segments with base set to 0 whenever possible; avoid non-zero segment base address that is not aligned to cache line boundary at all cost. We can't avoid having a non-zero base for the stack-protector segment, but we can make it cache-aligned. Signed-off-by: Jeremy Fitzhardinge LKML-Reference: <4AA01893.6000507@goop.org> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

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, amd: Don't probe for extended APIC ID if APICs are disabled

2009-09-09T03:33:52Z

commit 2cb078603abb612e3bcd428fb8122c3d39e08832 upstream. If we've logically disabled apics, don't probe the PCI space for the AMD extended APIC ID. [ Impact: prevent boot crash under Xen. ] Signed-off-by: Jeremy Fitzhardinge Reported-by: Bastian Blank Signed-off-by: H. Peter Anvin Cc: Andreas Herrmann 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: Fix VMI && stack protector

2009-08-16T21:19:07Z

commit 7d5b005652bc5ae3e1e0efc53fd0e25a643ec506 upstream. With CONFIG_STACK_PROTECTOR turned on, VMI doesn't boot with more than one processor. The problem is with the gs value not being initialized correctly when registering the secondary processor for VMI's case. The patch below initializes the gs value for the AP to __KERNEL_STACK_CANARY. Without this the secondary processor keeps on taking a GP on every gs access. Signed-off-by: Alok N Kataria LKML-Reference: <1249425262.18955.40.camel@ank32.eng.vmware.com> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: Add quirk for Intel DG45ID board to avoid low memory corruption

2009-07-30T21:40:03Z

commit 6aa542a694dc9ea4344a8a590d2628c33d1b9431 upstream. AMI BIOS with low memory corruption was found on Intel DG45ID board (Bug 13710). Add this board to the blacklist - in the (somewhat optimistic) hope of future boards/BIOSes from Intel not having this bug. Also see: http://bugzilla.kernel.org/show_bug.cgi?id=13736 Signed-off-by: Alexey Fisher Cc: ykzhao Cc: alan@lxorguk.ukuu.org.uk Cc: LKML-Reference: <1247660169-4503-1-git-send-email-bug-track@fisher-privat.net> Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

x86: geode: Mark mfgpt irq IRQF_TIMER to prevent resume failure

2009-07-30T21:39:59Z

commit d6c585a4342a2ff627a29f9aea77c5ed4cd76023 upstream. Timer interrupts are excluded from being disabled during suspend. The clock events code manages the disabling of clock events on its own because the timer interrupt needs to be functional before the resume code reenables the device interrupts. The mfgpt timer request its interrupt without setting the IRQF_TIMER flag so suspend_device_irqs() disables it as well which results in a fatal resume failure. Adding IRQF_TIMER to the interupt flags when requesting the mrgpt timer interrupt solves the problem. Signed-off-by: Thomas Gleixner LKML-Reference: Cc: Andres Salomon 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