This patch fixes two places where we used plain 'x - PAGE_OFFSET' to
achieve virtual to physical address convertions. This type of convertion
is no more allowed since commit 6f284a2c.
Reported-by: NMaxime Bizon <mbizon@freebox.fr>
Signed-off-by: NFranck Bui-Huu <fbuihuu@gmail.com>

[Build fixes for machines that don't use the generic dma-coherence.h]
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Ray Lee reported, that on an UP kernel with "noapic" command line option
set, the box locks hard during boot.

Adding some debug printks revealed, that the last action on the box
before stalling was "Send IPI" - a debug printk which was put into
smp_send_timer_broadcast_ipi().

It seems that send_IPI_mask(mask, LOCAL_TIMER_VECTOR) fails when
"noapic" is set on the command line on an UP kernel.

Aside of that it does not make much sense to trigger an interrupt
instead of calling the function directly on the CPU which gets the
PIT/HPET interrupt in case of broadcasting.
Reported-by: NRay Lee <ray-lk@madrabbit.org>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NRay Lee <ray-lk@madrabbit.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Needed for any architecture that claims ARCH_APICTIMER_STOPS_ON_C3,
not just i386.

I'm hoping Thomas will clean this up a bit later..
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

It turned out that it is almost impossible to trust ACPI, BIOS & Co.
regarding the C states. This was the reason to switch the local apic
timer off in C2 state already. OTOH there are sane and well behaving
systems, which get punished by that decision.

Allow the user to confirm that the local apic timer is trustworthy in C2
state. This keeps the default behaviour on the safe side.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

latest -git triggers an irqtrace/lockdep warning of a leaked
irqs-off condition:

  BUG: at kernel/fork.c:1033 copy_process()

after some debugging it turns out that commit ca1b940c accidentally left
interrupts disabled - which trickled down all the way to the first time
we fork a kernel thread and triggered the warning.

the fix is to re-enable interrupts in the 'else' branch of
setup_boot_APIC_clock()'s pmtimers calibration path.
Reported-by: NMichal Piotrowski <michal.k.k.piotrowski@gmail.com>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NThomas Gleixner <tglx@brown.paperbag.linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The local APIC timer stops to work in deeper C-States.  This is handled by
the ACPI code and a broadcast mechanism in the clockevents / tick managment
code.

Some systems do not expose the deeper C-States to the kernel, but switch
into deeper C-States behind the kernels back.  This delays the local apic
timer interrupts for ever and makes the systems unusable.

Add a command line option to disable the local apic timer and a dmi
quirk for known broken systems.

Andi sayeth:

  While not wrong by itself i think it is still better to use some heuristic
  -- like "has battery in ACPI" With the DMI table if the problem is more wide
  spread we will just continue extending it.

  But anyways should be ok now for .21 although I'm not really happy with
  it.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NIngo Molnar <mingo@elte.hu>
Cc: john stultz <johnstul@us.ibm.com>
Grudgingly-acked-by: NAndi Kleen <ak@suse.de>
Cc: Len Brown <lenb@kernel.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The PIT has no dedicated mode for shut down. The only way to disable PIT
is to put it into one shot mode. AMD implementations of PIT on Geode
(also observed on Cyrix) are confused by an "empty" transition from
CLOCK_EVT_MODE_UNUSED to CLOCK_EVT_MODE_SHUTDOWN, which puts the PIT
into one shot mode momentarily.

I realized after staring helpless at the bug report
http://bugzilla.kernel.org/show_bug.cgi?id=8027 for quite a while, that
the only change, which might influence the bogomips calibration, is the
above transition during the PIT initialization.

Avoiding the unnecessary switch to oneshot and later to periodic mode
fixes the weird bogomips value and also the resulting slowness.

The fix is confirmed on OLPC and another Geode based box.

Note: this is unrelated to the Dual Core problem discussed here:
http://lkml.org/lkml/2007/3/17/48Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

I noticed that we execute hcalls before cpu feature code has run (eg
for setting up the bolted kernel region).  This means that we may be
executing code that is not appropriate for the processor we have.
Create an unconditional branch that we nop out all the time to fix this.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

kexec invokes plpar_hcall hypervisor call in real mode.  plpar_hcall
refers to per cpu variables for accounting hypervisor statistics.
These variables may not be in the RMO region, so accesses to them
in real mode may result in a data storage exception.

This fixes this problem by using a new plpar_hcall_raw function which
does not update the hypervisor call statistics.  Thanks to Anton for
suggesting this idea.
Signed-off-by: NMohan Kumar M <mohan@in.ibm.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

In sn_io_slot_fixup(), the parent is re-set from the bus to
io(port|mem)_resource because the address is changed in a way that it's not
child of the bus any more.

However, only the root is set but not the parent/child/sibling relationship in
the resource tree which causes 'cat /proc/iomem' to stop after this memory
area. Depding on the poition in the tree the iomem may be nearly completely
empty.
Signed-off-by: NBernhard Walle <bwalle@suse.de>
Acked-by: NJohn Keller <jpk@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

When booting an SN system without specifing a console
(i.e., no "console=" on boot line), the system will hang during
boot at the point where /sbin/init is run.

The problem is that vga_console_iobase is not converted to a
virtual address before storing in io_space[0].mmio_base.
The conversion was happening in sn_scan_pcdp(), but not in
setup_vga_console().
Signed-off-by: NJohn Keller <jpk@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

Clearly should be checking for "val == DIE_INIT_SLAVE_ENTER".
Signed-off-by: NJay Lan <jlan@sgi.com>
Acked-by: NSimon Horman <horms@verge.net.au>
Signed-off-by: NTony Luck <tony.luck@intel.com>

If a system consists of mixed processor types, kmalloc()
can be called before the per-cpu data page is initialized.
If the slab contains sufficient memory, then kmalloc() works
ok. However, if the slabs are empty, slab calls the memory
allocator. This requires per-cpu data (NODE_DATA()) & the
cpu dies.

Also noted by Russ Anderson who had a very similar patch.
Signed-off-by: NJack Steiner <steiner@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

We have seen bad_pte_print when testing crashdump on an SN machine in
recent 2.6.20 kernel.  There are tons of bad pte print (pfn < max_low_pfn)
reports when the crash kernel boots up, all those reported bad pages
are inside initmem range; That is because if the crash kernel code and
data happens to be at the beginning of the 1st node. build_node_maps in
discontig.c will bypass reserved regions with filter_rsvd_memory. Since
min_low_pfn is calculated in build_node_map, so in this case, min_low_pfn
will be greater than kernel code and data.

Because pages inside initmem are freed and reused later, we saw
pfn_valid check fail on those pages.

I think this theoretically happen on a normal kernel. When I check
min_low_pfn and max_low_pfn calculation in contig.c and discontig.c.
I found more issues than this.

1. min_low_pfn and max_low_pfn calculation is inconsistent between
contig.c and discontig.c,
min_low_pfn is calculated as the first page number of boot memmap in
contig.c (Why? Though this may work at the most of the time, I don't
think it is the right logic). It is calculated as the lowest physical
memory page number bypass reserved regions in discontig.c.
max_low_pfn is calculated include reserved regions in contig.c. It is
calculated exclude reserved regions in discontig.c.

2. If kernel code and data region is happen to be at the begin or the
end of physical memory, when min_low_pfn and max_low_pfn calculation is
bypassed kernel code and data, pages in initmem will report bad.

3. initrd is also in reserved regions, if it is at the begin or at the
end of physical memory, kernel will refuse to reuse the memory. Because
the virt_addr_valid check in free_initrd_mem.

So it is better to fix and clean up those issues.
Calculate min_low_pfn and max_low_pfn in a consistent way.
Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
Acked-by: NJay Lan <jlan@sgi.com>
Signed-off-by: NTony Luck <tony.luck@intel.com>

The evils of Kconfig's select bite us once again...
ia64/Kconfig selects ACPI, which depends on PM.
But select ignores dependencies, allnoconfig
chooses CONFIG_PM=n, and thus the menu of sub-options
under ACPI vanish, which breaks the build.

Manually select PM along with ACPI for now.
Some day, we should delete them both, or fix select.

Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The manual says that it is required and we actually have crash reports
where loads see stale data due to not having membars here.

In one case the networking does:

	memset(skb, 0, offsetof(struct sk_buff, truesize));

and then some code later checks skb->nohdr for zero, but it's still
the value that was there before the memset().

Note that arch/sparc64/lib/xor.S already got this right.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Otherwise objdump will screw up disassembly.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Allows overriding the MALTA/ATLAS/etc. default console setting with
non-serial console devices.
Signed-Off-By: NThiemo Seufer <ths@networkno.de>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

 o adds missing ST0_IM masks, which caused the logging of valid interrupts
   as spurious
 o stops pnx8550 to log every interrupt as spurious
 o adds cause register masks for ip22/ip32, which caused handling of masked
   interrupts
 o removes some superfluous parentheses in the SNI interrupt code
Signed-Off-By: NThiemo Seufer <ths@networkno.de>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

Might be useful for SMP debugging.
Signed-off-by: NAtsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

[Rewritten Kconfig bits to deal better fit in the usual pattern of doing
things - Ralf]
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

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

Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

We used wrong length values for ipl and dump hardware structures.
Since z/VM checks the ipl parameters more accurately than LPAR,
the operations fail there.
Signed-off-by: NMichael Holzheu <holzheu@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

strlcpy already accounts for the trailing zero in its length
computation, so there is no need to substract one to the buffer size.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

diag 260 returns the address of the last addressable byte and not the
size of memory. Since we want the size we have to add 1 to the return
value.
Disable diag 260 for non z/Arch mode since it doesn't work there
anyway.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Build fix:  sa1100/generic.c should already have included <asm/gpio.h>,
but it didn't ... causing a build problem with a recent patch.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

When PM-Timer is available for local APIC timer calibration we can skip the
verification of the calibrated time value.  The resulting error is quite
small on a bunch of evaluated platforms and is less harming than the
observed false positives.

We need to keep the verification on systems, which have no PM-Timer to
avoid bogus local APIC timer calibrations in the range of factor 2-10,
which can be observed when swicthing off the PM-timer support in the kernel
configuration.

The wrong calibration values are probably caused by SMM code trying to
emulate a PS/2 keyboard from a (maybe connected or not) USB keyboard.  This
prohibits the accurate delivery of PIT interrupts, which are used to
calibrate the local APIC timer.  Unfortunately we have no way to disable
this BIOS misfeature in the early boot process.

Add also the dropped cpu_relax() back to the wait loops.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NIngo Molnar <mingo@elte.hu>
Acked-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix atomicity of TIF update in flush_thread() for x86_64

Race :

parent process executing :
sys_ptrace()
 (lock_kernel())
 (ptrace_get_task_struct(pid))
 arch_ptrace()
   ptrace_detach()
     ptrace_disable(child);
       clear_singlestep(child);
         clear_tsk_thread_flag(child, TIF_SINGLESTEP);
         (which clears the TIF_SINGLESTEP flag atomically from a different
	  process)
 (put_task_struct(child))
 (unlock_kernel())

And at the same time, in the child process :
sys_execve()
 do_execve()
   search_binary_handler()
     load_elf_binary()
       flush_old_exec()
         flush_thread()
           doing a non-atomic thread flag update
Signed-off-by: NRebecca Schultz <rschultz@google.com>
Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: NAndi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

In sn_io_slot_fixup(), the parent is re-set from the bus to
io(port|mem)_resource because the address is changed in a way that it's not
child of the bus any more.

However, only the root is set but not the parent/child/sibling relationship
in the resource tree which causes 'cat /proc/iomem' to stop after this
memory area.  Depding on the poition in the tree the iomem may be nearly
completely empty.
Signed-off-by: NBernhard Walle <bwalle@suse.de>
Cc: John Keller <jpk@sgi.com>
Cc: Jay Lan <jlan@engr.sgi.com>
Acked-by: N"Luck, Tony" <tony.luck@intel.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=m
CONFIG_X86_P4_CLOCKMOD=y

arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_verify':p4-clockmod.c:(.text.cpufreq_p4_verify+0x8): undefined reference to `cpufreq_frequency_table_verify'
arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_cpu_exit':p4-clockmod.c:(.text.cpufreq_p4_cpu_exit+0x8): undefined reference to `cpufreq_frequency_table_put_attr'
arch/x86_64/kernel/built-in.o: In function `cpufreq_p4_cpu_init':p4-clockmod.c:(.text.cpufreq_p4_cpu_init+0x13b): undefined reference to `cpufreq_frequency_table_get_attr'
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Acked-by: NDave Jones <davej@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NDavid S. Miller <davem@davemloft.net>

It's been pointed out that output GPIOs should have an initial value, to
avoid signal glitching ...  among other things, it can be some time before
a driver is ready.  This patch corrects that oversight, fixing

 - documentation
 - platforms supporting the GPIO interface
 - users of that call (just one for now, others are pending)

There's only one user of this call for now since most platforms are still
using non-generic GPIO setup code, which in most cases already couples the
initial value with its "set output mode" request.

Note that most platforms are clear about the hardware letting the output
value be set before the pin direction is changed, but the s3c241x docs are
vague on that topic ...  so those chips might not avoid the glitches.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Acked-by: NAndrew Victor <andrew@sanpeople.com>
Acked-by: NMilan Svoboda <msvoboda@ra.rockwell.com>
Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

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

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

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

RTLX communication is based on lock-free shared memory buffers.  It
happened to be working by luck so far but relies on the optimizer doing
certain optimizations but no reordering.

Fixed by inserting proper barriers in rtlx_read and rtlx_write, and careful
pointer dereferencing.
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>

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

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

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