Stress-testing KVM's latest NMI support with kgdbts inside an SMP guest,
I came across spurious unhandled NMIs while running the singlestep test.
Looking closer at the code path each NMI takes when KGDB is enabled, I
noticed that kgdb_nmicallback is called twice per event: One time via
DIE_NMI_IPI notification, the second time on DIE_NMI. Removing the first
invocation cures the unhandled NMIs here.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

There is a bug in the BIOSes of some HP boxes with AMD Turions which
connects IO-APIC pins with ACPI thermal trip points in such a way that
if the state of the IO-APIC is not as expected by the (buggy) BIOS, the
thermal trip points are set to insanely low values (usually all of them
become 16 degrees Celsius).  As a result, thermal throttling kicks in
and knock the system down to its shoes.

Unfortunately some of the recent IO-APIC changes made the bug show up.
To prevent this from happening, blacklist machines that are known to be
affected (nx6115 and 6715b in this particular case).

This fixes http://bugzilla.kernel.org/show_bug.cgi?id=11516 listed as
a regression from 2.6.26.

On my box it was caused by:

commit 691874fa
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date:   Tue May 27 21:19:51 2008 +0100

    x86: I/O APIC: timer through 8259A second-chance
Signed-off-by: NMaciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

and the whole story is described in this (huge) thread:

    http://marc.info/?l=linux-kernel&m=121358440508410&w=4

Matthew Garrett told us about that happening on the nx6125:

    http://marc.info/?l=linux-kernel&m=121396307411930&w=4

and then Maciej analysed the breakage on the basis of a DSDT from the
nx6325:

    http://marc.info/?l=linux-kernel&m=121401068718826&w=4

As far as the Dmitry's and Jason's boxes are concerned, I recognized the
symptoms and asked them to verify that the blacklisting helped.

It appears that the buggy BIOS code has been copy-pasted to the entire
range of machines, for no good reason.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Tested-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Tested-by: NJason Vas Dias <jason.vas.dias@gmail.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Because sync-r4k.c doesn't build.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The Swarm IDE driver uses a release method which is defined in the driver
itself thus potentially oopsable.  The simple fix would be to just leak
the device but this patch goes the full length and moves the entire
handling of the platform device in the platform code and retains only
the platform driver code in drivers/ide/mips/swarm.c.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>
Acked-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
[bart: remove no longer needed BLK_DEV_IDE_SWARM from ide/Kconfig]
Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>

move init_memory_mapping() out of init_k8_gatt.

for: http://bugzilla.kernel.org/show_bug.cgi?id=11676
    2.6.27-rc2 to rc8, apgart fails, iommu=soft works, regression

This is needed because we need to map the GART aperture even
if the GATT is not initialized.
Signed-off-by: NYinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Impact: segfault on build of a 32-bit relocatable kernel

When converting arch/x86/boot/compressed/relocs.c to support unlimited
sections, the computation of sym_strtab in walk_relocs() was done
incorrectly.  This causes a segfault for some people when building the
relocatable 32-bit kernel.

Pointed out by Anonymous <pageexec@freemail.hu>.
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

This fixes a regression that came with 934b2857
("[S390] nohz/sclp: disable timer on synchronous waits.").
If udelay() gets called from a disabled context it sets the clock comparator
to a value where it expects the next interrupt. When the interrupt happens
the clock comparator gets not reset and therefore the interrupt condition
doesn't get cleared. The result is an endless timer interrupt loop.

In addition this patch fixes also the following:

rcutorture reveals that our __udelay implementation is still buggy,
since it might schedule tasklets, but prevents their execution:

NOHZ: local_softirq_pending 42
NOHZ: local_softirq_pending 02
NOHZ: local_softirq_pending 142
NOHZ: local_softirq_pending 02

To fix this we make sure that only the clock comparator interrupt
is enabled when the enabled wait psw is loaded.
Also no code gets called anymore which might schedule tasklets.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Rework of SMTC support to make it work with the new clock event system,
allowing "tickless" operation, and to make it compatible with the use of
the "wait_irqoff" idle loop.  The new clocking scheme means that the
previously optional IPI instant replay mechanism is now required, and has
been made more robust.
Signed-off-by: NKevin D. Kissell <kevink@paralogos.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NKevin D. Kissell <kevink@paralogos.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NKevin D. Kissell <kevink@paralogos.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Though from a hardware perspective it would be sensible to use only a
32-bit unsigned int type Linux defines interrupt flags to be stored in
an unsigned long and nothing else.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Commit 00c5372d caused the MPC8544DS
board to hang at boot.  The MPC8544DS is unique in that it doesn't use
the PCI slots on the ULI (unlike the MPC8572DS or MPC8610HPCD).  So
the dummy read at the end of the address space causes us to hang.

We can detect the situation by comparing the bridge's BARs versus
the root complex.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Fix the IRQ handling on the MN10300 arch.

