Restore a load from KSEG1 done as a workaround for an R4600 v2
erratum, dropped with 211be16de99a7424e66c0b6c0d00e2c970508ac2.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
It doesn't matter for use in 64-bit objects, but when used in
32-bit environments the top 32-bits of the local and in
registers will get chopped off on the next register window
spill/restore which leads to difficult to track down and
subtle bugs.
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC64]: Fix missing load-twin usage in Niagara-1 memcpy.
[SPARC64]: Fix put_user() calls in binfmt_aout32.c
[SPARC]: Fix EBUS use of uninitialized variable.
For the case where the source is not aligned modulo 8
we don't use load-twins to suck the data in and this
kills performance since normal loads allocate in the
L1 cache (unlike load-twin) and thus big memcpys swipe
the entire L1 D-cache.
We need to allocate a register window to implement this
properly, but that actually simplifies a lot of things
as a nice side-effect.
Signed-off-by: David S. Miller <davem@davemloft.net>
For some reason old binutils genertate larger headers so increase the text
offset of the vdso to avoid linker errors.
Roland McGrath explains:
"There are extra symbols in the '.dynsym' section that are responsible
for the size difference (They also cause corresponding inflation in
'.gnu.version')
Older ld's wrongly generated these unneeded symbols in .dynsym. This
was fixed not all that long ago (2006); binutils-2.17.50.0.6 might be
the first fixed version, but I have not verified for sure where the
cutoff was.
The unneeded symbols et al from old ld add almost 700 bytes excess.
This limits fairly tightly the amount by which the actual text and
data in the vDSO can grow in the future without pushing the whole
file over 4kb. If it does grow later on, we should consider changing
the layout with a config option or something to pack it better
without that padding, when building the kernel with newer binutils."
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Roland McGrath <roland@redhat.com>
Cc: Badari Pulavarty <pbadari@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On a POWER6 machine running 2.6.23-rc8 I sometimes see the following error:
xics_set_affinity: No online cpus in the mask 00000000,00000000,00000000,00000001 for irq 20
In a desperate attempt to get a changelog entry in 2.6.23, I took a look
into it.
It turns out we are passing a real and not a virtual irq into
get_irq_server. This works for the case where hwirq < NR_IRQS and we
set virq = hwirq. In my case however hwirq = 590082 and we try and
access irq_desc[590082], slightly past the end at 512 entries.
Lucky we ship lots of memory with our machines.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Store any note sections after the exception tables like the other
architectures do. This is required for .note.gnu.build-id emitted from
binutils 2.18 onwards if nothing else.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
argv and envp are pointers to u32's in userspace, so don't
try to put_user() a NULL to them.
Aparently gcc-4.2.x now warns about this, and since we use
-Werror for arch/sparc64 code, this breaks the build.
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix the following (valid) section warnings:
WARNING: vmlinux.o(.text+0xf7b5c): Section mismatch: reference to .init.text:pcibios_fixup_bus (between 'pci_scan_child_bus' and 'pci_scan_bridge')
WARNING: vmlinux.o(.text+0xfc5f4): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_map_rom' and 'pci_unmap_rom')
WARNING: vmlinux.o(.text+0xfc824): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_update_resource' and 'pci_claim_resource')
WARNING: vmlinux.o(.text+0xfd6d8): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
WARNING: vmlinux.o(.text+0xfd730): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
WARNING: vmlinux.o(.text+0xfd788): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
WARNING: vmlinux.o(.text+0xfd7e0): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_setup_cardbus' and 'find_free_bus_resource')
WARNING: vmlinux.o(.text+0xfe024): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_bus_assign_resources' and 'sys_pciconfig_read')
WARNING: vmlinux.o(.text+0xfe0f4): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_bus_assign_resources' and 'sys_pciconfig_read')
WARNING: vmlinux.o(.text+0xfe17c): Section mismatch: reference to .init.text:pcibios_resource_to_bus (between 'pci_bus_assign_resources' and 'sys_pciconfig_read')
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
[MIPS] Fix fallocate on o32 binary compat ABI
[MIPS] Fix CONFIG_BUILD_ELF64 kernels with symbols in CKSEG0.
[MIPS] IP32: Fix initialization of UART base addresses.
MIPS was mistakenly forgetting to use the fallocate compat wrapper, which
I noticed while cleaning up all the duplicate fallocate wrappers.
Signed-off-by: Kyle McMartin <kyle@mcmartin.ca>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The e820 probe code was checking %edx, not %eax, for the SMAP
signature on return. This worked on *almost* all systems, since %edx
still contained SMAP from the call on entry, but on a handful of
systems it failed -- plus, we would have missed real mismatches.
The error output is "=d" to make sure gcc knows %edx is clobbered
here.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Setup dr_mode for USB-DR to peripheral as the default (host mode) doesn't make
much sense for the mini-AB connector on the ITX board.
Peripheral mode is preferable to OTG as the fsl_usb2_udc.c driver doesn't yet
properly support it.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
mpc834x USB-MPH configuration got broken by commit
6f44256002. The selection bits in SICRL
should be cleared rather than set to configure the USB MUXes for the MPH.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
cpm_dpram_addr returns physical memory of the DP RAM instead of
iomapped virtual memory. As there usually is a 1:1 MMU map of
the IMMR area, this is often not noticed. However, cpm_dpram_phys
assumes this iomapped virtual memory and returns garbage on the
1:1 mapped memory causing CPM1 uart console to fail.
This patch fixes the problem (copied from the powerpc tree).
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
The powerpc version of commproc.c exports cpm_dpram_addr twice
and cpm_dpram_phys not at all due to a typo. This patch fixes this
problem.
CC arch/powerpc/sysdev/commproc.o
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kcrctab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kcrctab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__kstrtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__kstrtab_cpm_dpram_addr' was here
arch/powerpc/sysdev/commproc.c:398: error: redefinition of '__ksymtab_cpm_dpram_addr'
arch/powerpc/sysdev/commproc.c:392: error: previous definition of '__ksymtab_cpm_dpram_addr' was here
make[1]: *** [arch/powerpc/sysdev/commproc.o] Error 1
make: *** [arch/powerpc/sysdev] Error 2
Signed-off-by: Jochen Friedrich <jochen@scram.de>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
If of_get_property() fails, it returns NULL and the 'len'
parameter is undefined. So we need to explicitly set len
to zero in such cases.
Noticed by Al Viro.
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit e66485d747, since
Rafael Wysocki noticed that the change only works for his in -mm, not in
mainline (and that both "noapictimer" _and_ "apicmaintimer" are broken
on his hardware, but that's apparently not a regression, just a symptom
of the same issue that causes the automatic apic timer disable to not
work).
It turns out that it really doesn't work correctly on x86-64, since
x86-64 doesn't use the generic clock events for timers yet.
Thanks to Rafal for testing, and here's the ugly details on x86-64 as
per Thomas:
"I just looked into the code and the logic vs. noapictimer on SMP is
completely broken.
On i386 the noapictimer option not only disables the local APIC
timer, it also registers the CPUs for broadcasting via IPI on SMP
systems.
The x86-64 code uses the broadcast only when the local apic timer is
active, i.e. "noapictimer" is not on the command line. This defeats
the whole purpose of "noapictimer". It should be there to make boxen
work, where the local APIC timer actually has a hardware problem,
e.g. the nx6325.
The current implementation of x86_64 only fixes the ACPI c-states
related problem where the APIC timer stops in C3(2), nothing else.
On nx6325 and other AMD X2 equipped systems which have the C1E
enabled we run into the following:
PIT keeps jiffies (and the system) running, but the local APIC timer
interrupts can get out of sync due to this C1E effect.
I don't think this is a critical problem, but it is wrong
nevertheless.
I think it's safe to revert the C1E patch and postpone the fix to the
clock events conversion."
On further reflection, Thomas noted:
"It's even worse than I thought on the first check:
"noapictimer" on the command line of an SMP box prevents _ONLY_ the
boot CPU apic timer from being used. But the secondary CPU is still
unconditionally setting up the APIC timer and uses the non
calibrated variable calibration_result, which is of course 0, to
setup the APIC timer. Wreckage guaranteed."
so we'll just have to wait for the x86 merge to hopefully fix this up
for x86-64.
Tested-and-requested-by: Rafael J. Wysocki <rjw@sisk.pl>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
At least one system (a Geode system with a Digital Logic BIOS) has
been found which suddenly stops reporting the SMAP signature when
reading the E820 memory chain. We can't know what, exactly, broke in
the BIOS, so if we detect this situation, declare the E820 data
unusable and fall back to E801.
Also, revert to original behavior of always probing all memory
methods; that way all the memory information is available to the
kernel.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Jordan Crouse <jordan.crouse@amd.com>
Cc: Joerg Pommnitz <pommnitz@yahoo.com>
execve's error paths don't activate (and therefore pin) the mm before
calling exit_mmap to free it up, so don't try to unpin unless it is
actually pinned. This prevents a BUG_ON from triggering.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Christian Ostheimer <osth@freesurf.ch>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
commit 3556ddfa92 titled
[PATCH] x86-64: Disable local APIC timer use on AMD systems with C1E
solves a problem with AMD dual core laptops e.g. HP nx6325 (Turion 64
X2) with C1E enabled:
When both cores go into idle at the same time, then the system switches
into C1E state, which is basically the same as C3. This stops the local
apic timer.
This was debugged right after the dyntick merge on i386 and despite the
patch title it fixes only the 32 bit path.
x86_64 is still missing this fix. It seems that mainline is not really
affected by this issue, as the PIT is running and keeps jiffies
incrementing, but that's just waiting for trouble.
-mm suffers from this problem due to the x86_64 high resolution timer
patches.
This is a quick and dirty port of the i386 code to x86_64.
I spent quite a time with Rafael to debug the -mm / hrt wreckage until
someone pointed us to this. I really had forgotten that we debugged this
half a year ago already.
Sigh, is it just me or is there something yelling arch/x86 into my ear?
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The commit 8b6f50ef1d seems to have
been affected by a mismerge of a duplicate patch
(d054b36ffd) - both the
spufs_dir_contents and spufs_dir_nosched_contents have been given
write-only signal notification files.
This change reverts the spufs_dir_contents array to use the
readable signal notification file implementation.
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When PTRACE_O_TRACEEXEC is used, a ptrace call to fetch the registers at
the PTRACE_EVENT_EXEC stop (PTRACE_PEEKUSR) will oops in CHECK_FULL_REGS.
With recent versions, "gdb --args /bin/sh -c 'exec /bin/true'" and "run" at
the (gdb) prompt is sufficient to produce this. I also have written an
isolated test case, see https://bugzilla.redhat.com/show_bug.cgi?id=301791#c15.
This change fixes the problem by clearing the low bit of pt_regs.trap in
start_thread so that FULL_REGS is true again. This is correct since all of
the GPRs that "full" refers to are cleared in start_thread.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When compiling the Blackfin kernel, checksyscalls.pl will report lots of missing syscalls warnings.
This patch will add some missing syscalls which make sense on Blackfin arch
After appling this patch, toolchain should be rebuilt. Then recompiling the kernel with the new
toolchain.
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
This reverts commit 34feb2c83b.
Suresh Siddha points out that this one breaks the fundamental
requirement that you cannot free page table pages before the TLB caches
are flushed. The quicklists do not give the same kinds of guarantees
that the mmu_gather structure does, at least not in NUMA configurations.
Requested-by: Suresh Siddha <suresh.b.siddha@intel.com>
Acked-by: Andi Kleen <ak@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Asit Mallick <asit.k.mallick@intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Strictly it's only needed for eax.
It actually does a little more than strictly needed -- the other registers
are already zero extended.
Also remove the now unnecessary and non functional compat task check
in ptrace.
This is CVE-2007-4573
Found by Wojciech Purczynski
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There's an obvious typo in arch/i386/boot/header.S (in your
linux-2.6-x86setup.git) that I noticed by just studying the code.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
wakeup.S looks at the video mode number from the setup header and
looks to see if it is a VESA mode. Unfortunately, the decoding is
done incorrectly and it will attempt to frob the VESA BIOS for any
mode number 0x0200 or larger. Correct this, and remove a bunch of #if
0'd code.
Massive thanks to Jeff Chua for reporting the bug, and suffering
though a large number of experiments in order to track this problem
down.
Cc: Pavel Machek <pavel@ucw.cz>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Canonicalize the video mode number as presented to the kernel. The
video mode number may be user-entered (e.g. ASK_VGA), an alias
(e.g. NORMAL_VGA), or a size specification, and that confuses the
suspend wakeup code.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
The EP93XX_GPIO_LINE_F() macro is supposed to be called with a line
number between 0 and 7, but the current code causes it to get called
with an spuriously offset number range {16..23}.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Signed-off-by: Lennert Buytenhek <kernel@wantstofly.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
[POWERPC] Fix timekeeping on PowerPC 601
[POWERPC] Don't expose clock vDSO functions when CPU has no timebase
[POWERPC] spusched: Fix null pointer dereference in find_victim
Randy Dunlap noticed an interesting "crashme" behaviour on his dual
Prescott Xeon setup, where he gets page faults with the error code
having a zero "user" bit, but the register state points back to user
mode.
This may be a CPU microcode buglet triggered by some strange instruction
pattern that crashme generates, and loading a microcode update seems to
possibly have fixed it.
Regardless, we really should trust the register state more than the
error code, since it's really the register state that determines whether
we can actually send a signal, or whether we're in kernel mode and need
to oops/kill the process in the case of a page fault.
Cc: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add a workaround to address warnings generated on the "n" constraint by
GCC 3.3 and below.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fix the definition of the ioasic_ssr_lock spinlock to include a proper
initialisation.
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch fixes a crash caused by an interrupt coming in when an IRQ stack
is being torn down. When this happens, handle_signal will loop, setting up
the IRQ stack again because the tearing down had finished, and handling
whatever signals had come in.
However, to_irq_stack returns a mask of pending signals to be handled, plus
bit zero is set if the IRQ stack was already active, and thus shouldn't be
torn down. This causes a problem because when handle_signal goes around
the loop, sig will be zero, and to_irq_stack will duly set bit zero in the
returned mask, faking handle_signal into believing that it shouldn't tear
down the IRQ stack and return thread_info pointers back to their original
values.
This will eventually cause a crash, as the IRQ stack thread_info will
continue pointing to the original task_struct and an interrupt will look
into it after it has been freed.
The fix is to stop passing a signal number into to_irq_stack. Rather, the
pending signals mask is initialized beforehand with the bit for sig already
set. References to sig in to_irq_stack can be replaced with references to
the mask.
[akpm@linux-foundation.org: use UL]
Signed-off-by: Jeff Dike <jdike@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Xen ignores all updates to cr4, and some versions will kill the domain if
you try to change its value. Just ignore all changes.
Signed-off-by: Jeremy Fitzhardinge <jeremy@xensource.com>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I found a type mismatch in UML that makes host block devices unusable as ubd
devices on x86_64 and other 64 bits systems (segfault of the mm subsystem):
In block/ioctl.c, the following lines show that the BLKGETSIZE ioctl expects
a pointer to a long:
case BLKGETSIZE:
if ((bdev->bd_inode->i_size >> 9) > ~0UL)
return -EFBIG;
return put_ulong(arg, bdev->bd_inode->i_size >> 9);
In arch/um/os-Linux/file.c, os_file_size calls it with an int.
The ioctl_list man page should be fixed as well.
Cc: Jeff Dike <jdike@addtoit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Recent changes to the timekeeping code broke support for the PowerPC 601
processor which doesn't have the usual timebase facility but a slightly
different thing called (yuck) the RTC.
This fixes it, boot tested on an old 601 based PowerMac 7200.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
We forgot to remove the clock_gettime, clock_getres and get_tbfreq vDSO
calls on CPUs that have no timebase such as 601 or 403 (old CPUs that have
different mechanisms and for which the vDSO code will not work properly).
This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
find_victim can dereference a NULL pointer when iterating over the list
of victim spus because list_mutex only guarantees spu->ct to be stable,
but of course not to be non-NULL.
Also fix find_victim to not call spu_unbind_context without list_mutex
because that violates the above guarantee.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The l2x0_inv_range() function doesn't handle unaligned addresses
correctly. It's necessary to clean the cache lines that are at the
start and end of the invalidate range, if the addresses are not aligned,
to prevent corruption of other data sharing the same cache line.
Signed-off-by: Rui Sousa <rui.p.m.sousa@gmail.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
When NR_CPUS is smaller than the cpu probed, let the user
know that the cpu won't be used.
Suggested by Al Viro.
Signed-off-by: David S. Miller <davem@davemloft.net>
As noted by Al Viro, when we try to call prom_set_trap_table()
in the SMP trampoline code we try to take the PROM call spinlock
which doesn't work because the current thread pointer isn't
valid yet and lockdep depends upon that being correct.
Furthermore, we cannot set the current thread pointer register
because it can't be properly dereferenced until we return from
prom_set_trap_table(). Kernel TLB misses only work after that
call.
So do the PROM call to set the trap table directly instead of
going through the OBP library C code, and thus avoid the lock
altogether.
These calls are guarenteed to be serialized fully.
Since there are now no calls to the prom_set_trap_table{_sun4v}()
library functions, they can be deleted.
Signed-off-by: David S. Miller <davem@davemloft.net>
* git://git.linux-xtensa.org/kernel/xtensa-feed:
[patch 1/2] Xtensa: enable arbitary tty speed setting ioctls
[patch 2/2] xtensa console.c: remove duplicate #include
[XTENSA] Add support for cache-aliasing
[XTENSA] Add kernel module support
[XTENSA] Add support for executable/non-executable feature in the mmu
[XTENSA] Use the generic version of get_order
[XTENSA] Initialize semaphore_wake_lock
[XTENSA] Add typecast macro for constants
[XTENSA] Fix timer instabilities.
[XTENSA] Fix fadvise64_64
[XTENSA] Remove extraneous include statement
[XTENSA] Move string-io functions to io.c from pci.c
[XTENSA] Move pre-initialized structures to init_task.c
[XTENSA] Add freestanding option to CFLAGS
[XTENSA] Add getpgrp system-call to unistd.h
[XTENSA] add missing system calls
[XTENSA] fix wrong usage of __init and __initdata in traps.c
* 'for-linus' of master.kernel.org:/pub/scm/linux/kernel/git/cooloney/blackfin-2.6:
Blackfin arch: fix some bugs in lib/string.h functions found by our string testing modules
Blackfin arch: fix the aliased write macros
Blackfin arch: Update/Fix PM support add new pm_ops valid
* master.kernel.org:/home/rmk/linux-2.6-arm:
[ARM] 4567/1: Fix 'Oops - undefined instruction' when CONFIG_VFP=y on non VFP device
[ARM] realview: disable second GIC on RevB MPCore platforms
Another issue with 20Kc's WAIT, waiting for more details. With the
2.6.23 release immindent simply disable the use of WAIT instead of a
more fancy workaround.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fairly cosmetic as it would only affect VSMP / SMTC kernels that don't
use vectored interrupts.
Found by Beth.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
It refer to CPU_PROFILING.
arch/mips/kernel/time.c: In function 'local_timer_interrupt':
arch/mips/kernel/time.c:142: error: implicit declaration of function 'profile_tick'
arch/mips/kernel/time.c:142: error: 'CPU_PROFILING' undeclared (first use in this function)
arch/mips/kernel/time.c:142: error: (Each undeclared identifier is reported only once
arch/mips/kernel/time.c:142: error: for each function it appears in.)
Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
CC arch/mips/kernel/rtlx.o
cc1: warnings being treated as errors
arch/mips/kernel/rtlx.c:59: warning: 'irq' defined but not used
arch/mips/kernel/rtlx.c:60: warning: 'irq_num' defined but not used
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
CC arch/mips/kernel/rtlx.o
arch/mips/kernel/rtlx.c: In function 'rtlx_init':
arch/mips/kernel/rtlx.c:114: warning: format '%x' expects type 'unsigned int', but argument 3 has type 'long unsigned int'
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
vfp_init() takes care of the condition when CONFIG_VFP=y but no real VFP
device exists. However, when this condition is true, a compiler might
misplace code lines in a way that will break this support. (To be more
specific - fmrx(FPSID) might be executed before vfp_testing_entry
assignment, which will end up with Oops - undefined instruction).
This patch adds a barrier() to guarantee the right execution ordering.
Signed-off-by: Assaf Hoffman
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The second GIC asserts a permanent interrupt on Rev.B MPCore platforms.
Disable initialisation of this GIC to avoid unbootable systems.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
With the I/O space rewrite by BenH, the legacy_serial serial_dev_init()
initcall is now called before I/O space is setup, but it's dependent on
it being available.
Since there's no way to make dependencies between initcalls, we'll just
have to move it to device_initcall(). Yes, it's suboptimal but I'm not
aware of any better solution at this time, and it fixes a regression
from 2.6.22.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Fix a compile error when the directory above the kernel source contains
a file named "kernel". Originally from Ben LaHaise, modified based on
feedback from Sam Ravnborg
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Ben LaHaise <bcrl@kvack.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
AK: Removed the unlikelies because gcc heuristics default to unlikely
AK: for test == NULL and for negative returns.
Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Cc: Ashok Raj <ashok.raj@intel.com>
Cc: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
vdso vgetns() didn't mask the time source offset calculation, which
could lead to time problems with 32bit HPET. Add the masking.
Thanks to Chuck Ebbert for tracking this down.
Signed-off-by: Andi Kleen <ak@suse.de>
Cc: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Since the ULI1575 has a ISA bus we need to enable the generic ISA dma
support for drivers that might expect it. Without this we get compile
errors like the following:
ound/built-in.o: In function `claim_dma_lock':
/home/galak/git/linux-8572/include/asm/dma.h:189: undefined reference to `dma_spin_lock'
/home/galak/git/linux-8572/include/asm/dma.h:189: undefined reference to `dma_spin_lock'
sound/built-in.o: In function `release_dma_lock':
/home/galak/git/linux-8572/include/asm/dma.h:195: undefined reference to `dma_spin_lock'
sound/built-in.o: In function `claim_dma_lock':
/home/galak/git/linux-8572/include/asm/dma.h:189: undefined reference to `dma_spin_lock'
/home/galak/git/linux-8572/include/asm/dma.h:189: undefined reference to `dma_spin_lock'
sound/built-in.o:/home/galak/git/linux-8572/include/asm/dma.h:195: more undefined references to `dma_spin_lock' follow
make: *** [.tmp_vmlinux1] Error 1
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
On the root PCI bus, the OBP device tree lists device 3 twice.
Once as 'pm' and once as 'lomp'.
Everything goes downhill from there.
Ignore the second instance to workaround this.
Thanks to Kövedi_Krisztián for the bug report and
testing the fix.
Signed-off-by: David S. Miller <davem@davemloft.net>
Revert
commit 656dad312f
Author: Ingo Molnar <mingo@elte.hu>
Date: Sat Feb 10 01:46:36 2007 -0800
[PATCH] highmem: catch illegal nesting
Catch illegally nested kmap_atomic()s even if the page that is mapped by
the 'inner' instance is from lowmem.
This avoids spuriously zapped kmap-atomic ptes and turns hard to find
crashes into clear asserts at the bug site.
Problem is, a get_zeroed_page(GFP_KERNEL) from interrupt context will trigger
this check if non-irq code on this CPU holds a KM_USER0 mapping. But that
get_zeroed_page() will never be altering the kmap slot anyway due to the
GFP_KERNEL.
Cc: Christoph Lameter <clameter@sgi.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>
Acked-by: Satyam Sharma <satyam@infradead.org>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
[MIPS] Fix aliasing bug in copy_user_highpage.
[MIPS] IP22: fix wrong argument order
[MIPS] IP22: Fix wrong check for second HPC
[MIPS] Ocelot: remove remaining bits
[MIPS] TLB: Fix instruction bitmasks
[MIPS] R10000: Fix wrong test in dma-default.c
[MIPS] Provide empty irq_enable_hazard definition for legacy and R1 cores.
[MIPS] Sibyte: Remove broken dependency on EXPERIMENTAL from SIBYTE_SB1xxx_SOC.
[MIPS] Kconfig: whitespace cleanup.
[MIPS] PCI: Set need_domain_info if controller domain index is non-zero.
[MIPS] BCM1480: Fix computation of interrupt mask address register.
[MIPS] i8259: Add disable method.
[MIPS] tty: add the new ioctls and definitions.
Copy_user_highpage was written assuming it was only being called for
breaking COW pages in which case the source page isn't cached as in
marked cachable under it kernel virtual address. If it is called anyway
the aliasing avoidance strategy implemented by kmap_coherent will fail.
Avoid the use of kmap_coherent for pages marked dirty and to avoid
another instance of this sort of bug, place a BUG_ON in kmap_coherent.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fix wrong argument order; this is just a minimal fix for the half baked
redadb/writeb() conversion.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Wrong check for the second hpc on fullhouse machines, caused DBEs on
SGI Indys
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
CC arch/mips/sibyte/bcm1480/irq.o
arch/mips/sibyte/bcm1480/irq.c: In function 'bcm1480_mask_irq':
arch/mips/sibyte/bcm1480/irq.c:112: warning: cast to pointer from integer of different size
arch/mips/sibyte/bcm1480/irq.c:114: warning: cast to pointer from integer of different size
arch/mips/sibyte/bcm1480/irq.c: In function 'bcm1480_unmask_irq':
arch/mips/sibyte/bcm1480/irq.c:130: warning: cast to pointer from integer of different size
arch/mips/sibyte/bcm1480/irq.c:132: warning: cast to pointer from integer of different size
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This patch adds the Intel Tolapai LPC and SMBus Controller DID's.
Signed-off-by: Jason Gaston <jason.d.gaston@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
pcibios_get_irq_routing_table is an exported symbol. This results in a
modpost warning:
WARNING: vmlinux.o(.text+0xdca51): Section mismatch: reference to .init.text:pcibios_fixup_bus (between 'pci_scan_child_bus' and 'pci_scan_bus_parented')
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
In the case when an nmi gets stucks the endflag stays equal to zero.
This causes the busy looping on other cpus to continue, even though the
nmi test is done.
On my machine with out the change below the system would hang right
after check_nmi_watchdog(). The change below just sets endflag prior to
checking if the test was successful or not.
Signed-off-by: Daniel Walker <dwalker@mvista.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The CLFLUSH for the modified code line in text_poke was supposed
to speed up CPU recovery. Unfortunately it seems to cause hangs
on some VIA C3s (at least on VIA Esther Model 10 Stepping 9)
Remove it.
Thanks to Stefan Becker for reporting/testing.
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix the NMI watchdog on Intel CoreDuo processor where the kernel would
get stuck during boot. The issue is related to errata AE49, where the
PERFEVTSEL1 counter does not have a working enable bit. Thus it is not
possible to use it for NMI.
The patch creates a dedicated wd_ops for CoreDuo which falls back to
using PERFEVTSEL0. The other Intel processors supporting the
architectural PMU will keep on using PERFEVTSEL1 as this allows other
subsystems, such as perfmon, to use PERFEVTSEL0 for PEBS monitoring in
particular. Bug initially reported by Daniel Walker.
AK: Added comments
Signed-off-by: Stephane Eranian <eranian@hpl.hp.com>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When PTRACE_SYSCALL was used and then PTRACE_DETACH is used, the
TIF_SYSCALL_TRACE flag is left set on the formerly-traced task. This
means that when a new tracer comes along and does PTRACE_ATTACH, it's
possible he gets a syscall tracing stop even though he's never used
PTRACE_SYSCALL. This happens if the task was in the middle of a system
call when the second PTRACE_ATTACH was done. The symptom is an
unexpected SIGTRAP when the tracer thinks that only SIGSTOP should have
been provoked by his ptrace calls so far.
A few machines already fixed this in ptrace_disable (i386, ia64, m68k).
But all other machines do not, and still have this bug. On x86_64, this
constitutes a regression in IA32 compatibility support.
Since all machines now use TIF_SYSCALL_TRACE for this, I put the
clearing of TIF_SYSCALL_TRACE in the generic ptrace_detach code rather
than adding it to every other machine's ptrace_disable.
Signed-off-by: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
[MIPS] Ocelot: remove remaining bits
[MIPS] TLB: Fix instruction bitmasks
[MIPS] R10000: Fix wrong test in dma-default.c
[MIPS] Provide empty irq_enable_hazard definition for legacy and R1 cores.
[MIPS] Sibyte: Remove broken dependency on EXPERIMENTAL from SIBYTE_SB1xxx_SOC.
[MIPS] Kconfig: whitespace cleanup.
[MIPS] PCI: Set need_domain_info if controller domain index is non-zero.
[MIPS] BCM1480: Fix computation of interrupt mask address register.
[MIPS] i8259: Add disable method.
[MIPS] tty: add the new ioctls and definitions.
