linux-stable.git/arch, branch linux-2.6.29.y

x86: Set cpu_llc_id on AMD CPUs

2009-07-02T23:40:51+00:00

commit 99bd0c0fc4b04da54cb311953ef9489931c19c63 upstream.

This counts when building sched domains in case NUMA information
is not available.

( See cpu_coregroup_mask() which uses llc_shared_map which in turn is
  created based on cpu_llc_id. )

Currently Linux builds domains as follows:
(example from a dual socket quad-core system)

 CPU0 attaching sched-domain:
  domain 0: span 0-7 level CPU
   groups: 0 1 2 3 4 5 6 7

  ...

 CPU7 attaching sched-domain:
  domain 0: span 0-7 level CPU
   groups: 7 0 1 2 3 4 5 6

Ever since that is borked for multi-core AMD CPU systems.
This patch fixes that and now we get a proper:

 CPU0 attaching sched-domain:
  domain 0: span 0-3 level MC
   groups: 0 1 2 3
   domain 1: span 0-7 level CPU
    groups: 0-3 4-7

  ...

 CPU7 attaching sched-domain:
  domain 0: span 4-7 level MC
   groups: 7 4 5 6
   domain 1: span 0-7 level CPU
    groups: 4-7 0-3

This allows scheduler to assign tasks to cores on different sockets
(i.e. that don't share last level cache) for performance reasons.

Signed-off-by: Andreas Herrmann 
LKML-Reference: <20090619085909.GJ5218@alberich.amd.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: handle initrd that extends into unusable memory

2009-07-02T23:40:46+00:00

commit 8c5dd8f43367f4f266dd616f11658005bc2d20ef upstream.

On a system where system memory (according e820) is not covered by
mtrr, mtrr_trim_memory converts a portion of memory to reserved, but
bootloader has already put the initrd in that range.

Thus, we need to have 64bit to use relocate_initrd too.

[ Impact: fix using initrd when mtrr_trim_memory happen ]

Signed-off-by: Yinghai Lu 
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86: Add quirk for reboot stalls on a Dell Optiplex 360

2009-07-02T23:40:42+00:00

commit 4a4aca641bc4598e77b866804f47c651ec4a764d upstream.

The Dell Optiplex 360 hangs on reboot, just like the Optiplex 330, so
the same quirk is needed.

Signed-off-by: Jean Delvare 
Cc: Steve Conklin 
Cc: Leann Ogasawara 
LKML-Reference: <200906051202.38311.jdelvare@suse.de>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

x86: hpet: fix periodic mode programming on AMD 81xx

2009-06-15T16:40:21+00:00

commit 7a6f9cbb37120c745fc187083fb5c3de4dca4f97 upstream.

(See http://bugzilla.kernel.org/show_bug.cgi?id=12961)

It partially reverts commit c23e253e67c9d8a91a0ffa33c1f571a17f0a2403
(x86: hpet: stop HPET_COUNTER when programming periodic mode)

HPET on AMD 81xx chipset needs a second write (with HPET_TN_SETVAL
cleared) to T0_CMP register to set the period in periodic mode.

With this patch HPET_COUNTER is still stopped but not reset when HPET
is programmed in periodic mode. This should help to avoid races when
HPET is programmed in periodic mode and fixes a boot time hang that
I've observed on a machine when using 1000HZ.

[ Impact: fix boot time hang on machines with AMD 81xx chipset ]

Reported-by: Jeff Mahoney 
Signed-off-by: Andreas Herrmann 
Tested-by: Jeff Mahoney 
LKML-Reference: <20090421180037.GA2763@alberich.amd.com>
Signed-off-by: Ingo Molnar 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86: hpet: stop HPET_COUNTER when programming periodic mode

2009-06-15T16:40:21+00:00

commit c23e253e67c9d8a91a0ffa33c1f571a17f0a2403 upstream

x86: hpet: stop HPET_COUNTER when programming periodic mode

Impact: fix system hang on some systems operating with HZ_1000

On a system that stalled with HZ_1000, the first value written to
T0_CMP (when the main counter was not stopped) did not trigger an
interrupt. Instead after the main counter wrapped around (after
several minutes) an interrupt was triggered and afterwards the
periodic interrupt took effect.

This can be fixed by implementing HPET spec recommendation for
programming the periodic mode (i.e. stopping the main counter).

[cebbert@redhat.com: backport to 2.6.29]

Signed-off-by: Andreas Herrmann 
Cc: Mark Hounschell 
Cc: Borislav Petkov 
Signed-off-by: Ingo Molnar 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

x86: hpet: provide separate functions to stop and start the counter

2009-06-15T16:40:20+00:00

commit 8d6f0c8214928f7c5083dd54ecb69c5d615b516e upstream.

By splitting up existing hpet_start_counter function.

Signed-off-by: Andreas Herrmann 
Cc: Mark Hounschell 
Cc: Borislav Petkov 
Signed-off-by: Ingo Molnar 
Cc: Chuck Ebbert 
Signed-off-by: Greg Kroah-Hartman

powerpc: fix for long standing bug noticed by gcc 4.4.0

2009-06-15T16:40:15+00:00

commit b62c31ae401c6df25c61b206681a6e904ef97169 upstream.

Previous gcc versions didn't notice this because one of the preceding
#ifs always evaluated to true.

gcc 4.4.0 produced this error:

arch/powerpc/mm/tlb_nohash_low.S:206:6: error: #elif with no expression

Signed-off-by: Stephen Rothwell 
Acked-by: Josh Boyer 
Signed-off-by: Kumar Gala 
Signed-off-by: Greg Kroah-Hartman

x86/pci: fix mmconfig detection with 32bit near 4g

2009-06-15T16:40:05+00:00

commit 75e613cdc7bb2ba3795b1bc3ddf19476c767ba68 upstream.

Pascal reported and bisected a commit:
|	x86/PCI: don't call e820_all_mapped with -1 in the mmconfig case

which broke one system system.

ACPI: Using IOAPIC for interrupt routing
PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 255
PCI: MCFG area at f0000000 reserved in ACPI motherboard resources
PCI: Using MMCONFIG for extended config space

it didn't have
PCI: updated MCFG configuration 0: base f0000000 segment 0 buses 0 - 63
anymore, and try to use 0xf000000 - 0xffffffff for mmconfig

For 32bit, mcfg_res->end could be 32bit only (if 64 resources aren't used)
So use end - 1 to pass the value in mcfg->end to avoid overflow.

We don't need to worry about the e820 path, they are always 64 bit.

Reported-by: Pascal Terjan 
Bisected-by: Pascal Terjan 
Tested-by: Pascal Terjan 
Signed-off-by: Yinghai Lu 
Signed-off-by: Jesse Barnes 
Signed-off-by: Greg Kroah-Hartman

x86: ignore VM_LOCKED when determining if hugetlb-backed page tables can be shared or not

2009-06-15T16:40:03+00:00

commit 32b154c0b0bae2879bf4e549d861caf1759a3546 upstream.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13302

On x86 and x86-64, it is possible that page tables are shared beween
shared mappings backed by hugetlbfs.  As part of this,
page_table_shareable() checks a pair of vma->vm_flags and they must match
if they are to be shared.  All VMA flags are taken into account, including
VM_LOCKED.

The problem is that VM_LOCKED is cleared on fork().  When a process with a
shared memory segment forks() to exec() a helper, there will be shared
VMAs with different flags.  The impact is that the shared segment is
sometimes considered shareable and other times not, depending on what
process is checking.

What happens is that the segment page tables are being shared but the
count is inaccurate depending on the ordering of events.  As the page
tables are freed with put_page(), bad pmd's are found when some of the
children exit.  The hugepage counters also get corrupted and the Total and
Free count will no longer match even when all the hugepage-backed regions
are freed.  This requires a reboot of the machine to "fix".

This patch addresses the problem by comparing all flags except VM_LOCKED
when deciding if pagetables should be shared or not for hugetlbfs-backed
mapping.

Signed-off-by: Mel Gorman 
Acked-by: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Lee Schermerhorn 
Cc: KOSAKI Motohiro 
Cc: 
Cc: Eric B Munson 
Cc: Adam Litke 
Cc: Andy Whitcroft 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

KVM: Fix PDPTR reloading on CR4 writes

2009-06-15T16:40:01+00:00

commit a2edf57f510cce6a389cc14e58c6ad0a4296d6f9 upstream.

The processor is documented to reload the PDPTRs while in PAE mode if any
of the CR4 bits PSE, PGE, or PAE change.  Linux relies on this
behaviour when zapping the low mappings of PAE kernels during boot.

The code already handled changes to CR4.PAE; augment it to also notice changes
to PSE and PGE.

This triggered while booting an F11 PAE kernel; the futex initialization code
runs before any CR3 reloads and writes to a NULL pointer; the futex subsystem
ended up uninitialized, killing PI futexes and pulseaudio which uses them.

Signed-off-by: Avi Kivity 
Signed-off-by: Greg Kroah-Hartman