This patch makes a number of significant changes:

 (1) It separates the irq_chip definition for edge-triggered interrupts from
     the one for level-triggered interrupts.

     This is necessary because the MN10300 PIC latches the IRQ channel's
     interrupt request bit (GxICR_REQUEST), even after the device has ceased to
     assert its interrupt line and the interrupt channel has been disabled in
     the PIC.  So for level-triggered interrupts we need to clear this bit when
     we re-enable - which is achieved by setting GxICR_DETECT but not
     GxICR_REQUEST when writing to the register.

     Not doing this results in spurious interrupts occurring because calling
     mask_ack() at the start of handle_level_irq() is insufficient - it fails
     to clear the REQUEST latch because the device that caused the interrupt is
     still asserting its interrupt line at this point.

 (2) IRQ disablement [irq_chip::disable_irq()] shouldn't clear the interrupt
     request flag for edge-triggered interrupts lest it lose an interrupt.

 (3) IRQ unmasking [irq_chip::unmask_irq()] also shouldn't clear the interrupt
     request flag for edge-triggered interrupts lest it lose an interrupt.

 (4) The end() operation is now left to the default (no-operation) as
     __do_IRQ() is compiled out.  This may affect misrouted_irq(), but
     according to Thomas Gleixner it's the correct thing to do.

 (5) handle_level_irq() is used for edge-triggered interrupts rather than
     handle_edge_irq() as the MN10300 PIC latches interrupt events even on
     masked IRQ channels, thus rendering IRQ_PENDING unnecessary.  It is
     sufficient to call mask_ack() at the start and unmask() at the end.

 (6) For level-triggered interrupts, ack() is now NULL as it's not used, and
     there is no effective ACK function on the PIC.  mask_ack() is now the
     same as mask() as the latch continues to latch, even when the channel is
     masked.

Further, the patch discards the disable() op implementation as its now the same
as the mask() op implementation, which is used instead.

It also discards the enable() op implementations as they're now the same as
the unmask() op implementations, which are used instead.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This one took a long time to rear up because LDT usage is not very
common, but the bug is quite serious.  It got introduced along with
another bug, already fixed, by 75b8bb3e

After investigating a JRE failure, I found this bug was introduced a long time
ago, and had already managed to survive another bugfix which occurred on the
same line.  The result is a total failure of the JRE due to LDT selectors not
working properly.
Signed-off-by: NZachary Amsden <zach@vmware.com>
Cc: Glauber de Oliveira Costa <gcosta@redhat.com>
Cc: stable@kernel.org
Signed-off-by: NIngo Molnar <mingo@elte.hu>

After investigating a JRE failure, I found this bug was introduced a
long time ago, and had already managed to survive another bugfix which
occurred on the same line.  The result is a total failure of the JRE due
to LDT selectors not working properly.

This one took a long time to rear up because LDT usage is not very
common, but the bug is quite serious.  It got introduced along with
another bug, already fixed, by 75b8bb3eSigned-off-by: NZachary Amsden <zach@vmware.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Glauber de Oliveira Costa <gcosta@redhat.com>
Cc: <stable@kernel.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Correct typo for 'enable_mtrr_cleanup' early boot param name.
Signed-off-by: NJ.A. Magallon <jamagallon@ono.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

I tracked down the shutdown regression to CPUs not dying
when being shut down during power-off. This turns out to
be due to the system_state being SYSTEM_POWER_OFF, which
this code doesn't take as a valid state for shutting off
CPUs in.

This has never made sense to me, but when I added hotplug
code to implement hibernate I only "made it work" and did
not question the need to check the system_state. Thomas
Gleixner helped me dig, but the only thing we found is
that it was added with the original commit that added CPU
hotplug support.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NJoel Schopp <jschopp@austin.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The PCI bridge on the Holly board is incorrectly represented in the
device tree.  The current device tree node for the PCI bridge sits
under the tsi-bridge node.  That's not obviously wrong, but the PCI
bridge translates some PCI spaces into CPU address ranges which were
not translated by the "ranges" property in tsi-bridge node.

We used to get away with this problem because the PCI bridge discovery
code was also buggy, assuming incorrectly that PCI host bridge nodes
were always directly under the root bus and treating the translated
addresses as raw CPU addresses, rather than parent bus addresses.
This has since been fixed, thus breaking Holly.

This could be fixed by adding extra translations to the tsi-bridge
node, but this patch instead moves the Holly PCI bridge out of the
tsi-bridge node to the root bus.  This makes the tsi-bridge node
represent only the built-in IO devices in the bridge, with a
more-or-less contiguous address range.  This is the same convention
used on Freescale SoC chips, where the "soc" node represents only the
IMMR region, and the PCI and other bus bridges are separate nodes
under the root bus.
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
Acked-by: NJosh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Initial fix for making sure that we can access percpu variables
in all C code (commit: 10617bbe)
inadvertantly allocated the memory in the "percpu" section of
the vmlinux ELF executable.  This confused kexec/dump.
Signed-off-by: NTony Luck <tony.luck@intel.com>

This patch defines pcibios_map_irq() and pcibios_plat_dev_init() for
the BCM47xx platform.

