This patch sets the max_cache_size value required to tune up
scheduler in SMP systems. Otherwise, the calculated
migration_cost is too high and task scheduling may lock up.
Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC64]: Avoid JBUS errors on some Niagara systems.
[FUSION]: Fix mptspi.c build with CONFIG_PM not set.
[TG3]: Handle Sun onboard tg3 chips more correctly.
[SPARC64]: Dump local cpu registers in sun4v_log_error()
Doing PCI config space accesses to non-present PCI slots
can result in fatal JBUS errors if the PCI config access
hypervisor call is performed on cpus other than the boot
cpu.
PCI config space accesses to present PCI slots works just
fine.
Recursively traverse the OBP device tree under the PCI
controller node and record all present device IDs into
a small hash table.
Avoid the hypervisor call for any PCI config space access
attempt for a device not recorded in the hash table.
Signed-off-by: David S. Miller <davem@davemloft.net>
The IBM Cell blade firmware might confuse the kernel to think it's a
pSeries machine. This fixes it for now. With a bit of luck, the firmware
will be updated to avoid that in the future but currently that patch is
needed.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The code in prom_init.c calling the firmware
ibm,client-architecture-support method on pSeries has a bug where it
fails to properly pass the instance handle of the firmware object when
trying to call a method. Result ranges from the call doing nothing to
the firmware crashing. (Found by Segher, thanks !)
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This fixes a bug found by Dave Jones that means that it is possible
for userspace to provoke a machine check on 32-bit kernels. This
also fixes a couple of other places where I found similar problems
by inspection.
Signed-off-by: Paul Mackerras <paulus@samba.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
The recent renaming of m48t86's ->readb() and ->writeb() platform driver
methods (2d7b20c188) to ->readbyte() and
->writebyte() to fix the ia64 build broke the build of the cirrus ep93xx
ARM platform. This patch fixes it up.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: Russell King <rmk@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: "Andy Currid" <ACurrid@nvidia.com>
This patch fixes a kernel panic during boot that occurs on NVIDIA platforms
that have HPET enabled.
When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2 and is
advertised as such in the ACPI APIC table - but an earlier workaround in the
kernel was ignoring this override. The fix is to honor timer IRQ overrides
from ACPI when HPET is detected on an NVIDIA platform.
Signed-off-by: Andy Currid <acurrid@nvidia.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: "Yu, Luming" <luming.yu@intel.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: "Andy Currid" <ACurrid@nvidia.com>
This patch fixes a kernel panic during boot that occurs on NVIDIA platforms
that have HPET enabled.
When HPET is enabled, the standard timer IRQ is routed to IOAPIC pin 2 and is
advertised as such in the ACPI APIC table - but an earlier workaround in the
kernel was ignoring this override. The fix is to honor timer IRQ overrides
from ACPI when HPET is detected on an NVIDIA platform.
Signed-off-by: Andy Currid <acurrid@nvidia.com>
Cc: "Brown, Len" <len.brown@intel.com>
Cc: "Yu, Luming" <luming.yu@intel.com>
Cc: Andi Kleen <ak@muc.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Move memory_present() in arch/mips/kernel/setup.c. When using sparsemem
extreme, this function does an allocate for bootmem. This would always
fail since init_bootmem hasn't been called yet.
Move memory_present after free_bootmem. This only marks actual memory
ranges as present instead of the entire address space.
Signed-off-by: Chad Reese <creese@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fix following warnings:
linux/arch/mips/kernel/setup.c:432: warning: field width is not type int (arg 2)
linux/arch/mips/kernel/setup.c:432: warning: field width is not type int (arg 4)
linux/arch/mips/kernel/syscall.c:279: warning: unused variable `len'
linux/arch/mips/kernel/syscall.c:280: warning: unused variable `name'
linux/arch/mips/math-emu/dp_fint.c:32: warning: unused variable `xc'
linux/arch/mips/math-emu/dp_flong.c:32: warning: unused variable `xc'
linux/arch/mips/math-emu/sp_fint.c:32: warning: unused variable `xc'
linux/arch/mips/math-emu/sp_flong.c:32: warning: unused variable `xc'
(original patch by Atsushi, slight changes to the setup.c part by me.)
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fix following warnings:
linux/arch/mips/kernel/setup.c:249:12: warning: constant 0xffffffff00000000 is so big it is unsigned long
linux/arch/mips/kernel/cpu-bugs64.c:209:10: warning: constant 0xffffffffffffdb9a is so big it is unsigned long
linux/arch/mips/kernel/cpu-bugs64.c:227:10: warning: constant 0xffffffffffffdb9a is so big it is unsigned long
linux/arch/mips/kernel/cpu-bugs64.c:283:10: warning: constant 0xffffffffffffdb9a is so big it is unsigned long
linux/arch/mips/kernel/cpu-bugs64.c:299:10: warning: constant 0xffffffffffffdb9a is so big it is unsigned long
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The wrong revision number in the check was forcing a fallback to FPU
emulation for all SB1 cores in 2.6.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
open() always sets the O_LARGEFILE flag for the o32 ABI implementation
of a 64bit kernel. The appended patch fixes it.
Signed-off-by: Thiemo Seufer <ths@networkno.de>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Alchemy boards use YAMON which passes the environment variables as the
tuples of strings (the name followed by the value) unlike PMON which
passes "name=<val>" strings.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Save the Config.OD bit from being clobbered by coherency_setup(). This
bit, when set, fixes various errata in the early steppings of Au1x00
SOCs. Unfortunately, the bit was write-only on the most early of them.
In addition, also restore the bit after a wakeup from sleep.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The modpost uses a whitelist for commonly used suffix on checking the
section mismatch. Adding "_ops" suffix to op_modex_xxx get rid of
this modpost warning.
WARNING: arch/mips/oprofile/oprofile.o - Section mismatch: reference to .init.text: from .data after 'op_model_mipsxx' (at offset 0x528)
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
From: Jeff Dike <jdike@addtoit.com>
This fixes the undefined reference to strcpy seen when building modules on
i386. Tracked down by Al Viro.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: Al Viro <viro@zeniv.linux.org.uk>
uml __user annotations
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: Al Viro <viro@zeniv.linux.org.uk>
fix uml/amd64 prctl()
put_user() there should go to (long __user *)addr, not &addr
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: Jeff Dike <jdike@addtoit.com>
We had a spurious semicolon somehow.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: Jeff Dike <jdike@addtoit.com>
Initialize wall_to_monotonic correctly. This fixes a problem where sleeps
lasted about one secone less than they should. This also called for a bit of
code restructuring, following a patch which Blaisorblade had been keeping.
Signed-off-by: Jeff Dike <jdike@addtoit.com>
Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
This fixes request_irq() potentially called from atomic context.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
From: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
After removal of fixup_cpu_present_map() function Alpha ended up with an empty
cpu_present_map, so secondary CPUs on SMP systems are not being started.
Worse, on some platforms we route interrupts to secondary CPUs using
cpu_possible_map which is still populated properly. As a result, these
interrupts go nowhere so the machines like DP264 aren't able to boot even with
a primary CPU.
Fixed basically by s/cpu_present_mask/cpu_present_map/.
Thanks to Ernst Herzberg for reporting the bug and testing the fix.
Cc: Ernst Herzberg <list-lkml@net4u.de>
Cc: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Patch from Steve Yang
MACHINE_START struct doesn't have any bootargs location for the
mainstone. Result is no kernel command args get passed; no serial driver
is selected for console and results in a silent boot failure.
Signed-off-by: Steve Yang <steve.yang@windriver.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Replacing mistyped "buad" with "baud" where applicable.
Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Both csum_partial() and the csum_partial_copy*() family of routines
forget to do a final fold on the computed checksum value on sparc64.
So do the standard Sparc "add + set condition codes, add carry"
sequence, then make sure the high 32-bits of the return value are
clear.
Based upon some excellent detective work and debugging done by
Richard Braun and Samuel Thibault.
Signed-off-by: David S. Miller <davem@davemloft.net>
* master.kernel.org:/home/rmk/linux-2.6-arm:
[ARM] 3540/1: ixp23xx: deal with gap in interrupt bitmasks
[ARM] 3539/1: ixp23xx: fix __arch_ixp23xx_is_coherent() for A1 stepping
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC64]: Fix D-cache corruption in mremap
[SPARC64]: Make smp_processor_id() functional before start_kernel()
Patch from Lennert Buytenhek
On the ixp23xx, the microengine thread interrupt sources are numbered
56..119, but their mask/status bits are located in bit positions 64..127
in the various registers in the interrupt controller (bit positions
56..63 are unused.)
We don't deal with this, so currently, when asked to enable IRQ 64, we
will enable IRQ 56 instead.
The only interrupts >= 64 are the thread interrupt sources, and there
are no in-tree users of those yet, so this is fortunately not a big
problem, but this needs fixing anyway.
Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
[MIPS] Treat R14000 like R10000.
[MIPS] Remove EXPERIMENTAL from PAGE_SIZE_16KB
[MIPS] Update/Fix instruction definitions
[MIPS] DSP and MDMX share the same config flag bit.
[MIPS] Fix deadlock on MP with cache aliases.
[MIPS] Use generic STABS_DEBUG macro.
[MIPS] Create consistency in "system type" selection.
[MIPS] Use generic DWARF_DEBUG
[MIPS] Fix kgdb exception handler from user mode.
[MIPS] Update struct sigcontext member names
[MIPS] Update/fix futex assembly
[MIPS] Remove support for sysmips(2) SETNAME and MIPS_RDNVRAM operations.
[MIPS] Fix detection and handling of the 74K processor.
[MIPS] Add missing 34K processor IDs
[MIPS] Fix marking buddy of pte global for MIPS32 w/36-bit physical address
[MIPS] AU1xxx mips_timer_interrupt() fixes
[MIPS] Fix typo
A proper fix would involve introducing the notion of shared caches but
at this stage of 2.6.17 that's going to be too intrusive and not needed
for current hardware; aside I think some discussion will be needed.
So for now on the affected SMP configurations which happen to suffer from
cache aliases we make use of the fact that a single cache will be shared
by all processors. This solves the deadlock issue and will improve
performance by getting rid of the smp_call_function overhead.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The "system type" Kconfig options on MIPS are not consistent. For
some platforms, only the name is listed while other entries are
prepended with "Support for". Remove this as it doesn't make sense
when describing the "system type".
Signed-off-by: Martin Michlmayr <tbm@cyrius.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
When debugging a kernel compiled by gcc 4.1 with gdb 6.4, gdb could
not show filename, linenumber, etc. It seems fixed if I used generic
DWARF_DEBUG macro. Although gcc 3.x seems work without this change,
it would be better to use the generic macro unless there were
something MIPS specific.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Rename the 64-bit sc_hi and sc_lo arrays to use the same names
as the 32-bit struct sigcontext (sc_mdhi, sc_hi1, et cetera).
Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
SETNAME only had a minor defect but probably never had a user and
MIPS_RDNVRAM was unimplemented anyway.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
