When using 64k page sizes, our PTE pages are split in two halves,
the second half containing the "extension" used to keep track of
individual 4k pages when not using HW 64k pages.

However, our page tables used for hugetlb have a slightly different
format and don't carry that "second half".

Our code that batched PTEs to be invalidated unconditionally reads
the "second half" (to put it into the batch), which means that when
called to invalidate hugetlb PTEs, it will access unrelated memory.

It breaks when CONFIG_DEBUG_PAGEALLOC is enabled.

This fixes it by only accessing the second half when the _PAGE_COMBO
bit is set in the first half, which indicates that we are dealing with
a "combo" page which represents 16x4k subpages. Anything else shouldn't
have this bit set and thus not require loading from the second half.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The function udbg_44x_as1_flush() has the wrong prototype causing
a warning when enabling 440 early debug.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

dev_set_name() takes a format string, so use it properly and avoid
a warning with recent gcc's
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

spin_lock() can hang if called while the timebase is frozen,
so use a raw lock instead, also disable interrupts while
at it.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Several platforms use their own copy of what is essentially the same code,
using RTAS to synchronize the timebases when bringing up new CPUs. This
moves it all into a single common implementation and additionally
turns the spinlock into a raw spinlock since the former can rely on
the timebase not being frozen when spinlock debugging is enabled, and finally
masks interrupts while the timebase is disabled.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

RTAS currently uses a normal spinlock. However it can be called from
contexts where this is not necessarily a good idea. For example, it
can be called while syncing timebases, with the core timebase being
frozen. Unfortunately, that will deadlock in case of lock contention
when spinlock debugging is enabled as the spin lock debugging code
will try to use __delay() which ... relies on the timebase being
enabled.

Also RTAS can be used in some low level IRQ handling code path so it
may as well be a raw spinlock for -rt sake.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Based on initial work from: Dale Farnsworth <dale@farnsworth.org>

Add the low level irq tracing hooks for 32-bit powerpc needed
to enable full lockdep functionality.

The approach taken to deal with the code in entry_32.S is that
we don't trace all the transitions of MSR:EE when we just turn
it off to peek at TI_FLAGS without races. Only when we are
calling into C code or returning from exceptions with a state
that have changed from what lockdep thinks.

There's a little bugger though: If we take an exception that
keeps interrupts enabled (such as an alignment exception) while
interrupts are enabled, we will call trace_hardirqs_on() on the
way back spurriously. Not a big deal, but to get rid of it would
require remembering in pt_regs that the exception was one of the
type that kept interrupts enabled which we don't know at this
stage. (Well, we could test all cases for regs->trap but that
sucks too much).
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Tested-by: NKumar Gala <galak@kernel.crashing.org>

The 32-bit kernel relies on some memory being mapped covering
the kernel text,data and bss at least, early during boot before
the full MMU setup is done. On 32-bit "classic" processors, this
is done using BAT registers.

On 601, the size of BATs is limited to 8M and we use 2 of them
for that initial mapping. This can become quite tight when enabling
features like lockdep, so let's use a 3rd one to bump that mapping
from 16M to 24M. We keep the 4th BAT free as it can be useful for
debugging early boot code to map things like serial ports.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Those functions are way too big to be inline, besides, kmap_atomic()
wants to call debug_kmap_atomic() which isn't exported for modules
and causes module link failures.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Since we can use kmalloc earlier we are getting the following since the
mpic_alloc() code calls alloc_bootmem().  Move to using kzalloc() to
remove the warning.