It fixes the regression introduced by commit
aab547ce.
Signed-off-by: NAurelien Jarno <aurelien@aurel32.net>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

pcibios_map_irq is no way of returning an error but on IP27 an interrupt
is possibly not routable when running out of resources.  So do the
interrupt routing at pcibios_enable_device time.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

David Brownell <david-b@pacbell.net> wrote:
>       The problem is that "value" is zero-or-nonzero.
>       This code wrongly assumes it's zero-or-one.
>       Possible fix:  "((!!value) << gpio)".
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This patch contains the following cleanups:
- make the following needlessly global code static:
  - entry.S: resume_userspace
  - process.c: pm_idle
  - process.c: default_idle()
  - smp.c: send_IPI_allbutself()
  - time.c: timer_interrupt()
  - time.c: struct irq0
  - traps.c: set_eit_vector_entries()
  - traps.c: kstack_depth_to_print
  - traps.c: show_trace()
  - traps.c: die_lock
- remove the following unused code:
  - head.S: startup_32
  - process.c: hlt_counter
  - process.c: disable_hlt()
  - process.c: enable_hlt()
  - process.c: dump_task_regs()
- remove the following variables and their usages since they were
  always 0:
  - irq.c: irq_err_count
  - irq.c: irq_mis_count
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>

ERROR: "__ndelay" [drivers/spi/spi_bitbang.ko] undefined!
Reported-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>

ERROR: "empty_zero_page" [fs/ext4/ext4dev.ko] undefined!
Reported-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>

As far as I know no M32R hardware actually has ISA slots.

And ISA drivers don't compile on M32R.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>

Remove the unused NOHIGHMEM option.
Reviewed-by: NRobert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NHirokazu Takata <takata@linux-m32r.org>

Delete ARM's own cnt32_to_63.h as the copy in include/linux/ should now be
used instead.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

On x86_64 the gdb serial register structure defines the PS (also known
as eflags), CS and SS registers as 4 bytes entities.

This patch splits the x86_64 regnames enum into a 32 and 64 version to
account for the 32 bit entities in the gdb serial packets.

Also the program counter is properly filled in for the sleeping
threads.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

On the x86 arch, user space single step exceptions should be ignored
if they occur in the kernel space, such as ptrace stepping through a
system call.

First check if it is kgdb that is executing a single step, then ensure
it is not an accidental traversal into the user space, while in kgdb,
any other time the TIF_SINGLESTEP is set, kgdb should ignore the
exception.

On x86, arm, mips and powerpc, the kgdb_contthread usage was
inconsistent with the way single stepping is implemented in the kgdb
core.  The arch specific stub should always set the
kgdb_cpu_doing_single_step correctly if it is single stepping.  This
allows kgdb to correctly process an instruction steps if ptrace
happens to be requesting an instruction step over a system call.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

Make sched_clock() report time since boot rather than time since last
timer interrupt.

Make sched_clock() expand and scale the 32-bit TSC value running at
IOCLK speed (~33MHz) to a 64-bit nanosecond counter, using cnt32_to_63()
acquired from the ARM arch and without using slow DIVU instructions
every call.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Move asm-arm/cnt32_to_63.h to include/linux/ so that MN10300 can make
use of it too.
Signed-off-by: NDavid Howells <dhowells@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The OLPC doesn't support APM but also doesn't have DMI, so we can't detect
and disable it based on DMI data.  So, just disable based on machine_is_olpc()
Signed-off-by: NJeremy Katz <katzj@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

Fix build error introduced by commit 4faac97d ("x86: prevent stale
state of c1e_mask across CPU offline/online").

process_32.c needs to include idle.h to get the prototype for
c1e_remove_cpu()
Signed-off-by: NMarc Dionne <marc.c.dionne@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

When setting the direction of one GPIO pin we have to keep the state of the
other pins, hence use binary OR. Also gpio_direction_output() wants to set an
initial value, so add that too.

This fixes a problem with the USB power switch on mtx-1 boards.
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Impact: Functional TSC is marked unstable on AMD family 0x10 and 0x11 CPUs.

This would be wrong because for those CPUs "invariant TSC" means:

   "The TSC counts at the same rate in all P-states, all C states, S0,
   or S1"

(See "Processor BIOS and Kernel Developer's Guides" for those CPUs.)

[ tglx: Changed C1E to AMD C1E in the printks to avoid confusion 
	with Intel C1E ]
Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Impact: System hang when AMD C1E machines switch into C2/C3

AMD C1E enabled systems do not work with normal ACPI C-states 
even if the BIOS is advertising them. Limit the C-states to 
C1 for the ACPI processor idle code.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Impact: hang which happens across CPU offline/online on AMD C1E systems.

When a CPU goes offline then the corresponding bit in the broadcast
mask is cleared. For AMD C1E enabled CPUs we do not reenable the
broadcast when the CPU comes online again as we do not clear the
corresponding bit in the c1e_mask, which keeps track which CPUs
have been switched to broadcast already. So on those !$@#& machines
we never switch back to broadcasting after a CPU offline/online cycle.

Clear the bit when the CPU plays dead.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>