linux-toradex.git/arch, branch v2.6.32.28

x86, vt-d: Fix the vt-d fault handling irq migration in the x2apic mode

2011-01-07T22:43:11+00:00

commit 086e8ced65d9bcc4a8e8f1cd39b09640f2883f90 upstream.

In x2apic mode, we need to set the upper address register of the fault
handling interrupt register of the vt-d hardware. Without this
irq migration of the vt-d fault handling interrupt is broken.

Signed-off-by: Kenji Kaneshige 
LKML-Reference: <1291225233.2648.39.camel@sbsiddha-MOBL3>
Signed-off-by: Suresh Siddha 
Acked-by: Chris Wright 
Tested-by: Takao Indoh 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86: Enable the intr-remap fault handling after local APIC setup

2011-01-07T22:43:11+00:00

commit 7f7fbf45c6b748074546f7f16b9488ca71de99c1 upstream.

Interrupt-remapping gets enabled very early in the boot, as it determines the
apic mode that the processor can use. And the current code enables the vt-d
fault handling before the setup_local_APIC(). And hence the APIC LDR registers
and data structure in the memory may not be initialized. So the vt-d fault
handling in logical xapic/x2apic modes were broken.

Fix this by enabling the vt-d fault handling in the end_local_APIC_setup()

A cleaner fix of enabling fault handling while enabling intr-remapping
will be addressed for v2.6.38. [ Enabling intr-remapping determines the
usage of x2apic mode and the apic mode determines the fault-handling
configuration. ]

Signed-off-by: Kenji Kaneshige 
LKML-Reference: <20101201062244.541996375@intel.com>
Signed-off-by: Suresh Siddha 
Acked-by: Chris Wright 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, gcc-4.6: Use gcc -m options when building vdso

2011-01-07T22:43:10+00:00

commit de2a8cf98ecdde25231d6c5e7901e2cffaf32af9 upstream.

The vdso Makefile passes linker-style -m options not to the linker but
to gcc.  This happens to work with earlier gcc, but fails with gcc
4.6.  Pass gcc-style -m options, instead.

Note: all currently supported versions of gcc supports -m32, so there
is no reason to conditionalize it any more.

Reported-by: H. J. Lu 
Signed-off-by: H. Peter Anvin 
LKML-Reference: 
Signed-off-by: Greg Kroah-Hartman

x86, amd: Fix panic on AMD CPU family 0x15

2011-01-07T22:43:08+00:00

[The mainline kernel doesn't have this problem. Commit "(23588c3) x86,
amd: Add support for CPUID topology extension of AMD CPUs" removed the
family check. But 2.6.32.y needs to be fixed.]

This CPU family check is not required -- existence of the NodeId MSR
is indicated by a CPUID feature flag which is already checked in
amd_fixup_dcm() -- and it needlessly prevents amd_fixup_dcm() to be
called for newer AMD CPUs.

In worst case this can lead to a panic in the scheduler code for AMD
family 0x15 multi-node AMD CPUs. I just have a picture of VGA console
output so I can't copy-and-paste it herein, but the call stack of such
a panic looked like:

  do_divide_error
  ...
  find_busiest_group
  run_rebalance_domains
  ...
  apic_timer_interrupt
  ...
  cpu_idle

The mainline kernel doesn't have this problem. Commit "(23588c3) x86,
amd: Add support for CPUID topology extension of AMD CPUs" removed the
family check. But 2.6.32.y needs to be fixed.

Signed-off-by: Andreas Herrmann 
Signed-off-by: Greg Kroah-Hartman

x86, hotplug: Use mwait to offline a processor, fix the legacy case

2011-01-07T22:43:01+00:00

upstream ea53069231f9317062910d6e772cca4ce93de8c8
x86, hotplug: Use mwait to offline a processor, fix the legacy case

Here included also some small follow-on patches to the same code:

upstream a68e5c94f7d3dd64fef34dd5d97e365cae4bb42a
x86, hotplug: Move WBINVD back outside the play_dead loop

upstream ce5f68246bf2385d6174856708d0b746dc378f20
x86, hotplug: In the MWAIT case of play_dead, CLFLUSH the cache line

https://bugzilla.kernel.org/show_bug.cgi?id=5471

Signed-off-by: H. Peter Anvin 
Signed-off-by: Len Brown 
Signed-off-by: Greg Kroah-Hartman

nmi: fix clock comparator revalidation

2010-12-09T21:27:13+00:00

commit e8129c642155616d9e2160a75f103e127c8c3708 upstream.

On each machine check all registers are revalidated. The save area for
the clock comparator however only contains the upper most seven bytes
of the former contents, if valid.
Therefore the machine check handler uses a store clock instruction to
get the current time and writes that to the clock comparator register
which in turn will generate an immediate timer interrupt.
However within the lowcore the expected time of the next timer
interrupt is stored. If the interrupt happens before that time the
handler won't be called. In turn the clock comparator won't be
reprogrammed and therefore the interrupt condition stays pending which
causes an interrupt loop until the expected time is reached.