------------[ cut here ]------------
Badness at c0583248 [verbose debug info unavailable]
NIP: c0583248 LR: c0583210 CTR: 00000004
REGS: c0741de0 TRAP: 0700   Not tainted  (2.6.30-06736-g12a31df)
MSR: 00021000 <ME,CE>  CR: 22024024  XER: 00000000
TASK = c070d3b8[0] 'swapper' THREAD: c0740000 CPU: 0
<6>GPR00: 00000001 c0741e90 c070d3b8 00000001 00000210 00000020 3fffffff 00000000
<6>GPR08: 00000000 c0c85700 c04f8c40 0000002d 22044022 1004a388 7ffd9400 00000000
<6>GPR16: 00000000 7ffcd100 7ffcd100 7ffcd100 c04f8c40 00000000 c059f62c c075a0c0
<6>GPR24: c059f648 00000000 0000000f 00000210 00000020 00000000 3fffffff 00000210
NIP [c0583248] alloc_arch_preferred_bootmem+0x50/0x80
LR [c0583210] alloc_arch_preferred_bootmem+0x18/0x80
Call Trace:
[c0741e90] [c07343b0] devtree_lock+0x0/0x24 (unreliable)
[c0741ea0] [c0583b14] ___alloc_bootmem_nopanic+0x54/0x108
[c0741ee0] [c0583e18] ___alloc_bootmem+0x18/0x50
[c0741ef0] [c057b9cc] mpic_alloc+0x48/0x710
[c0741f40] [c057ecf4] mpc85xx_ds_pic_init+0x190/0x1b8
[c0741f90] [c057633c] init_IRQ+0x24/0x34
[c0741fa0] [c05738b8] start_kernel+0x260/0x3dc
[c0741ff0] [c00003c8] skpinv+0x2e0/0x31c
Instruction dump:
409e001c 7c030378 80010014 83e1000c 38210010 7c0803a6 4e800020 3d20c0c8
39295700 80090004 7c000034 5400d97e <0f000000> 2f800000 409e001c 38800000

BenH: Changed to use GFP_KERNEL, the allocator will do the right thing
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

For some reason we've had an explicit KERN_INFO for GPR dumps.  With
recent changes we get output like:

<6>GPR00: 00000000 ef855eb0 ef858000 00000001 000000d0 f1000000 ffbc8000 ffffffff

The KERN_INFO is causing the <6>.  Don't see any reason to keep it
around.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The old PowerSurge SMP (ie, dual or quad 604 machines) code has
numerous issues in modern world.

One is cpu_possible_map is set too late (the device-tree is bogus)
so we fail to allocate the interrupt stacks and crash. Another
problem is the fact the timebase is frozen by the bringup of the
second CPU so the delays in the generic code will hang, we need
to move some of the calling procedure to inside the powermac code.

This makes it boot again for me
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The kernel reserves the I/O address space from 0x0 to 0xfff for legacy
ISA devices. Change the ranges property for the PCI2ISA bridge to match
the kernels behavior, even if the ranges property isn't used for now.
Signed-off-by: NGerhard Pircher <gerhard_pircher@gmx.net>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

A change to the i2c subsystem breaks the warp platform code. The patch
is cleaner anyway, the old way was a bit crufty.

For those with keen eyes, the gratuitous change in the string from
PIKA to Warp is just so the logs look a bit nicer. The following two
lines tend to be printed one after another.

  Warp POST OK
  Warp DTM thread running.

Yeah, this will be the third patch to warp.c submitted in this
release....

Cheers,
   Sean

The i2c_client struct changed, breaking the code that looked for the ad7414
chip. Use the new of_find_i2c_device_by_node function added in 2.6.29.
Signed-off-by: NSean MacLennan <smaclennan@pikatech.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Have git ignore generated files from dtc compile
Signed-off-by: NJon Smirl <jonsmirl@gmail.com>
Acked-by: NDavid Gibson <david@gibson.dropbear.id.au>
Acked-by: NSean MacLennan <smaclennan@pikatech.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Commit 31207dab
"Fix incorrect allocation of interrupt rev-map"
introduced a regression crashing on boot on machines using
a "DCR" based MPIC, such as the Cell blades.

The reason is that the irq host data structure is initialized
much later as a result of that patch, causing our calls to
mpic_map() do be done before we have a host setup.

Unfortunately, this breaks _mpic_map_dcr() which uses the
mpic->irqhost to get to the device node.

This fixes it by, instead, passing the device node explicitely
to mpic_map().
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NAkira Tsukamoto <akirat@rd.scei.sony.co.jp>

Turning on SWIOTLB selects or enables PPC_NEED_DMA_SYNC_OPS, which means
we get the non empty versions of dma_sync_* in asm/dma-mapping.h

On my pseries machine the dma_ops have no such routines and we die with
a null pointer - this patch gets it booting, is there a more elegant way
to do it?
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The tftpboot build was failing with missing file errors.

It turns out that $(obj)/image wasn't being generated which was causing the a.out conversion to be skipped and hence piggyback to be called with nonexistent files.
Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Kjetil Oftedal mentioned that piggyback_32 was failing
when building a sparc image.

I tracked this down to the fact that the kernel no longer
provided an absolute symbol named "end".

