aboutsummaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2008-12-25[S390] Add processor type march=z10 and a processor type safety check.Martin Schwidefsky
This patch adds the code generation option for IBM System z10 and adds a check in head[31,64].S to prevents the execution of a kernel compiled for a new processor type on an old machine. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] remove warnings with functions ending in BUGMartin Schwidefsky
Functions which end in a BUG() statement and skip the return statement cause compile warnings on s390, e.g.: mm/bootmem.c: In function 'mark_bootmem': mm/bootmem.c:321: warning: control reaches end of non-void function To avoid the warning add an endless loop to the BUG() macro. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] mark disabled_wait as noreturn functionHeiko Carstens
disabled_wait() won't return, so add an __attribute__((noreturn)). This will remove a false positive finding which our internal code checker reports. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] cio: update sac valuesPeter Oberparleiter
Values for the sac field have changed - update code accordingly. Signed-off-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] remove ptrace warning on 31 bit.Martin Schwidefsky
A kernel compile on 31 bit gives the following warnings in ptrace.c: arch/s390/kernel/ptrace.c: In function 'peek_user': arch/s390/kernel/ptrace.c:207: warning: unused variable 'dummy' arch/s390/kernel/ptrace.c: In function 'poke_user': arch/s390/kernel/ptrace.c:315: warning: unused variable 'dummy' Getting rid of the dummy variables removes the warnings. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] ftrace: function tracer backend for s390Heiko Carstens
This implements just the basic function tracer (_mcount) backend for s390. The dynamic variant will come later. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] service level interface.Martin Schwidefsky
Add a new proc interface /proc/service_levels that allows any code to report a relevant service level, e.g. the microcode level of devices, the service level of the hypervisor, etc. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] qdio: rework debug feature loggingJan Glauber
- make qdio_trace a per device view - remove s390dbf exceptions - remove CONFIG_QDIO_DEBUG, not needed anymore if we check for the level before calling sprintf - use snprintf for dbf entries - add start markers to see if the dbf view wrapped - add a global error view for all queues Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] qdio: fix qeth port count detectionJan Glauber
qeth needs to get the port count information before qdio has allocated a page for the chsc operation. Extend qdio_get_ssqd_desc() to store the data in the specified structure. Signed-off-by: Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] zcrypt: Use of Thin InterruptsFelix Beck
When the machine supports AP adapter interrupts polling will be switched off at module initialization and the driver will work in interrupt mode. Signed-off-by: Felix Beck <felix.beck@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] Move stfle to header file.Heiko Carstens
stfle will be needed by the ap_bus module to figure out wether the AP queue adapter interruption facility is installed. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] convert s390 to generic IPI infrastructureHeiko Carstens
Since etr/stp don't need the old smp_call_function semantics anymore we can convert s390 to the generic IPI infrastructure. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] serialize stp/etr workMartin Schwidefsky
The work function dispatched with schedule_work() can be run twice on different cpus because run_workqueue clears the WORK_STRUCT_PENDING bit and then executes the function. Another cpu can call schedule_work() again and run the work function a second time before the first call is completed. This patch serialized the etr and stp work function with a mutex. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] convert etr/stp to stop_machine interfaceHeiko Carstens
This converts the etr and stp code to the new stop_machine interface which allows to synchronize all cpus without allocating any memory. This way we get rid of the only reason why we haven't converted s390 to the generic IPI interface yet. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] introduce vdso on s390Martin Schwidefsky
Add a vdso to speed up gettimeofday and clock_getres/clock_gettime for CLOCK_REALTIME/CLOCK_MONOTONIC. Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] arch_setup_additional_pages argumentsMartin Schwidefsky
arch_setup_additional_pages currently gets two arguments, the binary format descripton and an indication if the process uses an executable stack or not. The second argument is not used by anybody, it could be removed without replacement. What actually does make sense is to pass an indication if the process uses the elf interpreter or not. The glibc code will not use anything from the vdso if the process does not use the dynamic linker, so for statically linked binaries the architecture backend can choose not to map the vdso. Acked-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] cpu topology: dont destroy cpu sets on topology changeHeiko Carstens
Call rebuild_sched_domains instead of arch_reinit_sched_domains if cpu topology changes. This leaves cpu sets alone which otherwise would be destroyed. If and how it makes sense to define cpu sets on a virtualized architecture is another question. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] audit: get s390 ret_from_fork in sync with other architecturesAl Viro
On s390 we have ret_from_fork jump not to the "do all work we normally do on return from syscall" as on x86, ppc, etc., but to the "do all such work except audit". Historical reasons - the codepath triggered when we have AUDIT process flag set is separated from the normall one and they converge at sysc_return, which is the common part of post-syscall work. And does not include calling audit_syscall_exit() - that's done in the end of sysc_tracesys path, just before that path jumps to sysc_return. IOW, the child returning from fork()/clone()/vfork() doesn't call audit_syscall_exit() at all, so no matter what we do with its audit context, we are not going to see the audit entry. The fix is simple: have ret_from_fork go to the point just past the call of sys_.... in the 'we have AUDIT flag set' path. There we have (64bit variant; for 31bit the situation is the same): sysc_tracenogo: tm __TI_flags+7(%r9),(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT) jz sysc_return la %r2,SP_PTREGS(%r15) # load pt_regs larl %r14,sysc_return # return point is sysc_return jg do_syscall_trace_exit which is precisely what we need - check the flag, bugger off to sysc_return if not set, otherwise call do_syscall_trace_exit() and bugger off to sysc_return. r9 has just been properly set by ret_from_fork itself, so we are fine. Tested on s390x, seems to work fine. WARNING: it's been about 16 years since my last contact with 3X0 assembler[1], so additional review would be very welcome. I don't think I've managed to screw it up, but... [1] that *was* in another country and besides, the box is dead... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25[S390] cpu topology: fix cpu_core_map initializationHeiko Carstens
Common code doesn't call arch_update_cpu_topology() anymore on cpu hotplug. But our architecture backend relied on that in order to update the cpu_core_map. For machines without cpu topology support this leads uninitialized cpu_core_maps for later on added cpus. To solve this just initialize the maps with cpu_possible_map, since that will be always valid for machines without topology support. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
2008-12-25Merge branches 'tracing/ftrace', 'tracing/hw-branch-tracing' and ↵Ingo Molnar
'tracing/ring-buffer'; commit 'v2.6.28' into tracing/core
2008-12-25Merge branch 'x86/tsc' into tracing/coreIngo Molnar
Merge it to resolve this incidental conflict between the BTS fixes/cleanups and changes in x86/tsc: Conflicts: arch/x86/kernel/cpu/intel.c
2008-12-25Merge branches 'x86/pat2' and 'x86/fpu'; commit 'v2.6.28' into x86/coreIngo Molnar
2008-12-25x86: traps.c replace #if CONFIG_X86_32 with #ifdef CONFIG_X86_32Jaswinder Singh
Impact: cleanup, avoid warning on X86_64 Fixes this warning on X86_64: CC arch/x86/kernel/traps.o arch/x86/kernel/traps.c:695:5: warning: "CONFIG_X86_32" is not defined Signed-off-by: Jaswinder Singh <jaswinder@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-25Merge branch 'topic/asoc' into to-pushTakashi Iwai
2008-12-25tracing/ftrace: don't trace on early stage of a secondary cpu boot, v3Frederic Weisbecker
Impact: fix a crash/hard-reboot on certain configs while enabling cpu runtime On some archs, the boot of a secondary cpu can have an early fragile state. On x86-64, the pda is not initialized on the first stage of a cpu boot but it is needed to get the cpu number and the current task pointer. This data is needed during tracing. As they were dereferenced at this stage, we got a crash while tracing a cpu being enabled at runtime. Some other archs like ia64 can have such kind of issue too. Changes on v2: We dropped the previous solution of a per-arch called function to guess the current state of a cpu. That could slow down the tracing. This patch removes the -pg flag on arch/x86/kernel/cpu/common.c where the low level cpu boot functions exist, on start_secondary() and a helper function used at this stage. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Acked-by: Steven Rostedt <srostedt@redhat.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-25Merge branch 'next' into for-linusJames Morris
2008-12-25crypto: crc32c-intel - Switch to shashHerbert Xu
This patch changes crc32c-intel to the new shash interface. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-25crypto: crc32c-intel - Update copyright headKent Liu
The original copyright head for crc32c-intel.c is incorrect. Please merge the patch to update it. Signed-Off-By: Kent Liu <kent.liu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2008-12-24Revert "x86: disable X86_PTRACE_BTS"Ingo Molnar
This reverts commit 40f15ad8aadff5ebb621b17a6f303ad2cd3f847d. The CONFIG_X86_PTRACE_BTS bugs have been fixed via: c5dee61: x86, bts: memory accounting bf53de9: x86, bts: add fork and exit handling Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-24Merge branch 'linus' into tracing/hw-branch-tracingIngo Molnar
2008-12-24Merge branch 'x86-fixes-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86: disable X86_PTRACE_BTS
2008-12-24x86: disable X86_PTRACE_BTSIngo Molnar
there's a new ptrace arch level feature in .28: config X86_PTRACE_BTS bool "Branch Trace Store" it has broken fork() handling: the old DS area gets copied over into a new task without clearing it. Fixes exist but they came too late: c5dee61: x86, bts: memory accounting bf53de9: x86, bts: add fork and exit handling and are queued up for v2.6.29. This shows that the facility is still not tested well enough to release into a stable kernel - disable it for now and reactivate in .29. In .29 the hardware-branch-tracer will use the DS/BTS facilities too - hopefully resulting in better code. Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-24x86: PAT: fix address types in track_pfn_vma_new()H. Peter Anvin
Impact: cleanup, fix warning This warning: arch/x86/mm/pat.c: In function track_pfn_vma_copy: arch/x86/mm/pat.c:701: warning: passing argument 5 of follow_phys from incompatible pointer type Triggers because physical addresses are resource_size_t, not u64. This really matters when calling an interface like follow_phys() which takes a pointer to a physical address -- although on x86, being littleendian, it would generally work anyway as long as the memory region wasn't completely uninitialized. Signed-off-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-12-23parisc: disable UP-optimized flush_tlb_mmKyle McMartin
flush_tlb_mm's "optimized" uniprocessor case of allocating a new context for userspace is exposing a race where we can suddely return to a syscall with the protection id and space id out of sync, trapping on the next userspace access. Debugged-by: James Bottomley <James.Bottomley@HansenPartnership.com> Tested-by: Helge Deller <deller@gmx.de> Signed-off-by: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-12-23Merge branch 'x86/irq' into x86/coreIngo Molnar
2008-12-23Merge branch 'x86/iommu' into x86/coreIngo Molnar
2008-12-23Merge branch 'x86/tsc' into x86/coreIngo Molnar
2008-12-23Merge branch 'x86/ptrace' into x86/tscIngo Molnar
Conflicts: arch/x86/kernel/cpu/intel.c
2008-12-23Merge branches 'x86/apic', 'x86/cleanups', 'x86/cpufeature', ↵Ingo Molnar
'x86/crashdump', 'x86/debug', 'x86/defconfig', 'x86/detect-hyper', 'x86/doc', 'x86/dumpstack', 'x86/early-printk', 'x86/fpu', 'x86/idle', 'x86/io', 'x86/memory-corruption-check', 'x86/microcode', 'x86/mm', 'x86/mtrr', 'x86/nmi-watchdog', 'x86/pat2', 'x86/pci-ioapic-boot-irq-quirks', 'x86/ptrace', 'x86/quirks', 'x86/reboot', 'x86/setup-memory', 'x86/signal', 'x86/sparse-fixes', 'x86/time', 'x86/uv' and 'x86/xen' into x86/core
2008-12-23Merge branch 'x86/apic' into x86/irqIngo Molnar
Conflicts: arch/x86/kernel/apic.c
2008-12-23Merge commit 'v2.6.28-rc9' into x86/apicIngo Molnar
2008-12-23powerpc/32: Wire up the trampoline code for kdumpDale Farnsworth
Wire up the trampoline code for ppc32 to relay exceptions from the vectors at address 0 to vectors at address 32MB, and modify Kconfig to enable Kdump support for all classic powerpcs. Signed-off-by: Dale Farnsworth <dale@farnsworth.org> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-23powerpc/32: Add the ability for a classic ppc kernel to be loaded at 32MDale Farnsworth
Add the ability for a classic ppc kernel to be loaded at an address of 32MB. This done by fixing a few places that assume we are loaded at address 0, and by changing several uses of KERNELBASE to use PAGE_OFFSET, instead. Signed-off-by: Dale Farnsworth <dale@farnsworth.org> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-23powerpc/32: Allow __ioremap on RAM addresses for kdump kernelAnton Vorontsov
While for debugging it is good to catch bogus users of ioremap, though for kdump support it is more convenient to use __ioremap for copy_oldmem_page() (exactly as we do for PPC64 currently). Note that copy_oldmem_page() calls __ioremap with flags set to '0', so it should be safe with the regard to the caches. The other option is to use kmap_atomic_pfn()[1], but it will not work for kernels compiled without HIGHMEM. That is, on a board with 256MB RAM and crashkernel=64M@32M case, the !HIGHMEM capturing kernel maps 0-96M range, which does not include all the memory needed to capture the dump. And, obviously, accessing anything upper than 96M will cause faults. [1] http://ozlabs.org/pipermail/linuxppc-dev/2007-November/046747.html Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-23powerpc/32: Setup OF properties for kdumpDale Farnsworth
Refactor the setting of kdump OF properties, moving the common code from machine_kexec_64.c to machine_kexec.c where it can be used on both ppc64 and ppc32. This will be needed for kdump to work on ppc32 platforms. Signed-off-by: Dale Farnsworth <dale@farnsworth.org> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-23powerpc/32/kdump: Implement crash_setup_regs() using ppc_save_regs()Anton Vorontsov
This replaces the dummy crash_setup_regs function with full-fledged crash_setup_regs implementation. On PPC32 we simply use the new ppc_save_regs function to dump the registers. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-23powerpc: Prepare xmon_save_regs for use with kdumpAnton Vorontsov
Today the arch/powerpc/xmon/setjmp.S file contains only the xmon_save_regs function. We want to use it for kdump purposes, so let's move the file into arch/powerpc/kernel/ and give the function a more generic name (ppc_save_regs). Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-23powerpc: Remove default kexec/crash_kernel ops assignmentsAnton Vorontsov
Default ops are implicit now. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-23powerpc: Make default kexec/crash_kernel ops implicitAnton Vorontsov
This removes the need for each platform to specify default kexec and crash kernel ops, thus effectively adds a working kexec support for most 6xx/7xx/7xxx-based boards. Platforms that can't cope with default ops will explode in some weird way (a hang or reboot is most likely), which means that the board's kexec support should be fixed or blacklisted via dummy _prepare callback returning -ENOSYS. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
2008-12-23powerpc: Setup OF properties for ppc32 kexecDale Farnsworth
Refactor the setting of kexec OF properties, moving the common code from machine_kexec_64.c to machine_kexec.c where it can be used on both ppc64 and ppc32. This is needed for kexec to work on ppc32 platforms. Signed-off-by: Dale Farnsworth <dale@farnsworth.org> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Signed-off-by: Paul Mackerras <paulus@samba.org>