On NOHZ machines this can result in unresponsive machines since the
time of the next expected interrupted can be a couple of days in the
future.

To fix this just revalidate the clock comparator register with the
expected value.
In addition the special handling for udelay must be changed as well.

Signed-off-by: Heiko Carstens 
Signed-off-by: Greg Kroah-Hartman

x86-32: Fix dummy trampoline-related inline stubs

2010-12-09T21:27:11+00:00

commit 8848a91068c018bc91f597038a0f41462a0f88a4 upstream.

Fix dummy inline stubs for trampoline-related functions when no
trampolines exist (until we get rid of the no-trampoline case
entirely.)

Signed-off-by: H. Peter Anvin 
Cc: Joerg Roedel 
Cc: Borislav Petkov 
LKML-Reference: <4C6C294D.3030404@zytor.com>
Signed-off-by: Greg Kroah-Hartman

x86, mm: Fix CONFIG_VMSPLIT_1G and 2G_OPT trampoline

2010-12-09T21:27:11+00:00

commit b7d460897739e02f186425b7276e3fdb1595cea7 upstream.

rc2 kernel crashes when booting second cpu on this CONFIG_VMSPLIT_2G_OPT
laptop: whereas cloning from kernel to low mappings pgd range does need
to limit by both KERNEL_PGD_PTRS and KERNEL_PGD_BOUNDARY, cloning kernel
pgd range itself must not be limited by the smaller KERNEL_PGD_BOUNDARY.

Signed-off-by: Hugh Dickins 
LKML-Reference: 
Signed-off-by: H. Peter Anvin 
Cc: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

x86-32: Separate 1:1 pagetables from swapper_pg_dir

2010-12-09T21:27:11+00:00

commit fd89a137924e0710078c3ae855e7cec1c43cb845 upstream.

This patch fixes machine crashes which occur when heavily exercising the
CPU hotplug codepaths on a 32-bit kernel. These crashes are caused by
AMD Erratum 383 and result in a fatal machine check exception. Here's
the scenario:

1. On 32-bit, the swapper_pg_dir page table is used as the initial page
table for booting a secondary CPU.

2. To make this work, swapper_pg_dir needs a direct mapping of physical
memory in it (the low mappings). By adding those low, large page (2M)
mappings (PAE kernel), we create the necessary conditions for Erratum
383 to occur.

3. Other CPUs which do not participate in the off- and onlining game may
use swapper_pg_dir while the low mappings are present (when leave_mm is
called). For all steps below, the CPU referred to is a CPU that is using
swapper_pg_dir, and not the CPU which is being onlined.

4. The presence of the low mappings in swapper_pg_dir can result
in TLB entries for addresses below __PAGE_OFFSET to be established
speculatively. These TLB entries are marked global and large.

5. When the CPU with such TLB entry switches to another page table, this
TLB entry remains because it is global.

6. The process then generates an access to an address covered by the
above TLB entry but there is a permission mismatch - the TLB entry
covers a large global page not accessible to userspace.

7. Due to this permission mismatch a new 4kb, user TLB entry gets
established. Further, Erratum 383 provides for a small window of time
where both TLB entries are present. This results in an uncorrectable
machine check exception signalling a TLB multimatch which panics the
machine.

There are two ways to fix this issue:

        1. Always do a global TLB flush when a new cr3 is loaded and the
        old page table was swapper_pg_dir. I consider this a hack hard
        to understand and with performance implications

        2. Do not use swapper_pg_dir to boot secondary CPUs like 64-bit
        does.

This patch implements solution 2. It introduces a trampoline_pg_dir
which has the same layout as swapper_pg_dir with low_mappings. This page
table is used as the initial page table of the booting CPU. Later in the
bringup process, it switches to swapper_pg_dir and does a global TLB
flush. This fixes the crashes in our test cases.

-v2: switch to swapper_pg_dir right after entering start_secondary() so
that we are able to access percpu data which might not be mapped in the
trampoline page table.

Signed-off-by: Joerg Roedel 
LKML-Reference: <20100816123833.GB28147@aftab>
Signed-off-by: Borislav Petkov 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, UV: Fix initialization of max_pnode

2010-12-09T21:27:07+00:00

commit 36ac4b987bea9a95217e1af552252f275ca7fc44 upstream.

Fix calculation of "max_pnode" for systems where the the highest
blade has neither cpus or memory. (And, yes, although rare this
does occur).

Signed-off-by: Jack Steiner 
LKML-Reference: <20100910150808.GA19802@sgi.com>
Signed-off-by: Ingo Molnar 
Cc: maximilian attems 
Signed-off-by: Greg Kroah-Hartman