Commit 86ed40bd ("sparc: unify sections.h")
renamed end to _end but failed to update piggyback_32.
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Cc: Kjetil Oftedal <oftedal@gmail.com>
Cc: Robert Reif <reif@earthlink.net>
Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NRobert Reif <reif@earthlink.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes the following build warnings:
arch/sparc/boot/piggyback_64.c: In function 'main':
arch/sparc/boot/piggyback_64.c:44: warning: 'end' may be used uninitialized in this function
arch/sparc/boot/piggyback_64.c:44: warning: 'start' may be used uninitialized in this function
Signed-off-by: NJulian Calaby <julian.calaby@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The page allocator and SLAB are available at this point now,
and if we still try to use bootmem allocations here the kernel
spits out warnings.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

delay_tsc needs rdtsc_barrier to provide proper delay.

Output from a test driver using hpet to cross check delay
provided by udelay().

Before:
[   86.794363] Expected delay 5us actual 4679ns
[   87.154362] Expected delay 5us actual 698ns
[   87.514162] Expected delay 5us actual 4539ns
[   88.653716] Expected delay 5us actual 4539ns
[   94.664106] Expected delay 10us actual 9638ns
[   95.049351] Expected delay 10us actual 10126ns
[   95.416110] Expected delay 10us actual 9568ns
[   95.799216] Expected delay 10us actual 9638ns
[  103.624104] Expected delay 10us actual 9707ns
[  104.020619] Expected delay 10us actual 768ns
[  104.419951] Expected delay 10us actual 9707ns

After:
[   50.983320] Expected delay 5us actual 5587ns
[   51.261807] Expected delay 5us actual 5587ns
[   51.565715] Expected delay 5us actual 5657ns
[   51.861171] Expected delay 5us actual 5587ns
[   52.164704] Expected delay 5us actual 5726ns
[   52.487457] Expected delay 5us actual 5657ns
[   52.789338] Expected delay 5us actual 5726ns
[   57.119680] Expected delay 10us actual 10755ns
[   57.893997] Expected delay 10us actual 10615ns
[   58.261287] Expected delay 10us actual 10755ns
[   58.620505] Expected delay 10us actual 10825ns
[   58.941035] Expected delay 10us actual 10755ns
[   59.320903] Expected delay 10us actual 10615ns
[   61.306311] Expected delay 10us actual 10755ns
[   61.520542] Expected delay 10us actual 10615ns
Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

<asm/boot.h> needs <asm/pgtable_types.h>, not <asm/page_types.h> in
order to resolve PMD_SHIFT.  Also, correct a +1 which really should be
+ THREAD_ORDER.

This is a build error which was masked by a typoed #ifdef.
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

CONFIG_X86_64 was misspelled (wrong case), which caused the x86-64
kernel to advertise itself as more relocatable than it really is.
This could in theory cause boot failures once bootloaders start
support the new relocation fields.
Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

If CONFIG_NO_HZ + CONFIG_SMP, timer added via add_timer() might
be migrated on other cpu.  Use add_timer_on() instead.

Avoids the following failure:

Maciej Rutecki wrote:
> > After normal boot I try:
> >
> > echo 1 > /sys/devices/system/machinecheck/machinecheck0/check_interval
> >
> > I found this in dmesg:
> >
> > [  141.704025] ------------[ cut here ]------------
> > [  141.704039] WARNING: at arch/x86/kernel/cpu/mcheck/mce.c:1102
> > mcheck_timer+0xf5/0x100()
Reported-by: NMaciej Rutecki <maciej.rutecki@gmail.com>
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Tested-by: NMaciej Rutecki <maciej.rutecki@gmail.com>
Acked-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>

This patch introduces a new sysctl:

    /proc/sys/kernel/panic_on_io_nmi

which defaults to 0 (off).

When enabled, the kernel panics when the kernel receives an NMI
caused by an IO error.

The IO error triggered NMI indicates a serious system
condition, which could result in IO data corruption. Rather
than contiuing, panicing and dumping might be a better choice,
so one can figure out what's causing the IO error.

This could be especially important to companies running IO
intensive applications where corruption must be avoided, e.g. a
bank's databases.

[ SuSE has been shipping it for a while, it was done at the
  request of a large database vendor, for their users. ]
Signed-off-by: NKurt Garloff <garloff@suse.de>
Signed-off-by: NRoberto Angelino <robertangelino@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
LKML-Reference: <20090624213211.GA11291@kroah.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

UML: Fix some apparent bitrot

- migration of net_device methods into net_device_ops
- dma_sync_single() changes
Signed-off-by: NPaul Menage <menage@google.com>
Acked-by: NAmerigo Wang <xiyou.wangcong@gmail.com>
--

This version is split from my earlier patch, including just the
portions that ar required for Linus' tree.

Fixes the following compile errors:

include/linux/dma-mapping.h:113: error: redefinition of 'dma_sync_single'
arch/um/include/asm/dma-mapping.h:84: error: previous definition of 'dma_sync_single' was here
include/linux/dma-mapping.h: In function 'dma_sync_single':
include/linux/dma-mapping.h:117: error: implicit declaration of function 'dma_sync_single_for_cpu'
include/linux/dma-mapping.h: At top level:
include/linux/dma-mapping.h:120: error: redefinition of 'dma_sync_sg'
arch/um/include/asm/dma-mapping.h:91: error: previous definition of 'dma_sync_sg' was here
include/linux/dma-mapping.h: In function 'dma_sync_sg':
include/linux/dma-mapping.h:124: error: implicit declaration of function 'dma_sync_sg_for_cpu'

arch/um/drivers/slirp_kern.c: In function 'slirp_init':
arch/um/drivers/slirp_kern.c:35: error: 'struct net_device' has no member named 'init'
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit 9e9f46c4.

Quoting from the commit message:

 "At this point, it seems to solve more problems than it causes, so let's
  try using it by default.  It's an easy revert if it ends up causing
  trouble."

And guess what? The _CRS code causes trouble.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Thanks to Cavium Inc. for the code contribution and help.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The SMP implementation of suspend and hibernate depends on CPU hotplugging.
In the past we didn't have CPU hotplug so suspend and hibernation were not
possible on SMP systems.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Each platform has to add support for CPU hotplugging itself by providing
suitable definitions for the cpu_disable and cpu_die of the smp_ops
methods and setting SYS_SUPPORTS_HOTPLUG_CPU.  A platform should only set
SYS_SUPPORTS_HOTPLUG_CPU once all it's smp_ops definitions have the
necessary changes.  This patch contains the changes to the dummy smp_ops
definition for uni-processor systems.

Parts of the code contributed by Cavium Inc.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This fixes kernel.org bugzilla 13596, see
http://bugzilla.kernel.org/show_bug.cgi?id=13596

Reported-by: dvice_null@yahoo.com
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

This fixes kernel.org bugzilla 13595, see
http://bugzilla.kernel.org/show_bug.cgi?id=13595

Reported-by: dvice_null@yahoo.com
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

We can't perform any flushes on SMP from swsusp_arch_resume because
interrupts are disabled.  A cross-CPU flush is unnecessary anyway
because all but the local CPU have already been disabled.  A local
flush is not needed either because we didn't change any mappings.  So
just delete the code.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Some of the were relying into smp.h being dragged in by another header
which of course is fragile.  <asm/cpu-info.h> uses smp_processor_id()
only in macros and including smp.h there leads to an include loop, so
don't change cpu-info.h.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

In the past this file somehow used to be dragged in.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

The initialization of the UV Broadcast Assist Unit's sending
buffers was making an invalid assumption about the
initialization of an MMR that defines its address.

The BIOS will not be providing that MMR.  So
uv_activation_descriptor_init() should unconditionally set it.

Tested on UV simulator.
Signed-off-by: NCliff Wickman <cpw@sgi.com>
Cc: <stable@kernel.org> # for v2.6.30.x
LKML-Reference: <E1MJTfj-0005i1-W8@eag09.americas.sgi.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>

To support domain-isolation usages, the platform hardware must be
capable of uniquely identifying the requestor (source-id) for each
interrupt message. Without source-id checking for interrupt remapping
, a rouge guest/VM with assigned devices can launch interrupt attacks
to bring down anothe guest/VM or the VMM itself.

This patch adds source-id checking for interrupt remapping, and then
really isolates interrupts for guests/VMs with assigned devices.

Because PCI subsystem is not initialized yet when set up IOAPIC
entries, use read_pci_config_byte to access PCI config space directly.
Signed-off-by: NWeidong Han <weidong.han@intel.com>
Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>