- 30 Apr, 2008 14 commits
-
-
Martin Schwidefsky authored
After the PT_IEEE_IP hack has been removed s390 can now use the common code sys_ptrace function. Signed-off-by:Martin Schwidefsky <schwidefsky@de.ibm.com>
-
Martin Schwidefsky authored
The self referential PT_IEEE_IP ptrace peek & poke calls have been broken for that last 6 years. For peek the code always returns 0 instead of the last ieee fault and for poke the code does nothing. Since nobody noticed the code seems to be superfluous. So lets remove it. Cc: Christoph Hellwig <hch@infradead.org> Signed-off-by: -
Heiko Carstens authored
Convert s390 to SPARSEMEM and SPARSEMEM_VMEMMAP. We do a select of SPARSEMEM_VMEMMAP since it is configurable. This is because SPARSEMEM without SPARSEMEM_VMEMMAP gives us a hell of broken include dependencies that I don't want to fix. Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by:
-
Gerald Schaefer authored
This adds hugetlbfs support on System z, using both hardware large page support if available and software large page emulation on older hardware. Shared (large) page tables are implemented in software emulation mode, by using page->index of the first tail page from a compound large page to store page table information. Signed-off-by:
Gerald Schaefer <geraldsc@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
From: Heiko Carstens <heiko.carstens@de.ibm.com> From: Carsten Otte <cotte@de.ibm.com> This lets us use defines for the magic bits in machine flags instead of using plain numbers all over the place. In addition on newer machines features/facilities are indicated by the result of the stfl instruction. So we use these bits instead of trying to execute new instructions and check wether we get an exception or not. Also the mvpg instruction is always available when in zArch mode, whereas the idte instruction is only available in zArch mode. This results in some minor optimizations. Signed-off-by:
Carsten Otte <cotte@de.ibm.com> Signed-off-by:
-
Heiko Carstens authored
Always use clear_table to initialise page tables. The overlapping memcpy is just a leftover of a previous version that wasn't fully converted to clear_table. Signed-off-by:
-
Heiko Carstens authored
Signed-off-by:
-
Heiko Carstens authored
arch/s390/lib/uaccess_mvcos.c:166: warning: 'strnlen_user_mvcos' defined but not used arch/s390/lib/uaccess_mvcos.c:186: warning: 'strncpy_from_user_mvcos' defined but not used Signed-off-by:
-
Heiko Carstens authored
When we get a notification that cpu topology changed, we schedule a work struct which just calls arch_reinit_sched_domains. This function in turn calls get_online_cpus() which results int the lockdep warning below. After all it turnded out that it's not legal to call get_online_cpus() from the context of a multi-threaded work queue. It could deadlock this way: process 0 (events/cpu-x): -> run_workqueue -> removes my work_struct from the work queue -> calls work_struct->fn -> get_online_cpus() -> locks on cpu_hotplug.lock since process 1 below is doing cpu hotplug process 1: -> cpu_down (for cpu-x) -> cpu_hotplug_begin (holds cpu_hotplug.lock now) -> cpu-x dead -> notifier_call_chain with CPU_DEAD -> cleanup_workqueue_thread -> flush_cpu_workqueue (succeeds) -> kthread_stop for events/cpu-x -> now kthread_stop waits for my work_struct to complete from within process 0. -> dead. A single threaded workqueue wouldn't have such problems, however there is no such common queue available and it's not worth to create one for the very rare calls to arch_reinit_sched_domains. So we just create a kernel thread from our work struct which calls arch_reinit_sched_domains and are done with it. Thanks to Oleg Nesterov and Peter Zijlstra for helping me figuring out that this isn't a false positive lockdep warning: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.25-03562-g3dc50637-dirty #12 ------------------------------------------------------- events/3/14 is trying to acquire lock: (&cpu_hotplug.lock){--..}, at: [<0000000000076094>] get_online_cpus+0x50/0x78 but task is already holding lock: (topology_work){--..}, at: [<0000000000059cde>] run_workqueue+0x106/0x278 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (topology_work){--..}: [<000000000006fc74>] __lock_acquire+0x1010/0x111c [<000000000006fe40>] lock_acquire+0xc0/0xf8 [<0000000000059d48>] run_workqueue+0x170/0x278 [<0000000000059edc>] worker_thread+0x8c/0xf0 [<000000000005f5bc>] kthread+0x68/0xa0 [<000000000001a33e>] kernel_thread_starter+0x6/0xc [<000000000001a338>] kernel_thread_starter+0x0/0xc -> #1 (events){--..}: [<000000000006fc74>] __lock_acquire+0x1010/0x111c [<000000000006fe40>] lock_acquire+0xc0/0xf8 [<000000000005a23c>] cleanup_workqueue_thread+0x60/0xa8 [<00000000003b2ab8>] workqueue_cpu_callback+0xbc/0x170 [<00000000003bba80>] notifier_call_chain+0x5c/0xa4 [<00000000000655a2>] __raw_notifier_call_chain+0x26/0x38 [<00000000000655e2>] raw_notifier_call_chain+0x2e/0x40 [<0000000000075e00>] cpu_down+0x228/0x31c [<00000000003b1dd8>] store_online+0x64/0xb8 [<00000000001e7128>] sysdev_store+0x48/0x58 [<0000000000121cd2>] sysfs_write_file+0x126/0x1c0 [<00000000000c1944>] vfs_write+0xb0/0x15c [<00000000000c20e6>] sys_write+0x56/0x88 [<0000000000027a68>] sys32_write+0x34/0x4c [<0000000000023f70>] sysc_noemu+0x10/0x16 [<0000000077f3f186>] 0x77f3f186 -> #0 (&cpu_hotplug.lock){--..}: [<000000000006fa84>] __lock_acquire+0xe20/0x111c [<000000000006fe40>] lock_acquire+0xc0/0xf8 [<00000000003b701c>] mutex_lock_nested+0xd0/0x364 [<0000000000076094>] get_online_cpus+0x50/0x78 [<000000000003a03e>] arch_reinit_sched_domains+0x26/0x58 [<000000000002700e>] topology_work_fn+0x26/0x34 [<0000000000059d4e>] run_workqueue+0x176/0x278 [<0000000000059edc>] worker_thread+0x8c/0xf0 [<000000000005f5bc>] kthread+0x68/0xa0 [<000000000001a33e>] kernel_thread_starter+0x6/0xc [<000000000001a338>] kernel_thread_starter+0x0/0xc other info that might help us debug this: 2 locks held by events/3/14: #0: (events){--..}, at: [<0000000000059cde>] run_workqueue+0x106/0x278 #1: (topology_work){--..}, at: [<0000000000059cde>] run_workqueue+0x106/0x278 stack backtrace: CPU: 3 Not tainted 2.6.25-03562-g3dc50637 -dirty #12 Process events/3 (pid: 14, task: 000000002fb04038, ksp: 000000002fb0bd70) 0400000000000000 000000002fb0ba40 0000000000000002 0000000000000000 000000002fb0bae0 000000002fb0ba58 000000002fb0ba58 0000000000016488 0000000000000000 000000002fb0bd70 0000000000000000 0000000000000000 000000002fb0ba40 000000000000000c 000000002fb0ba40 000000002fb0bab0 00000000003c99e0 0000000000016488 000000002fb0ba40 000000002fb0ba90 Call Trace: ([<00000000000163fc>] show_trace+0x138/0x158) [<00000000000164e2>] show_stack+0xc6/0xf8 [<0000000000016624>] dump_stack+0xb0/0xc0 [<000000000006cd36>] print_circular_bug_tail+0xa2/0xb4 [<000000000006fa84>] __lock_acquire+0xe20/0x111c [<000000000006fe40>] lock_acquire+0xc0/0xf8 [<00000000003b701c>] mutex_lock_nested+0xd0/0x364 [<0000000000076094>] get_online_cpus+0x50/0x78 [<000000000003a03e>] arch_reinit_sched_domains+0x26/0x58 [<000000000002700e>] topology_work_fn+0x26/0x34 [<0000000000059d4e>] run_workqueue+0x176/0x278 [<0000000000059edc>] worker_thread+0x8c/0xf0 [<000000000005f5bc>] kthread+0x68/0xa0 [<000000000001a33e>] kernel_thread_starter+0x6/0xc [<000000000001a338>] kernel_thread_starter+0x0/0xc INFO: lockdep is turned off. Cc: Oleg Nesterov <oleg@tv-sign.ru> Cc: Peter Zijlstra <peterz@infradead.org> Signed-off-by: -
Heiko Carstens authored
This exposes the core siblings to user space via sysfs. Signed-off-by: -
Mathieu Desnoyers authored
Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> CC: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Heiko Carstens authored
Signed-off-by:
-
Heiko Carstens authored
On some smp sysfs store attributes get_online_cpus() may block on cpu_hotplug.lock, but we hold already smp_cpu_state_mutex. Since the locking order on cpu hotplug via arch_update_cpu_topology is inverse this might lead to deadlocks. So make sure locking order is always the same. Signed-off-by:
-
Heiko Carstens authored
This is where it should be and we can get rid of some externs and a static inline function. Signed-off-by:
-
- 29 Apr, 2008 26 commits
-
-
Alex Chiang authored
Legacy HP ia64 platforms currently cannot provide /proc/cpuinfo/physical_id due to legacy SAL/PAL implementations. However, that physical topology information can be obtained via ACPI. Provide an interface that gives ACPI one last chance to provide physical_id for these legacy platforms. This logic only comes into play iff: - ACPI actually provides slot information for the CPU - we lack a valid socket_id Otherwise, we don't do anything. Since x86 uses the ACPI processor driver as well, we provide a nop stub function for arch_fix_phys_package_id() in asm-x86/topology.h Signed-off-by:
Alex Chiang <achiang@hp.com> Signed-off-by:
Tony Luck <tony.luck@intel.com>
-
Jean Delvare authored
Based on earlier work by Jon Smirl and Jochen Friedrich. Update most new-style i2c drivers to use standard module aliasing instead of the old driver_name/type driver matching scheme. I've left the video drivers apart (except for SoC camera drivers) as they're a bit more diffcult to deal with, they'll have their own patch later. Signed-off-by:Jean Delvare <khali@linux-fr.org> Cc: Jon Smirl <jonsmirl@gmail.com> Cc: Jochen Friedrich <jochen@scram.de>
-
Alex Chiang authored
Commit 113134fc changed the flow of control when calling PAL_LOGICAL_TO_PHYSICAL and SAL_PHYSICAL_ID_INFO. With the change, if a platform did not implement the latter, a useless printk would appear in the boot log: ia64_sal_pltid failed with -1 So let's check the return code and only printk on a true error, and do not print anything in the unimplemented case. While we're in there, clean up some stylistic issues too. Signed-off-by:
-
Dean Nelson authored
Enable the uncached allocator to allocate multiple pages of contiguous uncached memory. Signed-off-by:
Dean Nelson <dcn@sgi.com> Signed-off-by:
-
Hidetoshi Seto authored
If "max_purges" from PAL is 0, it actually means 1. However it was not handled later when a hot-added cpu pass the max_purges from PAL. This makes systems easy to go BUG_ON(). Signed-off-by:
Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by:
-
Russell King authored
The referenced commit changed the order such that the CPU code was initialised before MFP, resulting in unregistered MFP sysfs objects being referenced. Reverse the link order of these so MFP is initialised before the CPU code. Signed-off-by:Russell King <rmk+kernel@arm.linux.org.uk>
-
Christoph Lameter authored
Signed-off-by:
Christoph Lameter <clameter@sgi.com> Cc: Miles Bader <miles@gnu.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
New version that does not preserve the marker. Arch maintainers indicate that the marker functionality is is not needed anymore. Note you may simplify the s390 asm-offsets.c code further if you use the OFFSET() macro instead of the DEFINE. See kbuild.h Signed-off-by:
-
Christoph Lameter authored
s390 has a strange marker in DEFINE. Undefine the DEFINE from kbuild.h and define it the way s390 wants it to preserve things as they were. May be good if the arch maintainer could go over this and check if this workaround is really necessary. Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Signed-off-by:
-
Christoph Lameter authored
Use the macros in kbuild.h Signed-off-by:
-
Christoph Lameter authored
Use the macros provided in kbuild.h Signed-off-by:
-
Christoph Lameter authored
Drop the macro definitions in asm-offsets_*.c and use kbuild.h Signed-off-by:
Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Harvey Harrison authored
Unaligned access is ok for the following arches: cris, m68k, mn10300, powerpc, s390, x86 Arches that use the memmove implementation for native endian, and the byteshifting for the opposite endianness. h8300, m32r, xtensa Packed struct for native endian, byteshifting for other endian: alpha, blackfin, ia64, parisc, sparc, sparc64, mips, sh m86knommu is generic_be for Coldfire, otherwise unaligned access is ok. frv, arm chooses endianness based on compiler settings, uses the byteshifting versions. Remove the unaligned trap handler from frv as it is now unused. v850 is le, uses the byteshifting versions for both be and le. Remove the now unused asm-generic implementation. Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Acked-by:
-
