- Mar 17, 2006
-
-
Michael Ellerman authored
My patch (d7a5b2ff) to always panic if lmb_alloc() fails is broken because it checks alloc < 0, but should be checking alloc == 0. Signed-off-by:
Michael Ellerman <michael@ellerman.id.au> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
- Mar 16, 2006
-
-
Olaf Hering authored
remove warnings when building a 64bit kernel. smp_call_function triggers also with 32bit kernel. WARNING: vmlinux: duplicate symbol 'smp_call_function' previous definition was in vmlinux arch/powerpc/kernel/ppc_ksyms.c:164:EXPORT_SYMBOL(smp_call_function); arch/powerpc/kernel/smp.c:300:EXPORT_SYMBOL(smp_call_function); WARNING: vmlinux: duplicate symbol 'ioremap' previous definition was in vmlinux arch/powerpc/kernel/ppc_ksyms.c:113:EXPORT_SYMBOL(ioremap); arch/powerpc/mm/pgtable_64.c:321:EXPORT_SYMBOL(ioremap); WARNING: vmlinux: duplicate symbol '__ioremap' previous definition was in vmlinux arch/powerpc/kernel/ppc_ksyms.c:117:EXPORT_SYMBOL(__ioremap); arch/powerpc/mm/pgtable_64.c:322:EXPORT_SYMBOL(__ioremap); WARNING: vmlinux: duplicate symbol 'iounmap' previous definition was in vmlinux arch/powerpc/kernel/ppc_ksyms.c:118:EXPORT_SYMBOL(iounmap); arch/powerpc/mm/pgtable_64.c:323:EXPORT_SYMBOL(iounmap); Signed-off-by:
Olaf Hering <olh@suse.de> Signed-off-by:
-
- Feb 28, 2006
-
-
Michael Ellerman authored
Before the merge I updated create_pte_mapping() to work for iSeries, by calling iSeries_hpte_bolt_or_insert. (4c55130b) Later we changed iSeries_hpte_insert to cope with the bolting case, and called that instead from create_pte_mapping() (which was renamed to htab_bolt_mapping) (3c726f8d). Unfortunately that change introduced a subtle bug, where we pass an absolute address to iSeries_hpte_insert() where it expects a physical address. This leads to us calling phys_to_abs() twice on the physical address, which is seriously bogus. This only causes a problem if the absolute address from the first translation can be looked up again in the chunk_map, which depends on the size and layout of memory. I've seen it fail on one box, but not others. The minimal fix is to pass the physical address to iSeries_hpte_insert(). For 2.6.17 we should make phys_to_abs() BUG if we try to double-translate an address. Signed-off-by:
-
- Feb 24, 2006
-
-
R Sharada authored
native_hpte_clear has a spinlock recursion problem with the native_tlbie_lock being called twice, once in native_hpte_clear() and once within tlbie(). Fix the problem by changing the call to tlbie() in native_hpte_clear() to __tlbie(). It still supports only 4k pages for now. Signed-off-by:
R Sharada <sharada@in.ibm.com> Signed-off-by:
-
Michael Ellerman authored
For kexec we need to know the size of the MMU hash table. Currently we calculate the size once in the htab code, and then twice more in the kexec code, once using htab_hash_mask and once using ppc64_pft_size. On some machines the ppc64_pft_size calculation is broken because ppc64_pft_size is not set. So we need to fix the second calculation, but better still we should just calculate the size once and use it everywhere else. Tested on Power5 LPAR, Power4 non-LPAR and Power3. Signed-off-by:
-
- Feb 10, 2006
-
-
Jon Mason authored
This patch removes all self references and fixes references to files in the now defunct arch/ppc64 tree. I think this accomplises everything wanted, though there might be a few references I missed. Signed-off-by:
Jon Mason <jdmason@us.ibm.com> Signed-off-by:
-
- Feb 07, 2006
-
-
Michael Ellerman authored
LMB_ALLOC_ANYWHERE doesn't need to be part of the API, it's only used in lmb.c - so move it out of the header file. Signed-off-by:
-
Michael Ellerman authored
Currently most callers of lmb_alloc() don't check if it worked or not, if it ever does weird bad things will probably happen. The few callers who do check just panic or BUG_ON. So make lmb_alloc() panic internally, to catch bugs at the source. The few callers who did check the result no longer need to. The only caller that did anything interesting with the return result was careful_allocation(). For it we create __lmb_alloc_base() which _doesn't_ panic automatically, a little messy, but passable. Signed-off-by:
-
David Gibson authored
The code to mark a page as icache dirty (so that it will later be icache-dcache flushed when we try to execute from it) is duplicated in three places: flush_dcache_page() does this marking and nothing else, but clear_user_page() and copy_user_page() duplicate it, since those functions make the page icache dirty themselves. This patch makes those other functions call flush_dcache_page() instead, so the logic's all in one place. This will make life less confusing if we ever need to tweak the details of the the lazy icache flush mechanism. arch/powerpc/mm/mem.c | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) Signed-off-by:
David Gibson <dwg@au1.ibm.com> Signed-off-by:
-
Michael Ellerman authored
To prevent problems later in boot, make sure we don't create zero-size lmb regions. I've checked all the callers, and at the moment no one should ever hit this. All callers use a constant size, or they check the computed size before they call us. Signed-off-by:
-
- Jan 10, 2006
-
-
Linas Vepstas authored
240-ioremap-null-ptr-test.patch Under highly unusual circumstances, a buggy driver will ask a null ptr to be ioremapped, an operation that curently succeeds but leads to later trouble. Instead, refuse to remap the null pointer. Signed-off-by:
Linas Vepstas <linas@austin.ibm.com> Signed-off-by:
-
- Jan 09, 2006
-
-
Adrian Bunk authored
Signed-off-by:Adrian Bunk <bunk@stusta.de>
-
Michael Ellerman authored
In add_memory() we should be using __va() to get a virtual address. Spotted by Mike Kravetz. Signed-off-by:
-
Anton Blanchard authored
When taking a DABR exception we were reporting the PC. It makes more sense to report the address that caused the exception, and the gdb guys would like it that way. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Mike Kravetz authored
The system will oops if an attempt is made to add memory to an empty node/zone. This patch prevents adding memory to an empty node. The code to dynamically add a node/zone is non-trivial. This patch is temporary and will be removed when the ability to dynamically add a node/zone is complete. Signed-off-by:
Mike Kravetz <kravetz@us.ibm.com> Signed-off-by:
-
Arnd Bergmann authored
Building the arch/powerpc tree currently gives me two warnings with gcc-4.0: arch/powerpc/mm/imalloc.c: In function '__im_get_area': arch/powerpc/mm/imalloc.c:225: warning: 'tmp' may be used uninitialized in this function arch/powerpc/mm/hugetlbpage.c: In function 'hugetlb_get_unmapped_area': arch/powerpc/mm/hugetlbpage.c:608: warning: unused variable 'vma' both fixes are trivial. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
David Gibson authored
On ppc64, we independently define VMALLOCBASE and VMALLOC_START to be the same thing: the start of the vmalloc() area at 0xd000000000000000. VMALLOC_START is used much more widely, including in generic code, so this patch gets rid of the extraneous VMALLOCBASE. This does require moving the definitions of region IDs from page_64.h to pgtable.h, but they don't clearly belong in the former rather than the latter, anyway. While we're moving them, clean up the definitions of the REGION_IDs: - Abolish REGION_SIZE, it was only used once, to define REGION_MASK anyway - Define the specific region ids in terms of the REGION_ID() macro. - Define KERNEL_REGION_ID in terms of PAGE_OFFSET rather than KERNELBASE. It amounts to the same thing, but conceptually this is about the region of the linear mapping (which starts at PAGE_OFFSET) rather than of the kernel text itself (which is at KERNELBASE). Signed-off-by:
David Gibson <david@gibson.dropbear.id.au> Signed-off-by:
-
Benjamin Herrenschmidt authored
The pre-parsed addrs/n_addrs fields in struct device_node are finally gone. Remove the dodgy heuristics that did that parsing at boot and remove the fields themselves since we now have a good replacement with the new OF parsing code. This patch also fixes a bunch of drivers to use the new code instead, so that at least pmac32, pseries, iseries and g5 defconfigs build. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Anton Blanchard authored
We used to print a NUMA cpu summary at boot before the hotplug cpu code was added. This has been useful for catching machine configuration as well as firmware bugs in the past. This patch restores that functionality. An example of the output is: Node 0 CPUs: 0-7 Node 1 CPUs: 8-15 Signed-off-by:
-
Michael Ellerman authored
Milton has proposed that we should support a "linux,usable-memory" property on memory nodes which describes, in preference to "reg", the regions of memory Linux should use. This facility is required for kdump to inform the second kernel which memory it should use. Signed-off-by:
Haren Myneni <haren@us.ibm.com> Signed-off-by:
-
Mike Kravetz authored
This places dynamically added memory within the appropriate numa node. A new routine hot_add_scn_to_nid() replicates most of the memory scanning code in parse_numa_properties(). Signed-off-by:
-
Michael Ellerman authored
This patch separates usage of KERNELBASE and PAGE_OFFSET. I haven't looked at any of the PPC32 code, if we ever want to support Kdump on PPC we'll have to do another audit, ditto for iSeries. This patch makes PAGE_OFFSET the constant, it'll always be 0xC * 1 gazillion for 64-bit. To get a physical address from a virtual one you subtract PAGE_OFFSET, _not_ KERNELBASE. KERNELBASE is the virtual address of the start of the kernel, it's often the same as PAGE_OFFSET, but _might not be_. If you want to know something's offset from the start of the kernel you should subtract KERNELBASE. Signed-off-by:
-
Michael Ellerman authored
There's a bunch of code that compares an address with KERNELBASE to see if it's a "kernel address", ie. >= KERNELBASE. The proper test is actually to compare with PAGE_OFFSET, since we're going to change KERNELBASE soon. So replace all of them with an is_kernel_addr() macro that does that. Signed-off-by:
-
Mike Kravetz authored
Here is an updated version of the patch that panics if no memory is found as Nathan suggested. I'm still concerned that panic strings (not just the one added here) at this stage of booting do not show up on my system. But, that is an issue separate from this patch. Combine get_mem_*_cells() routines to avoid multiple memory node lookups. Added missing of_node_put() call. Changed variable names to help with some confusion as to meaning. Signed-off-by:
-
Paul Mackerras authored
This reverts f1fdc0117004d343698b9830e141491d5ae320d1 commit.
-
Mike Kravetz authored
I started to add missing of_node_put() calls to the routines that determine the number of cells for memory. Decided to combine the routines instead of making separate node lookups. Changed variable names to help with some confusion as to meaning. Signed-off-by:
-
David Gibson authored
Currently, the powerpc version of hugetlb_get_unmapped_area() entirely ignores the hint address. The only way to get a hugepage mapping at a specified address is with MAP_FIXED, in which case there's no way (short of parsing /proc/self/maps) for userspace to tell if it will clobber an existing mapping. This is inconvenient, so the patch below makes hugepage mappings use the given hint address if possible. Signed-off-by:
-
Benjamin Herrenschmidt authored
This patch unifies udbg for both ppc32 and ppc64 when building the merged achitecture. xmon now has a single "back end". The powermac udbg stuff gets enriched with some ADB capabilities and btext output. In addition, the early_init callback is now called on ppc32 as well, approx. in the same order as ppc64 regarding device-tree manipulations. The init sequences of ppc32 and ppc64 are getting closer, I'll unify them in a later patch. For now, you can force udbg to the scc using "sccdbg" or to btext using "btextdbg" on powermacs. I'll implement a cleaner way of forcing udbg output to something else than the autodetected OF output device in a later patch. Signed-off-by:
-
Arnd Bergmann authored
This is the current version of the spu file system, used for driving SPEs on the Cell Broadband Engine. This release is almost identical to the version for the 2.6.14 kernel posted earlier, which is available as part of the Cell BE Linux distribution from http://www.bsc.es/projects/deepcomputing/linuxoncell/ . The first patch provides all the interfaces for running spu application, but does not have any support for debugging SPU tasks or for scheduling. Both these functionalities are added in the subsequent patches. See Documentation/filesystems/spufs.txt on how to use spufs. Signed-off-by:
Arnd Bergmann <arndb@de.ibm.com> Signed-off-by:
-
- Dec 29, 2005
-
-
Anton Blanchard authored
Sonny has noticed hotplug CPU on ppc64 is broken in 2.6.15-*. One of the problems is that htab_initialize_secondary is called when a cpu is being brought up, but it is marked __init. Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
- Dec 09, 2005
-
-
David Gibson authored
On ppc64, when opening a new hugepage region, we need to make sure any old normal-page SLBs for the area are flushed on all CPUs. There was a bug in this logic - after putting the new hugepage area masks into the thread structure, we copied it into the paca (read by the SLB miss handler) only on one CPU, not on all. This could cause incorrect SLB entries to be loaded when a multithreaded program was running simultaneously on several CPUs. This patch corrects the error, copying the context information into the PACA on all CPUs using the mm in question before flushing any existing SLB entries. Signed-off-by:
-
David Gibson authored
On most powerpc CPUs, the dcache and icache are not coherent so between writing and executing a page, the caches must be flushed. Userspace programs assume pages given to them by the kernel are icache clean, so we must do this flush between the kernel clearing a page and it being mapped into userspace for execute. We were not doing this for hugepages, this patch corrects the situation. We use the same lazy mechanism as we use for normal pages, delaying the flush until userspace actually attempts to execute from the page in question. Tested on G5. Signed-off-by:
-
- Dec 08, 2005
-
-
Benjamin Herrenschmidt authored
The 64k pages patch changed the meaning of one argument passed to the low level hash functions (from "large" it became "psize" or page size index), but one of the call sites wasn't properly updated, causing potential random weird problems with huge pages. This fixes it. Signed-off-by:
-
Mike Kravetz authored
This bug exists in the current code and prevents machines from booting with numa enabled if there is a node that does not contain memory. Workaround is to boot with 'numa=off'. Looks like a simple typo. Signed-off-by:
-
- Dec 05, 2005
-
-
Olof Johansson authored
There's never been a hardware platform that has both pSeries/RPA LPAR hypervisor and stab (pre-POWER4 segment management). This removes the redundant code in stab_initalize(). Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
- Nov 25, 2005
-
-
David Gibson authored
Blah. The patch [0] I recently sent fixing errors with in_hugepage_area() and prepare_hugepage_range() for powerpc itself has an off-by-one bug. Furthermore, the related functions touches_hugepage_*_range() and within_hugepage_*_range() are also buggy. Some of the bugs, like those addressed in [0] originated with commit 7d24f0b8 where we tweaked the semantics of where hugepages are allowed. Other bugs have been there essentially forever, and are due to the undefined behaviour of '<<' with shift counts greater than the type width (LOW_ESID_MASK could return non-zero for high ranges with the right congruences). The good news is that I now have a testsuite which should pick up things like this if they creep in again. [0] "powerpc-fix-for-hugepage-areas-straddling-4gb-boundary" Signed-off-by:
-
- Nov 24, 2005
-
-
David Gibson authored
Commit 7d24f0b8 fixed bugs in the ppc64 SLB miss handler with respect to hugepage handling, and in the process tweaked the semantics of the hugepage address masks in mm_context_t. Unfortunately, it left out a couple of necessary changes to go with that change. First, the in_hugepage_area() macro was not updated to match, second prepare_hugepage_range() was not updated to correctly handle hugepages regions which straddled the 4GB point. The latter appears only to cause process-hangs when attempting to map such a region, but the former can cause oopses if a get_user_pages() is triggered at the wrong point. This patch addresses both bugs. Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Hugh Dickins authored
Restore an earlier mod which went missing in the powerpc reshuffle: the 4xx mmu_mapin_ram does not need to take init_mm.page_table_lock. Signed-off-by:
Hugh Dickins <hugh@veritas.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Hugh Dickins authored
Update comments (only) on page_table_lock and mmap_sem in arch/powerpc. Removed the comment on page_table_lock from hash_huge_page: since it's no longer taking page_table_lock itself, it's irrelevant whether others are; but how it is safe (even against huge file truncation?) I can't say. Signed-off-by:
-
- Nov 19, 2005
-
-
David Gibson authored
asm-ppc64/imalloc.h is only included from files in arch/powerpc/mm. We already have a header for mm local definitions, arch/powerpc/mm/mmu_decl.h. Thus, this patch moves the contents of imalloc.h into mmu_decl.h. The only exception are the definitions of PHBS_IO_BASE, IMALLOC_BASE and IMALLOC_END. Those are moved into pgtable.h, next to similar definitions of VMALLOC_START and VMALLOC_SIZE. Built for multiplatform 32bit and 64bit (ARCH=powerpc). Signed-off-by:
-
