- Sep 20, 2011
-
-
Benjamin Herrenschmidt authored
It was preventing the global early debug selection whenever KVM was enabled instead of only preventing the 440 specific one. Signed-off-by:Benjamin Herrenschmidt <benh@kernel.crashing.org>
-
Anton Blanchard authored
The icswx code introduced an A-B B-A deadlock: CPU0 CPU1 ---- ---- lock(&anon_vma->mutex); lock(&mm->mmap_sem); lock(&anon_vma->mutex); lock(&mm->mmap_sem); Instead of using the mmap_sem to keep mm_users constant, take the page table spinlock. Signed-off-by:Anton Blanchard <anton@samba.org> Cc: <stable@kernel.org> Signed-off-by:
-
Anton Blanchard authored
If we echo an address the hypervisor doesn't like to /sys/devices/system/memory/probe we oops the box: # echo 0x10000000000 > /sys/devices/system/memory/probe kernel BUG at arch/powerpc/mm/hash_utils_64.c:541! The backtrace is: create_section_mapping arch_add_memory add_memory memory_probe_store sysdev_class_store sysfs_write_file vfs_write SyS_write In create_section_mapping we BUG if htab_bolt_mapping returned an error. A better approach is to return an error which will propagate back to userspace. Rerunning the test with this patch applied: # echo 0x10000000000 > /sys/devices/system/memory/probe -bash: echo: write error: Invalid argument Signed-off-by:
-
Anton Blanchard authored
While converting code to use for_each_node_by_type I noticed a number of coding style issues. Signed-off-by:
-
Anton Blanchard authored
Use for_each_node_by_type instead of open coding it. Signed-off-by:
-
Anton Blanchard authored
During memory hotplug testing, I got the following warning: ERROR: Bad of_node_put() on /memory@0 of_node_release kref_put of_node_put of_find_node_by_type hot_add_node_scn_to_nid hot_add_scn_to_nid memory_add_physaddr_to_nid ... of_find_node_by_type() loop does the of_node_put for us so we only need the handle the case where we terminate the loop early. As suggested by Stephen Rothwell we can do the of_node_put unconditionally outside of the loop since of_node_put handles a NULL argument fine. Signed-off-by:
-
Anton Blanchard authored
We have two identical definitions of RECLAIM_DISTANCE, looks like the patch got applied twice. Remove one. Signed-off-by:
-
Anton Blanchard authored
On big POWER7 boxes we see large amounts of CPU time in system processes like workqueue and watchdog kernel threads. We currently rebalance the entire machine each time a task goes idle and this is very expensive on large machines. Disable newidle balancing at the node level and rely on the scheduler tick to rebalance across nodes. Signed-off-by:
-
Anton Blanchard authored
The largest POWER7 boxes have 32 nodes. SD_NODES_PER_DOMAIN groups nodes into chunks of 16 and adds a global balancing domain (SD_ALLNODES) above it. If we bump SD_NODES_PER_DOMAIN to 32, then we avoid this extra level of balancing on our largest boxes. Signed-off-by:
-
Anton Blanchard authored
When chasing a performance issue on ppc64, I noticed tasks communicating via a pipe would often end up on different nodes. It turns out SD_WAKE_AFFINE is not set in our node defition. Commit 9fcd18c9 (sched: re-tune balancing) enabled SD_WAKE_AFFINE in the node definition for x86 and we need a similar change for ppc64. I used lmbench lat_ctx and perf bench pipe to verify this fix. Each benchmark was run 10 times and the average taken. lmbench lat_ctx: before: 66565 ops/sec after: 204700 ops/sec 3.1x faster perf bench pipe: before: 5.6570 usecs after: 1.3470 usecs 4.2x faster Signed-off-by:
-
- Sep 19, 2011
-
-
Hector Martin authored
Add a new udbg driver for the PS3 gelic Ehthernet device. This driver shares only a few stucture and constant definitions with the gelic Ethernet device driver, so is implemented as a stand-alone driver with no dependencies on the gelic Ethernet device driver. Signed-off-by:
Hector Martin <hector@marcansoft.com> Signed-off-by:
Andre Heider <a.heider@gmail.com> Signed-off-by:
Geoff Levand <geoff@infradead.org> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
Since commit 188917e1, /proc/ppc64 is a symlink to /proc/powerpc/. That means that creating /proc/ppc64/eeh will end up with a unaccessible file, that is not listed under /proc/powerpc/ and, then, not listed under /proc/ppc64/. Creating /proc/powerpc/eeh fixes that problem and maintain the compatibility intended with the ppc64 symlink. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by:
-
Arnaud Lacombe authored
This should fix the following warning: LD arch/powerpc/sysdev/xics/built-in.o WARNING: arch/powerpc/sysdev/xics/built-in.o(.text+0x1310): Section mismatch in reference from the function .icp_native_init() to the function .init.text:.icp_native_init_one_node() The function .icp_native_init() references the function __init .icp_native_init_one_node(). This is often because .icp_native_init lacks a __init annotation or the annotation of .icp_native_init_one_node is wrong. icp_native_init() is only referenced in `arch/powerpc/sysdev/xics/xics-common.c' by xics_init() which is itself marked with __init. = not built-tested = Reported-by:
Timur Tabi <timur@freescale.com> Signed-off-by:
Arnaud Lacombe <lacombar@gmail.com> Signed-off-by:
-
Anton Blanchard authored
During hotplug CPU add we get the following error: Unexpected Error (0) returned from configure-connector ibm,configure-connector returns 0 for configuration complete, so catch this and avoid the error. Signed-off-by:
-
Tang Yuantian authored
In SMP mode, the kernel would produce call trace when resumed from hibernation. The reason is when the function destroy_context is called to drop the resuming mm context, the mm->context.active is 1 which is wrong and should be zero. We pass the current->active_mm as previous mm context to function switch_mmu_context to decrease the context.active by 1. In UP mode, there is no effect. Signed-off-by:
Tang Yuantian <b29983@freescale.com> Signed-off-by:
-
Tony Breeds authored
The various port_init_hw methods of ppc4xx_pciex_hwops should have been marked __init and when I added ppc4xx_pciex_port_reset_sdr(), which is __init. This added many section mismatch warnings like: WARNING: arch/powerpc/sysdev/built-in.o(.text+0x5c68): Section mismatch in reference from the function ppc440spe_pciex_init_port_hw() to the function .init.text:ppc4xx_pciex_port_reset_sdr() The function ppc440spe_pciex_init_port_hw() references the function __init ppc4xx_pciex_port_reset_sdr(). This is often because ppc440spe_pciex_init_port_hw lacks a __init annotation or the annotation of ppc4xx_pciex_port_reset_sdr is wrong. Trivial patch to silence those warnings. Reported-By:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Tony Breeds <tony@bakeyournoodle.com> Yours Tony Signed-off-by:
-
Michael Ellerman authored
Based on a patch by Michael Ellerman <michael@ellerman.id.au> Patch was simply forward ported upstream. Jimi Xenidis <jimix@pobox.com> Signed-off-by: -
Benjamin Herrenschmidt authored
Based on a patch by Benjamin Herrenschmidt <benh@kernel.crashing.org> Modernized and slightly modified to not record erros into the nvram log since we do not have that device driver just yet. Jimi Xenidis <jimix@pobox.com> Signed-off-by: -
Jimi Xenidis authored
Some config selections were applied to the platform (reference board) when they actuall apply to the chip. Signed-off-by:
Jimi Xenidis <jimix@pobox.com> Signed-off-by:
-
Julia Lawall authored
At this point, window has not been stored anywhere, so it has to be freed before leaving the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/ ) // <smpl> @exists@ local idexpression x; statement S,S1; expression E; identifier fl; expression *ptr != NULL; @@ x = \(kmalloc\|kzalloc\|kcalloc\)(...); ... if (x == NULL) S <... when != x when != if (...) { <+...kfree(x)...+> } when any when != true x == NULL x->fl ...> ( if (x == NULL) S1 | if (...) { ... when != x when forall ( return \(0\|<+...x...+>\|ptr\); | * return ...; ) } ) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Acked-by:
Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by:
-
Scott Wood authored
u64 is used rather than phys_addr_t to keep things simple, as this is called from assembly code. Update callers to pass a 64-bit address in r3/r4. Other unused register assignments that were once parameters to machine_init are dropped. For FSL BookE, look up the physical address of the device tree from the effective address passed in r3 by the loader. This is required for situations where memory does not start at zero (due to AMP or IOMMU-less virtualization), and thus the IMA doesn't start at zero, and thus the device tree effective address does not equal the physical address. Signed-off-by:
Scott Wood <scottwood@freescale.com> Signed-off-by:
-
Jim Keniston authored
Capture more than twice as much text from the printk buffer, and compress it to fit it in the lnx,oops-log NVRAM partition. You can view the compressed text using the new (as of July 20) --unzip option of the nvram command in the powerpc-utils package. [BenH: Added select of ZLIB_DEFLATE] Signed-off-by:
Jim Keniston <jkenisto@us.ibm.com> Signed-off-by:
-
Matthew McClintock authored
Currently, the build can (very rarely) fail to build because libfdt.h has not been created or is in the process of being copied. Signed-off-by:
Matthew McClintock <msm@freescale.com> Signed-off-by:
-
Timur Tabi authored
There is one place in the MPIC driver that assumes that the cores are numbered from 0 to n-1. However, this is not true if the CPUs are not numbered sequentially. This can happen on a eight-core SOC where cores two and three are removed in the device tree. So instead of blindly looping, we iterate over the discovered CPUs and use the SMP ID as the index. This means that we no longer ask the MPIC how many CPUs there are, so we also delete mpic->num_cpus. We also catch if the number of CPUs in the SOC exceeds the number that the MPIC supports. This should never happen, of course, but it's good to be sure. Signed-off-by:
-
Becky Bruce authored
Enable hugepages on Freescale BookE processors. This allows the kernel to use huge TLB entries to map pages, which can greatly reduce the number of TLB misses and the amount of TLB thrashing experienced by applications with large memory footprints. Care should be taken when using this on FSL processors, as the number of large TLB entries supported by the core is low (16-64) on current processors. The supported set of hugepage sizes include 4m, 16m, 64m, 256m, and 1g. Page sizes larger than the max zone size are called "gigantic" pages and must be allocated on the command line (and cannot be deallocated). This is currently only fully implemented for Freescale 32-bit BookE processors, but there is some infrastructure in the code for 64-bit BooKE. Signed-off-by:
Becky Bruce <beckyb@kernel.crashing.org> Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
Arnd Bergmann authored
This iotype is only used by the legacy_serial code in powerpc, so the code should live there, rather than be compiled in for every 8250 driver. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: linuxppc-dev@lists.ozlabs.org Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: linux-serial@vger.kernel.org Acked-by:
David Daney <david.daney@cavium.com> Signed-off-by:
-
Milton Miller authored
The new get_required_mask hook name is longer than many of but not all of the prior ops. Tidy the struct initializers to align the equal signs using the local whitespace. Signed-off-by:
Milton Miller <miltonm@bga.com> Signed-off-by:
-
Milton Miller authored
Now that the generic code has dma_map_ops set, instead of having a messy ifdef & if block in the base dma_get_required_mask hook push the computation into the dma ops. If the ops fails to set the get_required_mask hook default to the width of dma_addr_t. This also corrects ibmbus ibmebus_dma_supported to require a 64 bit mask. I doubt anything is checking or setting the dma mask on that bus. Signed-off-by:
-
- Sep 15, 2011
-
-
Linus Torvalds authored
On x86-64, they were just wasteful: with the explicitly added (now unnecessary) padding, the size of the alternatives structure was 16 bytes, and an alignment of 8 bytes didn't hurt much. However, it was still silly, since the natural size and alignment for the structure is actually just 12 bytes, 4-byte aligned since commit 59e97e4d ("x86: Make alternative instruction pointers relative"). So removing the padding, and removing the extra alignment is just a good idea. On x86-32, the alignment of 4 bytes was correct, but was incorrectly hardcoded as 8 bytes in <asm/alternative-asm.h>. That header file had used to be an x86-64 only header file, but various unification efforts have made it be used for x86-32 too (ie the unification of rwlock and rwsem). That in turn caused x86-32 boot failures, because the extra alignment would result in random zero-filled words in the altinstructions section, causing oopses early at boot when doing alternative instruction replacement. So just remove all the alignment noise entirely. It's wrong, and it's unnecessary. The section itself is already properly aligned by the linker scripts, and all additions to the section had better be of the proper 12-byte format, keeping it aligned. So if the align directive were to ever make a difference, that would be an indication of a serious bug to begin with. Reported-by:
Werner Landgraf <w.landgraf@ru.r> Acked-by:
Andrew Lutomirski <luto@mit.edu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Jan Beulich authored
The numbers obtained from the hypervisor really can't ever lead to an overflow here, only the original calculation going through the order of the range could have. This avoids the (as Jeremy points outs) somewhat ugly NULL-based calculation here. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-
Ben Hutchings authored
Since GPIOLIB is optional on alpha, GENERIC_GPIO must not be selected by default. If GPIOLIB is enabled, it will select GENERIC_GPIO. See <http://bugs.debian.org/638696 > for an example of what 'def_bool y' breaks. Reported-by:
Michael Cree <mcree@orcon.net.nz> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Cc: Michael Cree <mcree@orcon.net.nz> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Al Viro authored
richard@nod.at: Fixes: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/libc.a(strrchr.o): In function `rindex': (.text+0x0): multiple definition of `strrchr' If both STATIC_LINK and UML_NET_VDE are set to "y" libc's strrchr may clash with the kernel implementation. This workaround comes originally from Jeff Dike: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494995#35 Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Richard Weinberger <richard@nod.at> Cc: Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Al Viro authored
1) take subarch-specific stuff to subarch_ptrace() 2) PTRACE_{PEEK,POKE}{TEXT,DATA} is handled by ptrace_request() just fine... Signed-off-by: -
Al Viro authored
It's 32bit-only, not 64bit-only... And while we are at it, it's set_fpxregs(), not set_fpregs()... Signed-off-by:
-
Al Viro authored
while not doing free_irq() from irq handler is commendable, kfree() on the data passed to said handler before free_irq() is Not Good(tm). Freeing the stack it's being run on is also not nice... Solution: delay actually freeing stuff. Signed-off-by:
-
Al Viro authored
... so set winch->fd to -1 before doing free_irq(), to avoid having winch_interrupt() come from/during the latter and attempt to do reactivate_fd() on something that's already gone. Signed-off-by:
-
Al Viro authored
tty->count is decremented only after ->close() had been called and several tasks can hit it in parallel. As the result, using tty->count to check if you are the last one is broken. We end up leaving line->tty not reset to NULL and the next IRQ on that sucker will blow up trying to dereference pointers from kfree'd struct tty. Fix is obvious: we need to use a counter of our own. Signed-off-by:
-
Ingo van Lil authored
Some time ago Jeff prepared 42daba31 ("uml: stop saving process FP state") for UML to stop saving the process FP state between task switches. The assumption was that since with SKAS0 every guest process runs inside a host process context the host OS will take care of keeping the proper FP state. Unfortunately this is not true for multi-threaded applications, where all guest threads share a single host process context yet all may use the FPU on their own. Although I haven't verified it I suspect things to be even worse in SKAS3 mode where all guest processes run inside a single host process. The patch reintroduces the saving and restoring of the FP context between task switches. [richard@nod.at: Ingo posted this patch in 2009, sadly it was never applied and got lost. Now in 2011 the problem was reported by Gunnar.] Signed-off-by:
Ingo van Lil <inguin@gmx.de> Signed-off-by:
<gunnarlindroth@hotmail.com> Tested-by:
-
Jonathan Neuschäfer authored
I could use out_close1, but that seems to be the code path to close the fd returned by os_create_unix_socket, and using it to close the fd returned by mkstemp might lead to some confusion, so I don't do it. Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
Commit b789ef51 ("slub: Add cmpxchg_double_slab()") tests for cmpxchg_double support in the SLUB code and it breaks UML builds with SLUB. Since UML does not support checking for CPU features, disable CMPXCHG_DOUBLE just like CMPXCHG_LOCAL is disabled for UML. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com> Reviewed-by:
Christoph Lameter <cl@linux.com> Cc: Jeff Dike <jdike@addtoit.com> Cc: Richard Weinberger <richard@nod.at> Signed-off-by:
-
