linux-stable.git/arch, branch v3.9.9

powerpc/eeh: Fix fetching bus for single-dev-PE

2013-07-03T17:55:23+00:00

commit ea461abf61753b4b79e625a7c20650105b990f21 upstream.

While running Linux as guest on top of phyp, we possiblly have
PE that includes single PCI device. However, we didn't return
its PCI bus correctly and it leads to failure on recovery from
EEH errors for single-dev-PE. The patch fixes the issue.

Signed-off-by: Gavin Shan 
Cc: Steve Best 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

iommu/vt-d: add quirk for broken interrupt remapping on 55XX chipsets

2013-07-03T17:55:22+00:00

commit 03bbcb2e7e292838bb0244f5a7816d194c911d62 upstream.

A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf

For the 5520 and 5500 chipsets which contained an errata (specificially errata
53), which noted that these chipsets can't properly do interrupt remapping, and
as a result the recommend that interrupt remapping be disabled in bios.  While
many vendors have a bios update to do exactly that, not all do, and of course
not all users update their bios to a level that corrects the problem.  As a
result, occasionally interrupts can arrive at a cpu even after affinity for that
interrupt has be moved, leading to lost or spurrious interrupts (usually
characterized by the message:
kernel: do_IRQ: 7.71 No irq handler for vector (irq -1)

There have been several incidents recently of people seeing this error, and
investigation has shown that they have system for which their BIOS level is such
that this feature was not properly turned off.  As such, it would be good to
give them a reminder that their systems are vulnurable to this problem.  For
details of those that reported the problem, please see:
https://bugzilla.redhat.com/show_bug.cgi?id=887006

[ Joerg: Removed CONFIG_IRQ_REMAP ifdef from early-quirks.c ]

Signed-off-by: Neil Horman 
CC: Prarit Bhargava 
CC: Don Zickus 
CC: Don Dutile 
CC: Bjorn Helgaas 
CC: Asit Mallick 
CC: David Woodhouse 
CC: linux-pci@vger.kernel.org
CC: Joerg Roedel 
CC: Konrad Rzeszutek Wilk 
CC: Arkadiusz Miśkiewicz 
Signed-off-by: Joerg Roedel 
Signed-off-by: Greg Kroah-Hartman

s390/irq: Only define synchronize_irq() on SMP

2013-07-03T17:55:21+00:00

commit 690cec8e70c211d1f5f6e520b21a68d0306173b6 upstream.

In uniprocessor configurations, synchronize_irq() is defined in
 as a macro, and this function definition fails to
compile.

Reported-by: kbuild test robot 
Signed-off-by: Ben Hutchings 
Signed-off-by: Heiko Carstens 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

s390/pci: Implement IRQ functions if !PCI

2013-07-03T17:55:21+00:00

commit c46b54f7406780ec4cf9c9124d1cfb777674dc70 upstream.

All architectures must implement IRQ functions.  Since various
dependencies on !S390 were removed, there are various drivers that can
be selected but will fail to link.  Provide a dummy implementation of
these functions for the !PCI case.

Signed-off-by: Ben Hutchings 
Acked-by: David S. Miller 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

ARM: 7772/1: Fix missing flush_kernel_dcache_page() for noMMU

2013-07-03T17:55:20+00:00

commit 63384fd0b1509acf522a8a8fcede09087eedb7df upstream.

Commit 1bc3974 (ARM: 7755/1: handle user space mapped pages in
flush_kernel_dcache_page) moved the implementation of
flush_kernel_dcache_page() into mm/flush.c but did not implement it
on noMMU ARM.

Signed-off-by: Simon Baatz 
Acked-by: Kevin Hilman 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

ARM: 7755/1: handle user space mapped pages in flush_kernel_dcache_page

2013-07-03T17:55:20+00:00

commit 1bc39742aab09248169ef9d3727c9def3528b3f3 upstream.

Commit f8b63c1 made flush_kernel_dcache_page a no-op assuming that
the pages it needs to handle are kernel mapped only.  However, for
example when doing direct I/O, pages with user space mappings may
occur.

Thus, continue to do lazy flushing if there are no user space
mappings.  Otherwise, flush the kernel cache lines directly.

Signed-off-by: Simon Baatz 
Reviewed-by: Catalin Marinas 
Signed-off-by: Russell King 
Signed-off-by: Greg Kroah-Hartman

s390/ipl: Fix FCP WWPN and LUN format strings for read

2013-07-03T17:55:19+00:00

commit eda4ddf7e3a2245888e8c45c566fd514cdd5abbb upstream.

The following git commit changed the behavior of sscanf:

commit 53809751ac230a3611b5cdd375f3389f3207d471
Author: Jan Beulich 
Date:   Mon Dec 17 16:01:31 2012 -0800
    sscanf: don't ignore field widths for numeric conversions

This broke the WWPN and LUN sysfs attributes for s390 reipl and dump
on panic.

Example:

$ echo 0x0123456701234567 > /sys/firmware/reipl/fcp/wwpn
$ cat /sys/firmware/reipl/fcp/wwpn
0x0001234567012345

So fix this and use format strings that work also with the
new sscanf implementation:

$ echo 0x012345670123456789 > /sys/firmware/reipl/fcp/wwpn
$ cat /sys/firmware/reipl/fcp/wwpn
0x0123456701234567

Reviewed-by: Steffen Maier 
Signed-off-by: Michael Holzheu 
Signed-off-by: Martin Schwidefsky 
Signed-off-by: Greg Kroah-Hartman

x86: Fix section mismatch on load_ucode_ap

2013-06-27T17:38:46+00:00

commit 949785996ec2250fa958fc3a924e5186e9a8fa2c upstream.

We are in the process of removing all the __cpuinit annotations.
While working on making that change, an existing problem was
made evident:

  WARNING: arch/x86/kernel/built-in.o(.text+0x198f2): Section mismatch
  in reference from the function cpu_init() to the function
  .init.text:load_ucode_ap()   The function cpu_init() references
  the function __init load_ucode_ap().  This is often because cpu_init
  lacks a __init annotation or the annotation of load_ucode_ap is wrong.

This now appears because in my working tree, cpu_init() is no longer
tagged as __cpuinit, and so the audit picks up the mismatch.  The 2nd
hypothesis from the audit is the correct one, as there was an incorrect
__init tag on the prototype in the header (but __cpuinit was used on
the function itself.)

The audit is telling us that the prototype's __init annotation took
effect and the function did land in the .init.text section.  Checking
with objdump on a mainline tree that still has __cpuinit shows that
the __cpuinit on the function takes precedence over the __init on the
prototype, but that won't be true once we make __cpuinit a no-op.

Even though we are removing __cpuinit, we temporarily align both
the function and the prototype on __cpuinit so that the changeset
can be applied to stable trees  if desired.

[ hpa: build fix only, no object code change ]

Signed-off-by: Paul Gortmaker 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Link: http://lkml.kernel.org/r/1371654926-11729-1-git-send-email-paul.gortmaker@windriver.com
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86: fix build error and kconfig for ia32_emulation and binfmt

2013-06-27T17:38:46+00:00

commit d1603990ea626668c78527376d9ec084d634202d upstream.

Fix kconfig warning and build errors on x86_64 by selecting BINFMT_ELF
when COMPAT_BINFMT_ELF is being selected.

warning: (IA32_EMULATION) selects COMPAT_BINFMT_ELF which has unmet direct dependencies (COMPAT && BINFMT_ELF)

fs/built-in.o: In function `elf_core_dump':
compat_binfmt_elf.c:(.text+0x3e093): undefined reference to `elf_core_extra_phdrs'
compat_binfmt_elf.c:(.text+0x3ebcd): undefined reference to `elf_core_extra_data_size'
compat_binfmt_elf.c:(.text+0x3eddd): undefined reference to `elf_core_write_extra_phdrs'
compat_binfmt_elf.c:(.text+0x3f004): undefined reference to `elf_core_write_extra_data'

[ hpa: This was sent to me for -next but it is a low risk build fix ]

Signed-off-by: Randy Dunlap 
Link: http://lkml.kernel.org/r/51C0B614.5000708@infradead.org
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

x86, mtrr: Fix original mtrr range get for mtrr_cleanup

2013-06-27T17:38:46+00:00

commit d8d386c10630d8f7837700f4c466443d49e12cc0 upstream.

Joshua reported: Commit cd7b304dfaf1 (x86, range: fix missing merge
during add range) broke mtrr cleanup on his setup in 3.9.5.
corresponding commit in upstream is fbe06b7bae7c.

  *BAD*gran_size: 64K chunk_size: 16M num_reg: 6 lose cover RAM: -0G

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

So it rejects new var mtrr layout.

It turns out we have some problem with initial mtrr range retrieval.
The current sequence is:
	x86_get_mtrr_mem_range
		==> bunchs of add_range_with_merge
		==> bunchs of subract_range
		==> clean_sort_range
	add_range_with_merge for [0,1M)
	sort_range()

add_range_with_merge could have blank slots, so we can not just
sort only, that will have final result have extra blank slot in head.

So move that calling add_range_with_merge for [0,1M), with that we
could avoid extra clean_sort_range calling.

Reported-by: Joshua Covington 
Tested-by: Joshua Covington 
Signed-off-by: Yinghai Lu 
Link: http://lkml.kernel.org/r/1371154622-8929-2-git-send-email-yinghai@kernel.org
Signed-off-by: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman