CONFIG_HOTPLUG_CPU=y:

WARNING: vmlinux.o(.text+0xfa52): Section mismatch: reference to .init.data:disable_pse (between 'identify_cpu' and 'identify_secondary_cpu')

[ akpm@linux-foundation.org: initializer fix. ]
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

CONFIG_HOTPLUG_CPU=y:

WARNING: vmlinux.o(.text+0x1199a): Section mismatch: reference to .init.text.5:select_idle_routine (between 'init_intel' and 'init_nexgen')
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

CONFIG_HOTPLUG_CPU=y:

WARNING: vmlinux.o(.text+0x22c60): Section mismatch: reference to .init.data:cpu_idle_tasks (between 'do_boot_cpu' and 'do_warm_boot_cpu')
WARNING: vmlinux.o(.text+0x22c99): Section mismatch: reference to .init.data:cpu_idle_tasks (between 'do_boot_cpu' and 'do_warm_boot_cpu')
WARNING: vmlinux.o(.text+0x2359b): Section mismatch: reference to .init.data:smp_b_stepping (between 'smp_store_cpu_info' and 'cpu_exit_clear')
WARNING: vmlinux.o(.text+0x235a0): Section mismatch: reference to .init.data:smp_b_stepping (between 'smp_store_cpu_info' and 'cpu_exit_clear')
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

CONFIG_HOTPLUG_CPU=y:

WARNING: vmlinux.o(.text+0x2390d): Section mismatch: reference to .init.text.5:setup_local_APIC (between 'start_secondary' and 'check_tsc_warp')
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Currently CMCI mask of hot-added CPU is always disabled after CPU hotplug.
We should adjust this mask depending on CMC polling state.
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NSatoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This fixes an unused variable warning in mm/vmalloc.c.

Tony: also fix resulting fallout in uncached.c with a
typo in args to flush_tlb_kernel_range().
Signed-off-by: NJan Beulich <jbeulich@novell.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Access to elfcorehdr_addr needs to be guarded by #if CONFIG_PROC_FS
as well as the existing #if guards.

Fixes the following build problem:

arch/ia64/hp/common/built-in.o: In function
`sba_init':arch/ia64/hp/common/sba_iommu.c:2043: undefined reference to `elfcorehdr_addr'
:arch/ia64/hp/common/sba_iommu.c:2043: undefined reference to `elfcorehdr_addr'
Signed-off-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The Altix shub2 BTE error detail bits are in a different location
than on shub1.  The current code does not take this into account
resulting in all shub2 BTE failures mapping to "unknown".

This patch reads the error detail bits from the proper location,
so the correct BTE failure reason is returned for both shub1
and shub2.
Signed-off-by: NRuss Anderson <rja@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This patch removes the following assembler warning messages.

  AS      arch/ia64/kernel/head.o
arch/ia64/kernel/head.S: Assembler messages:
arch/ia64/kernel/head.S:1179: Warning: Use of 'ld8' violates RAW dependency 'CR[PTA]' (data)
arch/ia64/kernel/head.S:1179: Warning: Only the first path encountering the conflict is reported
arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage
arch/ia64/kernel/head.S:1180: Warning: Use of 'ld8' violates RAW dependency 'CR[PTA]' (data)
arch/ia64/kernel/head.S:1180: Warning: Only the first path encountering the conflict is reported
arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage
 :
arch/ia64/kernel/head.S:1213: Warning: Use of 'ldf.fill.nta' violates RAW dependency 'CR[PTA]' (data)
arch/ia64/kernel/head.S:1213: Warning: Only the first path encountering the conflict is reported
arch/ia64/kernel/head.S:1178: Warning: This is the location of the conflicting usage
Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This patch removes the following compiler warning messages.

  CC      arch/ia64/kernel/irq_ia64.o
arch/ia64/kernel/irq_ia64.c: In function 'create_irq':
arch/ia64/kernel/irq_ia64.c:343: warning: 'domain.bits[0u]' may be used uninitialized in this function
arch/ia64/kernel/irq_ia64.c: In function 'assign_irq_vector':
arch/ia64/kernel/irq_ia64.c:203: warning: 'domain.bits[0u]' may be used uninitialized in this function
Signed-off-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

I tried to upgrade an IA32 chroot on my IA64 to a new glibc with TLS.
It kept dying because set_thread_area was returning -ESRCH
(bugs.debian.org/451939).

I instrumented arch/ia64/ia32/sys_ia32.c:get_free_idx() and ended up
seeing output like

[pid] idx   desc->a  desc->b
-----------------------------
[2710] 0 -> c6b0ffff 40dff31b
[2710] 1 -> 0 0
[2710] 2 -> 0 0

[2710] 0 -> c6b0ffff 40dff31b
[2710] 1 -> c6b0ffff 40dff31b
[2710] 2 -> 0 0

[2711] 0 -> c6b0ffff 40dff31b
[2711] 1 -> c6b0ffff 40dff31b
[2711] 2 -> 48c0ffff 40dff317

which suggested to me that TLS pointers were surviving exec() calls,
leading to GDT pointers filling up and the eventual failure of
get_free_idx().

I think the solution is flushing the tls array on exec.
Signed-Off-By: NIan Wienand <ianw@gelato.unsw.edu.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The ia64 oops message doesn't include the kernel version, which
makes it hard to automatically categorize oops messages scraped
from mailing lists and bug databases.
Signed-off-by: NTony Luck <tony.luck@intel.com>

s/addres/address/
s/performanc/performance/
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Improve performance of memory allocations on ia64 by avoiding a global TLB
purge to purge a single page from the file cache. This happens whenever we
evict a page from the buffer cache to make room for some other allocation.

Test case: Run 'find /usr -type f | xargs cat > /dev/null' in the
background to fill the buffer cache, then run something that uses memory,
e.g. 'gmake -j50 install'. Instrumentation showed that the number of
global TLB purges went from a few millions down to about 170 over a 12
hours run of the above.

The performance impact is particularly noticeable under virtualization,
because a virtual TLB is generally both larger and slower to purge than
a physical one.
Signed-off-by: NChristophe de Dinechin <ddd@hp.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Convert ia64's ia32 support from nopage to fault.
Signed-off-by: NNick Piggin <npiggin@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

This patch removes some redundant code in the function setup_sigcontext().

The registers ar.ccv,b7,r14,ar.csd,ar.ssd,r2-r3 and r16-r31 are not
restored in restore_sigcontext() when (flags & IA64_SC_FLAG_IN_SYSCALL) is
true.  So we don't need to zero those variables in setup_sigcontext().
Signed-off-by: NShi Weihua <shiwh@cn.fujitsu.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NTony Luck <tony.luck@intel.com>

this is the tale of a full day spent debugging an ancient but elusive bug.

after booting up thousands of random .config kernels, i finally happened
to generate a .config that produced the following rare bootup failure
on 32-bit x86:

| ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
| ..MP-BIOS bug: 8254 timer not connected to IO-APIC
| ...trying to set up timer (IRQ0) through the 8259A ...  failed.
| ...trying to set up timer as Virtual Wire IRQ... failed.
| ...trying to set up timer as ExtINT IRQ... failed :(.
| Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug
| and send a report.  Then try booting with the 'noapic' option

this bug has been reported many times during the years, but it was never
reproduced nor fixed.

the bug that i hit was extremely sensitive to .config details.

First i did a .config-bisection - suspecting some .config detail.
That led to CONFIG_X86_MCE: enabling X86_MCE magically made the bug disappear
and the system would boot up just fine.

Debugging my way through the MCE code ended up identifying two unlikely
candidates: the thing that made a real difference to the hang was that
X86_MCE did two printks:

 Intel machine check architecture supported.
 Intel machine check reporting enabled on CPU#1.

Adding the same printks to a !CONFIG_X86_MCE kernel made the bug go away!

this left timing as the main suspect: i experimented with adding various
udelay()s to the arch/x86/kernel/io_apic_32.c:check_timer() function, and
the race window turned out to be narrower than 30 microseconds (!).

That made debugging especially funny, debugging without having printk
ability before the bug hits is ... interesting ;-)

eventually i started suspecting IRQ activities - those are pretty much the
only thing that happen this early during bootup and have the timescale of
a few dozen microseconds. Also, check_timer() changes the IRQ hardware
in various creative ways, so the main candidate became IRQ0 interaction.

i've added a counter to track timer irqs (on which core they arrived, at
what exact time, etc.) and found that no timer IRQ would arrive after the
bug condition hits - even if we re-enable IRQ0 and re-initialize the i8259A,
but that we'd get a small number of timer irqs right around the time when we
call the check_timer() function.

Eventually i got the following backtrace triggered from debug code in the
timer interrupt:

...trying to set up timer as Virtual Wire IRQ... failed.
...trying to set up timer as ExtINT IRQ...
Pid: 1, comm: swapper Not tainted (2.6.24-rc5 #57)
EIP: 0060:[<c044d57e>] EFLAGS: 00000246 CPU: 0
EIP is at _spin_unlock_irqrestore+0x5/0x1c
EAX: c0634178 EBX: 00000000 ECX: c4947d63 EDX: 00000246
ESI: 00000002 EDI: 00010031 EBP: c04e0f2e ESP: f7c41df4
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
 CR0: 8005003b CR2: ffe04000 CR3: 00630000 CR4: 000006d0
 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
 DR6: ffff0ff0 DR7: 00000400
  [<c05f5784>] setup_IO_APIC+0x9c3/0xc5c

the spin_unlock() was called from init_8259A(). Wait ... we have an IRQ0
entry while we are in the middle of setting up the local APIC, the i8259A
and the PIT??

That is certainly not how it's supposed to work! check_timer() was supposed
to be called with irqs turned off - but this eroded away sometime in the
past. This code would still work most of the time because this code runs
very quickly, but just the right timing conditions are present and IRQ0
hits in this small, ~30 usecs window, timer irqs stop and the system does
not boot up. Also, given how early this is during bootup, the hang is
very deterministic - but it would only occur on certain machines (and
certain configs).

The fix was quite simple: disable/restore interrupts properly in this
function. With that in place the test-system now boots up just fine.

(64-bit x86 io_apic_64.c had the same bug.)

Phew! One down, only 1500 other kernel bugs are left ;-)
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

Kprobes for x86-64 may cause a kernel crash if it inserted on "iret"
instruction. "call absolute" is invalid on x86-64, so we don't need
treat it.

 - Change the processing order as same as x86-32.
 - Add "iret"(0xcf) case.
 - Remove next_rip local variable.
Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

jprobe for x86-64 may cause kernel page fault when the jprobe_return()
is called from incorrect function.

- Use jprobe_saved_regs instead getting it from stack.
  (Especially on x86-64, it may get incorrect data, because
   pt_regs can not be get by using container_of(rsp))
- Change the type of stack pointer to unsigned long *.
Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

This patch is for controlling the upper 32bits of the event ctrl msrs.
This includes the upper 4 bits of the event select and the Guest Only and
Host Only bits

This patch is necessary to make Event Based Profiling work reliably on a
Family 10h processor

[akpm@linux-foundation.org: checkpatch.pl fixes]
Signed-off-by: NBarry Kasindorf <barry.kasindorf@amd.com>
Signed-off-by: NRobert Richter <robert.richter@amd.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

This fixes some of the alpha-specific build problems, except a) modpost
warning about COMMON symbol "saved_config" and b) nasty final link
failure with gcc-4.x, -Os and scsi-disk driver configured built-in
(due to jump table in .rodata referencing discarded .exit.text).

- build failure with gcc-4.2.x: fix up casts in cia_io* routines to avoid
  warnings ('discards qualifiers from pointer target type'), which are
  failures, thanks to -Werror;
- modpost warnings: add missing __init qualifier for titan and marvel;
  for non-generic build, move machine vectors from .data to .data.init.refok
  section;
- unbreak CPU-specific optimization: rearrange cpuflags-y assignments
  so that extended -mcpu value (ev56, pca56, ev67) overrides basic
  one (ev5, ev6) and not vice versa.
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

First of all, thanks to Bob Tracy <rct@frus.com> and
Michael Cree <mcree@orcon.net.nz> for testing.
Especially to Bob, as he has done titanic multi-day git-bisect
work that finally helped to reproduce and nail down the bug
(http://bugzilla.kernel.org/show_bug.cgi?id=9457).

[ev6-]stxncpy.S: it's t12, not t2 register that is supposed to contain
the last byte offset upon return. As a result of wrong register use
(which was my fault back in 2003, IIRC), under some circumstances extra
terminating zero bytes were added to destination string. This particularly
led to incorrect DEVPATH strings generated in uevent and therefore to udev
problems.

strncpy.S: unrelated bug I found while testing the above fix - destination
is not properly zero-padded then a byte count exceeds source length.
Actually this is addition to strncpy fix from last year.
Signed-off-by: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Bob Tracy <rct@frus.com>
Cc: Michael Cree <mcree@orcon.net.nz>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Sometimes when UML is debugged gdb miss breakpoints.

When process traced by gdb do fork, debugger remove breakpoints from
child address space. There is possibility to trace more than one fork,
but this not work with UML, I guess (only guess) there is a deadlock -
gdb waits for UML and UML waits for gdb.

When clone() is called with SIGCHLD and CLONE_VM flags, gdb see this
as PTRACE_EVENT_FORK not as PTRACE_EVENT_CLONE and remove breakpoints
from child and at the same time from traced process, because either
have the same address space.

Maybe it is possible to do fix in gdb, but I'm not sure if there is
easy way to find out if traced and child processes share memory. So I
do fix for UML, it simply do not call clone() with both SIGCHLD and
CLONE_VM flags together.  Additionally __WALL flag is used for
waitpid() to assure not miss clone and normal process events.

[ jdike - checkpatch fixes ]
Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
Signed-off-by: NJeff Dike <jdike@linux.intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Revert commit efa4d2fb ("Hibernation:
Use temporary page tables for kernel text mapping on x86_64") because it
causes my t61p to reboot right at the end of resume-from-disk.  For
reasons unknown at this time.

Cc: Pavel Machek <pavel@ucw.cz>
Cc: Andi Kleen <ak@suse.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Acked-by: N"Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add proper support for CLOCK_EVT_MODE_RESUME and in the process fix
CLOCK_EVT_MODE_SHUTDOWN so that only the enable bits are toggled for both.
Signed-off-by: NKevin Hilman <khilman@mvista.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

According to ARM7TDMI Technical Reference Manual (ARM DDI 0210C) writing
to the DCC data write register coproc dest registers are 1 and 0, not 0
and 1.

ARM920T TRM (ARM DDI 0151C) agrees on that.

Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: NUwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: NChris Dearman <chris@mips.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Frank Rowand <frank.rowand@am.sony.com> reports:

> In linux-2.6.24-rc4 the Toshiba RBTX4927 hangs on boot.
>
> The cause is that plat_time_init() from arch/mips/tx4927/common/
> tx4927_setup.c does not override the __weak plat_time_init() from
> arch/mips/kernel/time.c.  This is due to a compiler bug in gcc 4.1.1.  The
> bug is reported to not exist in earlier versions of gcc, and to be fixed in
> 4.1.2.  The problem is that the __weak plat_time_init() is empty and thus
> gets optimized out of existence (thus the linker is never given the option
> to replace the __weak function).

[ He meant the call to plat_time_init() from time_init() gets optimized away ]

> For more info on the gcc bug see
>
>    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27781
>
> The attached patch is one workaround.  Another possible workaround

[ His patch adds -fno-unit-at-a-time for time.c ]

> would be to change the __weak plat_time_init() to be a non-empty
> function.

The __weak definition of plat_time_init was only ever meant to be a
migration helper to keep platforms that don't have a plat_time_init
compiling.  A few greps says that all platforms now supply their own
plat_time_init() so the weak definition is no longer needed.  So I
instead delete it.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

There might be other reasons why a resource might be marked as fixed
such as a PCI UART holding the system console but until we use
IORESOURCE_PCI_FIXED that way also this will work.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

A proper fix for this needs to turn a few MIPS-generic bits which I
don't want at this stage.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

the PCI specific code in this function doesn't check for the address range
being under the upper bound of the PCI memory window correctly -- fix this,
somewhat beautifying the code around the check, while at it...
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

... by getting the PCI resources back into the 32-bit range -- there's no
need therefore for CONFIG_RESOURCES_64BIT either. This makes Alchemy PCI
work again while currently the kernel skips the bus scan.
Signed-off-by: NSergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Signed-off-by: NYoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Currently it's impossible to build a ps3_defconfig which will reboot
without modules installed. This makes it all too easy to find yourself
with a PS3 that won't reboot.

This is because the system manager driver, which provides the reboot
mechanism, is only selectable if PS3_ADVANCED is set, else it defaults
to m. In ps3_defconfig PS3_ADVANCED is not set, therefore the system
manager is built as a module.

It would be desirable IMHO for the defconfig to produce a kernel that
boots and reboots, without needing modules to be installed.
Signed-off-by: NMichael Ellerman <michael@ellerman.id.au>
Acked-by: NGeoff Levand <geoffrey.levand@am.sony.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This patch fixes rounding bug in emulation for double float operating on PowerPC platform.

When pack double float operand, it need to truncate the tail due to the limited precision.
If the truncated part is not zero, the last bit of work bit (totally 3 bits) need to '|' 1.

This patch is completed in _FP_FRAC_SRS_2(X,N,sz) (arch/powerpc/math-emu/op-2.h).
Originally the code leftwards rotates the operand to just keep the truncated part,
then check whether it is zero. However, the number it rotates is not correct when
N is not smaller than _FP_W_TYPE_SIZE, and it will cause the work bit '|' 1 in the improper case.

This patch fixes this issue.
Signed-off-by: NLiu Yu <b13201@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Printk was observed to hang during module unload due to a limited
window of characters that may be sent to the hypervisor.  The window
only reexpands when we receive an ack from the HV and the spinlock here
prevents us from ever processing that ack.  This fixes it by dropping
the lock before doing the printk, then looping back to the top to
reacquire the lock.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

This was recently made configurable, and needs to be set for these boards.
Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Signed-off-by: NScott Wood <scottwood@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

Remove exports of __res and cpm_install_handler/cpm_free_handler.  Remove
cpm_install_handler/cpm_free_handler from the commproc.h as well.  Both
were used for ARCH=ppc and aren't defined for ARCH=powerpc.

CC      arch/powerpc/kernel/ppc_ksyms.o
arch/powerpc/kernel/ppc_ksyms.c:180: error: '__res' undeclared here (not in a function)
arch/powerpc/kernel/ppc_ksyms.c:180: warning: type defaults to 'int' in declaration of '__res'
make[1]: *** [arch/powerpc/kernel/ppc_ksyms.o] Error 1
make: *** [arch/powerpc/kernel] Error 2

LD      .tmp_vmlinux1
arch/powerpc/kernel/built-in.o:(__ksymtab+0x198): undefined reference to `cpm_free_handler'
arch/powerpc/kernel/built-in.o:(__ksymtab+0x1a0): undefined reference to `cpm_install_handler'
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: NJochen Friedrich <jochen@scram.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NVitaly Bordug <vitb@kernel.crashing.org>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>

This was caught and identified by Greg Onufer.

Since we setup the 256M/4M bitmap table after taking over the trap
table, it's possible for some 4M mapping to get loaded in the TLB
beforhand which later will be 256M mappings.

This can cause illegal TLB multiple-match conditions.  Fix this by
setting up the bitmap before we take over the trap table.

Next, __flush_tlb_all() was not doing anything on hypervisor
platforms.  Fix by adding sun4v_mmu_demap_all() and calling it.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>