[RFC][PATCH] initial port of fixmap over from x86 for ppc32
Wanted to get any feedback on this initial port of the fixmap support over
from x86. There are a few TODOs:
* change HIGHMEM support to use fixmap
* fixup up VMALLOC config to respect fixmap
(after initial powerpc patch is in tree/accepted):
* rework a few bits of fixmap.h into an asm-generic/fixmap.h
The reason for introducing fixmap into ppc32 is it provides us with a
clean way of getting fixed compile time virtual addresses for things.
Beyond the HIGHMEM usage. Ben and I have discussed cleaning up the PCIe
44x config code (and 83xx PCIe cfg) to use it. Also, Dale's kexec/kdump
support on ppc32 can take advantage of it. I'm also told this is useful
for hypervisor interactions.
One question for the guys looking at hypervisor. The x86 code also has a
function called reserve_top_address (see arch/x86/mm/pgtable_32.c). Is
this functionality something useful on ppc? If so for what?
- k
---
arch/powerpc/mm/pgtable_32.c | 18 ++
include/asm-powerpc/fixmap.h | 123 ++
2 files changed, 141 insertions(+), 0 deletions(-)
create mode 100644 include/asm-powerpc/fixmap.h
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index 64c44bc..fa0e48e 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -29,6 +29,7 @@
#include
#include
+#include
#include
#include "mmu_decl.h"
@@ -387,3 +388,20 @@ void kernel_map_pages(struct page *page, int numpages, int
enable)
change_page_attr(page, numpages, enable ? PAGE_KERNEL : __pgprot(0));
}
#endif /* CONFIG_DEBUG_PAGEALLOC */
+
+static int fixmaps;
+unsigned long __FIXADDR_TOP = 0xf000;
+EXPORT_SYMBOL(__FIXADDR_TOP);
+
+void __set_fixmap (enum fixed_addresses idx, phys_addr_t phys, pgprot_t flags)
+{
+ unsigned long address = __fix_to_virt(idx);
+
+ if (idx >= __end_of_fixed_addresses) {
+ BUG();
+ return;
+ }
+
+ map_page(address, phys, flags);
+ fixmaps++;
+}
diff --git a/include/asm-powerpc/fixmap.h b/include/asm-powerpc/fixmap.h
new file mode 100644
index 000..7b570e5
--- /dev/null
+++ b/include/asm-powerpc/fixmap.h
@@ -0,0 +1,123 @@
+/*
+ * fixmap.h: compile-time virtual memory allocation
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 1998 Ingo Molnar
+ *
+ * Support of BIGMEM added by Gerhard Wichert, Siemens AG, July 1999
+ *
+ * Copyright 2008 Freescale Semiconductor Inc.
+ * Port to powerpc added by Kumar Gala
+ */
+
+#ifndef _ASM_FIXMAP_H
+#define _ASM_FIXMAP_H
+
+
+/* used by vmalloc.c, vsyscall.lds.S.
+ *
+ * Leave one empty page between vmalloc'ed areas and
+ * the start of the fixmap.
+ */
+extern unsigned long __FIXADDR_TOP;
+#define FIXADDR_USER_START __fix_to_virt(FIX_VDSO)
+#define FIXADDR_USER_END __fix_to_virt(FIX_VDSO - 1)
+
+#ifndef __ASSEMBLY__
+#include
+#include
+#ifdef CONFIG_HIGHMEM
+#include
+#include
+#endif
+
+/*
+ * Here we define all the compile-time 'special' virtual
+ * addresses. The point is to have a constant address at
+ * compile time, but to set the physical address only
+ * in the boot process. We allocate these special addresses
+ * from the end of virtual memory (0xf000) backwards.
+ * Also this lets us do fail-safe vmalloc(), we
+ * can guarantee that these special addresses and
+ * vmalloc()-ed addresses never overlap.
+ *
+ * these 'compile-time allocated' memory buffers are
+ * fixed-size 4k pages. (or larger if used with an increment
+ * highger than 1) use fixmap_set(idx,phys) to associate
+ * physical memory with fixmap indices.
+ *
+ * TLB entries of such buffers will not be flushed across
+ * task switches.
+ */
+enum fixed_addresses {
+ FIX_HOLE,
+ FIX_VDSO,
+#ifdef CONFIG_HIGHMEM
+ FIX_KMAP_BEGIN, /* reserved pte's for temporary kernel mappings */
+ FIX_KMAP_END = FIX_KMAP_BEGIN+(KM_TYPE_NR*NR_CPUS)-1,
+#endif
+#ifdef CONFIG_PCI_MMCONFIG
+ FIX_PCIE_MCFG,
+#endif
+ __end_of_fixed_addresses
+};
+
+extern void __set_fixmap (enum fixed_addresses idx,
+ phys_addr_t phys, pgprot_t flags);
+
+#define set_fixmap(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL)
+/*
+ * Some hardware wants to get fixmapped without caching.
+ */
+#define set_fixmap_nocache(idx, phys) \
+ __set_fixmap(idx, phys, PAGE_KERNEL_NOCACHE)
+
+#define clear_fixmap(idx) \
+ __set_fixmap(idx, 0, __pgprot(0))
+
+#define FIXADDR_TOP((unsigned long)__FIXADDR_TOP)
+
+#define __FIXADDR_SIZE (__end_of_fixed_addresses << PAGE_SHIFT)
+#define __FIXADDR_BOOT_SIZE(__end_of_fixed_addresses << PAGE_SHIFT)
+#define FIXADDR_START (FIXADDR_TOP - __FIXADDR_SIZE)
+#define FIXADDR_BOOT_START (FIXADDR_TOP - __FIXADDR_BOOT_SIZE)
+
+#define __fix_to_virt(x) (FIXADDR_TOP - ((x) <
Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
On Apr 3, 2008, at 1:34 AM, Paul Mackerras wrote: Kumar Gala writes: For a kdump kernel, at least for 64-bit, the physical address has to be 32MB. There is no other choice, so there is no possibility of confusion. But how do you know a vmlinux image is for kdump or not? By looking at the ELF headers -- either the first PT_LOAD segment or the .text section -- and seeing whether the start address is 0xc200 or not. fair point. For 85xx, would it be possible to have the kernel figure out what physical address it has been loaded at, and use that as the base address, rather than having the base address set at compile time? Yes, that is what CONFIG_RELOCATABLE is all about. Is there any reason to have that as an option, rather than just always doing that? Concerned about runtime performance of __va() and __pa(). That would solve my objection since it would mean that there would no longer be two things that had to be kept in sync. You could pass any value to wrapper/mkimage (subject to constraints such as it has to be a multiple of 256M) and it would work. That value could even come from a config option in the case where wrapper is invoked as part of the kernel build, but that config option shouldn't affect anything at all in the vmlinux. Ok, but I still think the issues exists when we config PHYSICAL_START to non-zero and CONFIG_RELOCATABLE=n. Ideally we get set the phys address the PHDR, but I'm not sure how to get the linker to do that. If we can do that then the wrapper script can dig it out and pass it to mkimage, which would solve the problem. Ok, so on Segher's recommendation I looked at 'AT' and posted a patch that uses that so now regardless of the kernel the PT_LOAD PHDR will have the physical address set properly. So now we can look at the vmlinux and determine the physical offset. The question is how best to do that. Here are the options I see: * readelf, grep and parse output * objdump grep and parse output * simple C program that read's the elf and reports back [looking for suggestion on what direction you want to take] The other questions is if we'd ever have a vmlinux with more than one PT_LOAD PHDR. If so which one do we use (the one with the lowest physical address)? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.25' branch [UPDATED]
Please pull from 'for-2.6.25' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.25 to receive the following updates: (Added trivial cpm2 fix from Laurent) - k arch/powerpc/boot/dts/mpc8377_mds.dts |4 ++-- arch/powerpc/boot/dts/mpc8377_rdb.dts |3 +-- arch/powerpc/boot/dts/mpc8378_rdb.dts |3 +-- arch/powerpc/boot/dts/mpc8379_mds.dts |8 arch/powerpc/boot/dts/mpc8379_rdb.dts |3 +-- arch/powerpc/configs/mpc832x_mds_defconfig | 11 +++ arch/powerpc/configs/mpc834x_mds_defconfig | 11 +++ arch/powerpc/configs/mpc836x_mds_defconfig | 11 +++ arch/powerpc/configs/mpc837x_rdb_defconfig | 24 +++- arch/powerpc/configs/mpc83xx_defconfig | 24 +++- arch/powerpc/configs/mpc8544_ds_defconfig | 11 +++ arch/powerpc/configs/mpc8568mds_defconfig | 11 +++ arch/powerpc/configs/mpc8572_ds_defconfig | 11 +++ arch/powerpc/configs/mpc85xx_defconfig | 11 +++ arch/powerpc/configs/mpc8641_hpcn_defconfig | 11 +++ arch/powerpc/configs/prpmc2800_defconfig| 11 +++ arch/powerpc/configs/storcenter_defconfig | 11 +++ arch/powerpc/sysdev/cpm2.c |1 + drivers/ata/sata_fsl.c |5 + drivers/dma/fsldma.c|8 20 files changed, 91 insertions(+), 102 deletions(-) Anton Vorontsov (1): [POWERPC] 83xx: Fix wrong USB phy type in mpc837xrdb dts Kim Phillips (2): [POWERPC] 83xx: enable usb in 837x rdb and 83xx defconfigs [POWERPC] sata_fsl: reduce compatibility to fsl,pq-sata Kumar Gala (2): [POWERPC] fsldma: Use compatiable binding as spec [POWERPC] Fix defconfigs so we dont set both GENRTC and RTCLIB Laurent Pinchart (1): [POWERPC] Fix CPM2 SCC1 clock initialization. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Fix CPM2 SCC1 clock initialization.
On Apr 2, 2008, at 9:46 AM, Laurent Pinchart wrote: A missing break statement in a switch caused cpm2_clk_setup() to initialize SCC2 instead of SCC1. This patch fixes the bug. Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/cpm2.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) applied. However your email is malformatted. Since it was a trivial patch I fixed it up by hand. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
Kumar Gala writes: > > For a kdump kernel, at least for 64-bit, the physical address has to > > be 32MB. There is no other choice, so there is no possibility of > > confusion. > > But how do you know a vmlinux image is for kdump or not? By looking at the ELF headers -- either the first PT_LOAD segment or the .text section -- and seeing whether the start address is 0xc200 or not. > > For 85xx, would it be possible to have the kernel figure out what > > physical address it has been loaded at, and use that as the base > > address, rather than having the base address set at compile time? > > Yes, that is what CONFIG_RELOCATABLE is all about. Is there any reason to have that as an option, rather than just always doing that? > > That would solve my objection since it would mean that there would no > > longer be two things that had to be kept in sync. You could pass any > > value to wrapper/mkimage (subject to constraints such as it has to be > > a multiple of 256M) and it would work. That value could even come > > from a config option in the case where wrapper is invoked as part of > > the kernel build, but that config option shouldn't affect anything at > > all in the vmlinux. > > Ok, but I still think the issues exists when we config PHYSICAL_START > to non-zero and CONFIG_RELOCATABLE=n. Ideally we get set the phys > address the PHDR, but I'm not sure how to get the linker to do that. If we can do that then the wrapper script can dig it out and pass it to mkimage, which would solve the problem. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Update linker script to properly set physical addresses
We can set LOAD_OFFSET and use the AT attribute on sections and the
linker will properly set the physical address of the LOAD program
header for us.
This allows us to know how the PHYSICAL_START the user configured a
kernel with by just looking at the resulting vmlinux ELF.
This is pretty much stolen from how x86 does things in their linker
scripts.
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Paul,
This patch is top of my existing series of mm init cleanup/rework.
- k
arch/powerpc/kernel/vmlinux.lds.S | 47 ++---
include/asm-powerpc/page.h|1 +
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index b5a76bc..0c3000b 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -31,7 +31,7 @@ SECTIONS
*/
/* Text and gots */
- .text : {
+ .text : AT(ADDR(.text) - LOAD_OFFSET) {
ALIGN_FUNCTION();
*(.text.head)
_text = .;
@@ -56,7 +56,7 @@ SECTIONS
RODATA
/* Exception & bug tables */
- __ex_table : {
+ __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
__start___ex_table = .;
*(__ex_table)
__stop___ex_table = .;
@@ -72,7 +72,7 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__init_begin = .;
- .init.text : {
+ .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) {
_sinittext = .;
INIT_TEXT
_einittext = .;
@@ -81,11 +81,11 @@ SECTIONS
/* .exit.text is discarded at runtime, not link time,
* to deal with references from __bug_table
*/
- .exit.text : {
+ .exit.text : AT(ADDR(.exit.text) - LOAD_OFFSET) {
EXIT_TEXT
}
- .init.data : {
+ .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {
INIT_DATA
__vtop_table_begin = .;
*(.vtop_fixup);
@@ -101,19 +101,19 @@ SECTIONS
}
. = ALIGN(16);
- .init.setup : {
+ .init.setup : AT(ADDR(.init.setup) - LOAD_OFFSET) {
__setup_start = .;
*(.init.setup)
__setup_end = .;
}
- .initcall.init : {
+ .initcall.init : AT(ADDR(.initcall.init) - LOAD_OFFSET) {
__initcall_start = .;
INITCALLS
__initcall_end = .;
}
- .con_initcall.init : {
+ .con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
@@ -122,14 +122,14 @@ SECTIONS
SECURITY_INIT
. = ALIGN(8);
- __ftr_fixup : {
+ __ftr_fixup : AT(ADDR(__ftr_fixup) - LOAD_OFFSET) {
__start___ftr_fixup = .;
*(__ftr_fixup)
__stop___ftr_fixup = .;
}
#ifdef CONFIG_PPC64
. = ALIGN(8);
- __fw_ftr_fixup : {
+ __fw_ftr_fixup : AT(ADDR(__fw_ftr_fixup) - LOAD_OFFSET) {
__start___fw_ftr_fixup = .;
*(__fw_ftr_fixup)
__stop___fw_ftr_fixup = .;
@@ -137,14 +137,14 @@ SECTIONS
#endif
#ifdef CONFIG_BLK_DEV_INITRD
. = ALIGN(PAGE_SIZE);
- .init.ramfs : {
+ .init.ramfs : AT(ADDR(.init.ramfs) - LOAD_OFFSET) {
__initramfs_start = .;
*(.init.ramfs)
__initramfs_end = .;
}
#endif
. = ALIGN(PAGE_SIZE);
- .data.percpu : {
+ .data.percpu : AT(ADDR(.data.percpu) - LOAD_OFFSET) {
__per_cpu_start = .;
*(.data.percpu)
*(.data.percpu.shared_aligned)
@@ -152,7 +152,7 @@ SECTIONS
}
. = ALIGN(8);
- .machine.desc : {
+ .machine.desc : AT(ADDR(.machine.desc) - LOAD_OFFSET) {
__machine_desc_start = . ;
*(.machine.desc)
__machine_desc_end = . ;
@@ -170,25 +170,24 @@ SECTIONS
_sdata = .;
#ifdef CONFIG_PPC32
- .data:
- {
+ .data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
*(.sdata)
*(.got.plt) *(.got)
}
#else
- .data : {
+ .data : AT(ADDR(.data) - LOAD_OFFSET) {
DATA_DATA
*(.data.rel*)
*(.toc1)
*(.branch_lt)
}
- .opd : {
+ .opd : AT(ADDR(.opd) - LOAD_OFFSET) {
*(.opd)
}
- .got : {
+ .got : AT(ADDR(.got) - LOAD_OFFSET) {
__toc_start = .;
*(.got)
*(.toc)
@@ -205,26 +204,26 @@ SECTIONS
#else
. = ALIGN(16384);
#endif
- .data.init_task : {
+ .data.init_task : AT(ADDR(.data.init_task) - LOAD_OFFSET) {
*(.data.init_task)
}
Re: [PATCH] [POWERPC] Fix a mm compile error
On Apr 2, 2008, at 6:05 PM, Emil Medve wrote: arch/powerpc/mm/init_32.c:102: error: conflicting types for '__initial_memory_limit_addr' arch/powerpc/mm/mmu_decl.h:51: error: previous declaration of '__initial_memory_limit_addr' was here Signed-off-by: Emil Medve <[EMAIL PROTECTED]> --- arch/powerpc/mm/init_32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c index 555bb7e..63c5e3d 100644 --- a/arch/powerpc/mm/init_32.c +++ b/arch/powerpc/mm/init_32.c @@ -99,7 +99,7 @@ unsigned long __max_low_memory = MAX_LOW_MEM; * address of the limit of what is accessible with initial MMU setup - * 256MB usually, but only 16MB on 601. */ -unsigned long __initial_memory_limit_addr = 0x1000; +phys_addr_t __initial_memory_limit_addr = 0x1000; I should have fixed this in my tree, if there are still issues let me know. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Create common ppc4xx_reset_system() in ppc4xx_soc.c
On Thursday 03 April 2008, Josh Boyer wrote: > On Thu, 27 Mar 2008 15:43:31 +0100 > > Stefan Roese <[EMAIL PROTECTED]> wrote: > > diff --git a/arch/powerpc/platforms/44x/sequoia.c > > b/arch/powerpc/platforms/44x/sequoia.c index d279db4..1782d41 100644 > > --- a/arch/powerpc/platforms/44x/sequoia.c > > +++ b/arch/powerpc/platforms/44x/sequoia.c > > @@ -23,8 +23,6 @@ > > #include > > #include > > > > -#include "44x.h" > > - > > Almost a perfect patch. Alas, missing a #include which > breaks the sequoia build. > > I'll fix it up locally :). Thanks Josh. I missed that one. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: [EMAIL PROTECTED] = ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
On Thursday 03 April 2008, Grant Likely wrote: > > > > Since it is not really compatible with ns16550, shouldn't you at least > > specify > > a different "compatible" property? That way, the driver won't do incorrect > > accesses when you try to use an old driver with a device tree that > > specifies > > one of these. > > Heh; we've gone back and forth on this issue. The problem is that we > have a common case of ns16550 like devices that require a little bit > of register address tweaking that spans a whole range of vendors (so > adding a compatible match with each of those vendor's prefixes is > probably non-scalable). So, if "ns16550" is not a good idea, then > what should be used? "sparse16550" has been suggested more than once. After another IRC discussion between Grant, Segher and myself, we concluded that we don't need to invent a new "compatible" value, as only new device trees with old kernels will have a problem with this, and they don't work in the first place. The devices will still have their specific "compatible" value, e.g. "xlnx,plb-uart16550-1.00.c", followed by "ns16550", and possibly "ns16450" and "i8250", although the last two do not have an effect on Linux. Josh, can you please forward all three patches in their latest version? Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm: make mem_map allocation continuous v2.
On Wed, Apr 2, 2008 at 7:22 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Wed, 2 Apr 2008 18:30:24 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > v2 replace: > > [PATCH] mm: make mem_map allocation continuous. > > [PATCH] mm: allocate section_map for sparse_init > > [PATCH] mm: allocate usemap at first instead of mem_map in > sparse_init > > > > err, no. > > > > > > diff --git a/mm/sparse.c b/mm/sparse.c > > index f6a43c0..2881222 100644 > > --- a/mm/sparse.c > > +++ b/mm/sparse.c > > Sorry, but I'd rather not do it this way. We presently have this: > it replaces > mm-make-mem_map-allocation-continuous.patch > mm-make-mem_map-allocation-continuous-checkpatch-fixes.patch > mm-allocate-section_map-for-sparse_init.patch > mm-allocate-section_map-for-sparse_init-update.patch > mm-allocate-section_map-for-sparse_init-update-fix.patch > mm-allocate-section_map-for-sparse_init-powerpc-fix.patch others still needed so mm-make-mem-map-allocation-continuous.patch will not break powerpc and ia64 YH ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm: make mem_map allocation continuous v2.
Looks good to me. And ia64 boots up with this patch too.
Thanks.
Acked-by: Yasunori Goto <[EMAIL PROTECTED]>
>
> vmemmap allocation current got
> [e200-e21f] PMD ->81000140 on node 0
> [e220-e23f] PMD ->81000180 on node 0
> [e240-e25f] PMD ->810001c0 on node 0
> [e260-e27f] PMD ->81000200 on node 0
> [e280-e29f] PMD ->81000240 on node 0
> ...
>
> there is 2M hole between them.
>
> the rootcause is that usemap (24 bytes) will be allocated after every 2M
> mem_map. and it will push next vmemmap (2M) to next align (2M).
>
> solution:
> try to allocate mem_map continously.
>
> after patch, will get
> [e200-e21f] PMD ->81000140 on node 0
> [e220-e23f] PMD ->81000160 on node 0
> [e240-e25f] PMD ->81000180 on node 0
> [e260-e27f] PMD ->810001a0 on node 0
> [e280-e29f] PMD ->810001c0 on node 0
> ...
> and usemap will share in page because of they are allocated continuously too.
> sparse_early_usemap_alloc: usemap = 810024e0 size = 24
> sparse_early_usemap_alloc: usemap = 810024e00080 size = 24
> sparse_early_usemap_alloc: usemap = 810024e00100 size = 24
> sparse_early_usemap_alloc: usemap = 810024e00180 size = 24
> ...
>
> so we make the bootmem allocation more compact and use less memory for usemap.
>
> for power pc
> Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> > You have to call sparse_init_one_section() on each pmap and usemap
> > as we allocate - since valid_section() depends on it (which is needed
> > by vmemmap_populate() to check if the section is populated or not).
> > On ppc, we need to call htab_bolted_mapping() on each section and
> > we need to skip existing sections.
>
> so try to allocate usemap at first altogether.
>
> v2 replace:
> [PATCH] mm: make mem_map allocation continuous.
> [PATCH] mm: allocate section_map for sparse_init
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index f6a43c0..2881222 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -294,22 +294,48 @@ void __init sparse_init(void)
> unsigned long pnum;
> struct page *map;
> unsigned long *usemap;
> + unsigned long **usemap_map;
> + int size;
> +
> + /*
> + * map is using big page (aka 2M in x86 64 bit)
> + * usemap is less one page (aka 24 bytes)
> + * so alloc 2M (with 2M align) and 24 bytes in turn will
> + * make next 2M slip to one more 2M later.
> + * then in big system, the memory will have a lot of holes...
> + * here try to allocate 2M pages continously.
> + *
> + * powerpc need to call sparse_init_one_section right after each
> + * sparse_early_mem_map_alloc, so allocate usemap_map at first.
> + */
> + size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
> + usemap_map = alloc_bootmem(size);
> + if (!usemap_map)
> + panic("can not allocate usemap_map\n");
>
> for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> if (!present_section_nr(pnum))
> continue;
> + usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
> + }
>
> - map = sparse_early_mem_map_alloc(pnum);
> - if (!map)
> + for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> + if (!present_section_nr(pnum))
> continue;
>
> - usemap = sparse_early_usemap_alloc(pnum);
> + usemap = usemap_map[pnum];
> if (!usemap)
> continue;
>
> + map = sparse_early_mem_map_alloc(pnum);
> + if (!map)
> + continue;
> +
> sparse_init_one_section(__nr_to_section(pnum), pnum, map,
> usemap);
> }
> +
> + free_bootmem(__pa(usemap_map), size);
> }
>
> #ifdef CONFIG_MEMORY_HOTPLUG
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Yasunori Goto
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
On Wed, Apr 2, 2008 at 5:34 PM, Arnd Bergmann <[EMAIL PROTECTED]> wrote: > On Thursday 03 April 2008, John Linn wrote: > > The Xilinx 16550 uart core is not a standard 16550 because it uses > > word-based addressing rather than byte-based addressing. With > > additional properties it is compatible with the open firmware > > 'ns16550' compatible binding. > > > > This code updates the of_serial driver to handle the reg-offset > > and reg-shift properties to enable this core to be used. > > > > Signed-off-by: John Linn <[EMAIL PROTECTED]> > > I may not be the best driver maintainer, but please keep the illusion > alive for me and Cc me on patches to drivers I wrote ;-) > > > > diff --git a/Documentation/powerpc/booting-without-of.txt > b/Documentation/powerpc/booting-without-of.txt > > index 87f4d84..4066ec8 100644 > > --- a/Documentation/powerpc/booting-without-of.txt > > +++ b/Documentation/powerpc/booting-without-of.txt > > @@ -2539,6 +2539,16 @@ platforms are moved over to use the > flattened-device-tree model. > >differ between different families. May be > >'virtex2p', 'virtex4', or 'virtex5'. > > > > + iv) Xilinx Uart 16550 > > + > > + Xilinx UART 16550 devices are very similar to the NS16550 but with > > + different register spacing and an offset from the base address. > > + > > + Requred properties: > > + - clock-frequency : Frequency of the clock input > > + - reg-offset : A value of 3 is required > > + - reg-shift : A value of 2 is required > > + > > More devices will be defined as this spec matures. > > Since it is not really compatible with ns16550, shouldn't you at least > specify > a different "compatible" property? That way, the driver won't do incorrect > accesses when you try to use an old driver with a device tree that specifies > one of these. Heh; we've gone back and forth on this issue. The problem is that we have a common case of ns16550 like devices that require a little bit of register address tweaking that spans a whole range of vendors (so adding a compatible match with each of those vendor's prefixes is probably non-scalable). So, if "ns16550" is not a good idea, then what should be used? "sparse16550" has been suggested more than once. On the other side of the coin; the draft ePAPR spec already redefines the meaning of "ns16550" to add an optional "reg-shift" property. Also, in this particular case the problem is most likely more theoretical than actual. The likely hood of a platform needing these new properties being handed a kernel which does not support the "reg-*" properties is very slim. Anyway, all that just to say that I prefer "ns16550", but I'll put my vote and support behind "sparse16550" (or any other string) if other people express consensus with it. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm: make mem_map allocation continuous v2.
On Wed, 2 Apr 2008 18:30:24 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: > v2 replace: > [PATCH] mm: make mem_map allocation continuous. > [PATCH] mm: allocate section_map for sparse_init > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init > err, no. > > diff --git a/mm/sparse.c b/mm/sparse.c > index f6a43c0..2881222 100644 > --- a/mm/sparse.c > +++ b/mm/sparse.c Sorry, but I'd rather not do it this way. We presently have this: mm-make-mem_map-allocation-continuous.patch mm-make-mem_map-allocation-continuous-checkpatch-fixes.patch mm-fix-alloc_bootmem_core-to-use-fast-searching-for-all-nodes.patch mm-allocate-section_map-for-sparse_init.patch mm-allocate-section_map-for-sparse_init-update.patch mm-allocate-section_map-for-sparse_init-update-fix.patch mm-allocate-section_map-for-sparse_init-powerpc-fix.patch mm-offset-align-in-alloc_bootmem.patch mm-make-reserve_bootmem-can-crossed-the-nodes.patch mm-make-reserve_bootmem-can-crossed-the-nodes-checkpatch-fixes.patch and you purport to throw some of them away and combine them into a single patch? We assume that the later patches will still apply and work on top of this newer patch? It is up to me to check that the replacement patch incorporates the third-party changes to the original patches? Too hard, too risky. Can't we just do a fix against 2.6.25-rc8-mm1? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
On Thursday 03 April 2008, Josh Boyer wrote: > > > > Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> > > > > Signed-off-by: John Linn <[EMAIL PROTECTED]> > > > Acked-by: Grant Likely <[EMAIL PROTECTED]> > > > > Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> > > This is the second time all three of us have Acked this. I'm pulling > it in my tree. > Hehe, thanks! I never know what the right thing to do with of_serial patches is. In the past, I've sent them to akpm, in the absense of a dedicated serial driver maintainer, but I'm just as happy when they get into mainline any other way. Of course, it feels a bit wrong for me to forward a patch that was never sent to me personally. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
On Wed, Apr 2, 2008 at 5:44 PM, Yinghai Lu <[EMAIL PROTECTED]> wrote: > > On Wed, Apr 2, 2008 at 3:52 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > > > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init > > > > > > on powerpc, > > > > > > On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <[EMAIL PROTECTED]> > wrote: > > > > > > > > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote: > > > > > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote: > > > > > > Andrew Morton wrote: > > > > > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL > PROTECTED]> wrote: > > > so try to allocate usemap at first altogether. > > > > I have to turn all the above crud into a proper changelog. I'd prefer > that > > you do it. > > > > Unless this patch should be folded into another one, in which case it > > doesn't matter. > > > > > > > Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> > > > > > > diff --git a/mm/sparse.c b/mm/sparse.c > > > index d3cb085..782ebe5 100644 > > > --- a/mm/sparse.c > > > +++ b/mm/sparse.c > > > > We shouldn't merge this patch on its own because then that will leave a > > non-bisectable region in the powerpc history. > > > > So which patch is this patch fixing? Lexically it applies to > > mm-allocate-section_map-for-sparse_init.patch (and its updates). But is > > that where it logically lies? > > yes. we should fold > > > mm-make-mem_map-allocation-continuous.patch > > mm-allocate-section_map-for-sparse_init.patch > and this one > please check the big one. http://lkml.org/lkml/2008/4/2/650 YH ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] mm: make mem_map allocation continuous v2.
vmemmap allocation current got
[e200-e21f] PMD ->81000140 on node 0
[e220-e23f] PMD ->81000180 on node 0
[e240-e25f] PMD ->810001c0 on node 0
[e260-e27f] PMD ->81000200 on node 0
[e280-e29f] PMD ->81000240 on node 0
...
there is 2M hole between them.
the rootcause is that usemap (24 bytes) will be allocated after every 2M
mem_map. and it will push next vmemmap (2M) to next align (2M).
solution:
try to allocate mem_map continously.
after patch, will get
[e200-e21f] PMD ->81000140 on node 0
[e220-e23f] PMD ->81000160 on node 0
[e240-e25f] PMD ->81000180 on node 0
[e260-e27f] PMD ->810001a0 on node 0
[e280-e29f] PMD ->810001c0 on node 0
...
and usemap will share in page because of they are allocated continuously too.
sparse_early_usemap_alloc: usemap = 810024e0 size = 24
sparse_early_usemap_alloc: usemap = 810024e00080 size = 24
sparse_early_usemap_alloc: usemap = 810024e00100 size = 24
sparse_early_usemap_alloc: usemap = 810024e00180 size = 24
...
so we make the bootmem allocation more compact and use less memory for usemap.
for power pc
Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> You have to call sparse_init_one_section() on each pmap and usemap
> as we allocate - since valid_section() depends on it (which is needed
> by vmemmap_populate() to check if the section is populated or not).
> On ppc, we need to call htab_bolted_mapping() on each section and
> we need to skip existing sections.
so try to allocate usemap at first altogether.
v2 replace:
[PATCH] mm: make mem_map allocation continuous.
[PATCH] mm: allocate section_map for sparse_init
[PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/mm/sparse.c b/mm/sparse.c
index f6a43c0..2881222 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -294,22 +294,48 @@ void __init sparse_init(void)
unsigned long pnum;
struct page *map;
unsigned long *usemap;
+ unsigned long **usemap_map;
+ int size;
+
+ /*
+* map is using big page (aka 2M in x86 64 bit)
+* usemap is less one page (aka 24 bytes)
+* so alloc 2M (with 2M align) and 24 bytes in turn will
+* make next 2M slip to one more 2M later.
+* then in big system, the memory will have a lot of holes...
+* here try to allocate 2M pages continously.
+*
+* powerpc need to call sparse_init_one_section right after each
+* sparse_early_mem_map_alloc, so allocate usemap_map at first.
+*/
+ size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
+ usemap_map = alloc_bootmem(size);
+ if (!usemap_map)
+ panic("can not allocate usemap_map\n");
for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
if (!present_section_nr(pnum))
continue;
+ usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
+ }
- map = sparse_early_mem_map_alloc(pnum);
- if (!map)
+ for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
+ if (!present_section_nr(pnum))
continue;
- usemap = sparse_early_usemap_alloc(pnum);
+ usemap = usemap_map[pnum];
if (!usemap)
continue;
+ map = sparse_early_mem_map_alloc(pnum);
+ if (!map)
+ continue;
+
sparse_init_one_section(__nr_to_section(pnum), pnum, map,
usemap);
}
+
+ free_bootmem(__pa(usemap_map), size);
}
#ifdef CONFIG_MEMORY_HOTPLUG
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] 4xx: Create common ppc4xx_reset_system() in ppc4xx_soc.c
On Thu, 27 Mar 2008 15:43:31 +0100 Stefan Roese <[EMAIL PROTECTED]> wrote: > diff --git a/arch/powerpc/platforms/44x/sequoia.c > b/arch/powerpc/platforms/44x/sequoia.c > index d279db4..1782d41 100644 > --- a/arch/powerpc/platforms/44x/sequoia.c > +++ b/arch/powerpc/platforms/44x/sequoia.c > @@ -23,8 +23,6 @@ > #include > #include > > -#include "44x.h" > - Almost a perfect patch. Alas, missing a #include which breaks the sequoia build. I'll fix it up locally :). josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
On Wed, Apr 2, 2008 at 6:02 PM, David Gibson
<[EMAIL PROTECTED]> wrote:
>
> On Wed, Apr 02, 2008 at 09:52:14AM -0700, John Linn wrote:
> > The Xilinx 16550 uart core is not a standard 16550 because it uses
> > word-based addressing rather than byte-based adressing. With
> > additional properties it is compatible with the open firmware
> > 'ns16550' compatible binding.
> >
> > This code updates the ns16550 driver to use the reg-offset property
> > so that the Xilinx UART 16550 can be used with it. The reg-shift
> > was already being handled.
> >
> > Signed-off-by: John Linn <[EMAIL PROTECTED]>
> > ---
> > arch/powerpc/boot/ns16550.c |5 +
> > 1 files changed, 5 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> > index f8f1b2f..da9d2c2 100644
> > --- a/arch/powerpc/boot/ns16550.c
> > +++ b/arch/powerpc/boot/ns16550.c
> > @@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct
> serial_console_data *scdp)
> > {
> > int n;
> > unsigned long reg_phys;
> > + u32 reg_offset;
> >
> > n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
> > if (n != sizeof(reg_base)) {
> > @@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct
> serial_console_data *scdp)
> > reg_base = (void *)reg_phys;
> > }
> >
> > + n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
> > + if (n == sizeof(reg_offset))
> > + reg_base += reg_offset;
>
> Uh... how does the behaviour of reg-offset differ from just bumping
> the address in "reg"?
Mostly because the registers are actually 32 bit registers that can be
accessed with 32bit reads at offset 0. Using this property keeps the
reg property describing the real address range.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
On Thu, 3 Apr 2008 01:39:04 +0200 Arnd Bergmann <[EMAIL PROTECTED]> wrote: > On Wednesday 02 April 2008, Grant Likely wrote: > > On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote: > > > From: Stephen Neuendorffer <[EMAIL PROTECTED]> > > > > > > The of_serial driver queries the current-speed property and attempts > > > to use it to register the custom_divisor property of the uart_port. > > > However, if current-speed is not set, then this code will dereference > > > a bad pointer. The fix is to only set custom_divisor when a > > > current-speed property appears in the device tree. > > > > > > Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> > > > Signed-off-by: John Linn <[EMAIL PROTECTED]> > > Acked-by: Grant Likely <[EMAIL PROTECTED]> > > Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> This is the second time all three of us have Acked this. I'm pulling it in my tree. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
On Wed, Apr 2, 2008 at 4:51 PM, Badari Pulavarty <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-04-02 at 15:25 -0700, Yinghai Lu wrote:
> > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
>
> > so try to allocate usemap at first altogether.
> >
> > Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
> >
> > diff --git a/mm/sparse.c b/mm/sparse.c
> > index d3cb085..782ebe5 100644
> > --- a/mm/sparse.c
> > +++ b/mm/sparse.c
> > @@ -294,7 +294,7 @@ void __init sparse_init(void)
> > unsigned long pnum;
> > struct page *map;
> > unsigned long *usemap;
> > - struct page **section_map;
> > + unsigned long **usemap_map;
> > int size;
> > int node;
> >
> > @@ -305,27 +305,31 @@ void __init sparse_init(void)
> >* make next 2M slip to one more 2M later.
> >* then in big system, the memmory will have a lot hole...
> >* here try to allocate 2M pages continously.
>
> Comments are x86-64 specific. On ppc its 16MB chunks :(
>
>
>
> > + *
> > + * powerpc hope to sparse_init_one_section right after each
> > + * sparse_early_mem_map_alloc, so allocate usemap_map
> > + * at first.
> >*/
> > - size = sizeof(struct page *) * NR_MEM_SECTIONS;
> > - section_map = alloc_bootmem(size);
> > - if (!section_map)
> > - panic("can not allocate section_map\n");
> > + size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
> > + usemap_map = alloc_bootmem(size);
> > + if (!usemap_map)
> > + panic("can not allocate usemap_map\n");
> >
> > for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> > if (!present_section_nr(pnum))
> > continue;
> > - section_map[pnum] = sparse_early_mem_map_alloc(pnum);
> > + usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
> > }
> >
> > for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> > if (!present_section_nr(pnum))
> > continue;
> >
> > - map = section_map[pnum];
> > + map = sparse_early_mem_map_alloc(pnum);
> > if (!map)
> >continue;
> >
> > - usemap = sparse_early_usemap_alloc(pnum);
> > + usemap = usemap_map[pnum];
> > if (!usemap)
> > continue;
>
> You may want to move this check before doing sparse_early_mem_map_alloc
> (). We are also not handling errors properly (freeing up the unused
> map or usemap) if we "continue". I know the original code is this way,
> but you touched it last :)
Yes. could avoid some leak...
YH
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
On Wed, Apr 2, 2008 at 3:52 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: > > > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init > > > > on powerpc, > > > > On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <[EMAIL PROTECTED]> > wrote: > > > > > > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote: > > > > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote: > > > > > Andrew Morton wrote: > > > > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL > PROTECTED]> wrote: > > > > > > > > > > > >> Hi Andrew, > > > > > >> > > > > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power > machine(s). > > > > > >> > > > > > >> [0.00] [ cut here ] > > > > > >> [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240! > > > > > >> [0.00] Oops: Exception in kernel mode, sig: 5 [#1] > > > > > >> [0.00] SMP NR_CPUS=32 NUMA PowerMac > > > > > >> [0.00] Modules linked in: > > > > > >> [0.00] NIP: c03d1dcc LR: c03d1dc4 CTR: > c002b6ac > > > > > >> [0.00] REGS: c049b960 TRAP: 0700 Not tainted > (2.6.25-rc8-mm1-autokern1) > > > > > >> [0.00] MSR: 90021032 CR: 4488 > XER: 2000 > > > > > >> [0.00] TASK = c03f9c90[0] 'swapper' THREAD: > c0498000 CPU: 0 > > > > > >> [0.00] GPR00: c03d1dc4 c049bbe0 > c04989d0 0001 > > > > > >> [0.00] GPR04: d59aca40f000 0b00 > 0010 > > > > > >> [0.00] GPR08: 0004 0001 > c0027e520800 c04bf0f0 > > > > > >> [0.00] GPR12: c04bf020 c03fa900 > > > > > > >> [0.00] GPR16: > > > > > > >> [0.00] GPR20: > 4140 > > > > > >> [0.00] GPR24: 017d64b0 c03d6250 > c0504000 > > > > > >> [0.00] GPR28: cf1f8000 > 0100 cf00 > > > > > >> [0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4 > > > > > >> [0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4 > > > > > >> [0.00] Call Trace: > > > > > >> [0.00] [c049bbe0] [c03d1dc4] > .vmemmap_populate+0xb0/0xf4 (unreliable) > > > > > >> [0.00] [c049bc70] [c03d2ee8] > .sparse_mem_map_populate+0x38/0x60 > > > > > >> [0.00] [c049bd00] [c03c242c] > .sparse_early_mem_map_alloc+0x54/0x94 > > > > > >> [0.00] [c049bd90] [c03c250c] > .sparse_init+0xa0/0x20c > > > > > >> [0.00] [c049be50] [c03ab7d0] > .setup_arch+0x1ac/0x218 > > > > > >> [0.00] [c049bee0] [c03a36ac] > .start_kernel+0xe0/0x3fc > > > > > >> [0.00] [c049bf90] [c0008594] > .start_here_common+0x54/0xc0 > > > > > >> [0.00] Instruction dump: > > > > > >> [0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c > e92289c8 e96289c0 e9090002 > > > > > >> [0.00] e8eb0002 4bc575cd 6000 78630fe0 <0b03> > 7214 7fbfe840 7fe3fb78 > > > > > >> [0.00] ---[ end trace 31fd0ba7d8756001 ]--- > > > > > >> [0.00] Kernel panic - not syncing: Attempted to kill the > idle task! > > > > > > mm-make-mem_map-allocation-continuous.patch > > > and its friends in -mm. > > > > > > You have to call sparse_init_one_section() on each pmap and usemap > > > as we allocate - since valid_section() depends on it (which is needed > > > by vmemmap_populate() to check if the section is populated or not). > > > On ppc, we need to call htab_bolted_mapping() on each section and > > > we need to skip existing sections. > > > > > > These patches tried to group all allocations together and then later > > > calls sparse_init_one_section() - which is not good :( > > > > so try to allocate usemap at first altogether. > > I have to turn all the above crud into a proper changelog. I'd prefer that > you do it. > > Unless this patch should be folded into another one, in which case it > doesn't matter. > > > > Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> > > > > diff --git a/mm/sparse.c b/mm/sparse.c > > index d3cb085..782ebe5 100644 > > --- a/mm/sparse.c > > +++ b/mm/sparse.c > > We shouldn't merge this patch on its own because then that will leave a > non-bisectable region in the powerpc history. > > So which patch is this patch fixing? Lexically it applies to > mm-allocate-section_map-for-sparse_init.patch (and its updates). But is > that where it lo
Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
On Wed, Apr 02, 2008 at 09:52:14AM -0700, John Linn wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based adressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the ns16550 driver to use the reg-offset property
> so that the Xilinx UART 16550 can be used with it. The reg-shift
> was already being handled.
>
> Signed-off-by: John Linn <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/ns16550.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> index f8f1b2f..da9d2c2 100644
> --- a/arch/powerpc/boot/ns16550.c
> +++ b/arch/powerpc/boot/ns16550.c
> @@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct
> serial_console_data *scdp)
> {
> int n;
> unsigned long reg_phys;
> + u32 reg_offset;
>
> n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
> if (n != sizeof(reg_base)) {
> @@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct
> serial_console_data *scdp)
> reg_base = (void *)reg_phys;
> }
>
> + n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
> + if (n == sizeof(reg_offset))
> + reg_base += reg_offset;
Uh... how does the behaviour of reg-offset differ from just bumping
the address in "reg"?
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
On Thursday 03 April 2008, John Linn wrote: > The Xilinx 16550 uart core is not a standard 16550 because it uses > word-based addressing rather than byte-based addressing. With > additional properties it is compatible with the open firmware > 'ns16550' compatible binding. > > This code updates the of_serial driver to handle the reg-offset > and reg-shift properties to enable this core to be used. > > Signed-off-by: John Linn <[EMAIL PROTECTED]> I may not be the best driver maintainer, but please keep the illusion alive for me and Cc me on patches to drivers I wrote ;-) > diff --git a/Documentation/powerpc/booting-without-of.txt > b/Documentation/powerpc/booting-without-of.txt > index 87f4d84..4066ec8 100644 > --- a/Documentation/powerpc/booting-without-of.txt > +++ b/Documentation/powerpc/booting-without-of.txt > @@ -2539,6 +2539,16 @@ platforms are moved over to use the > flattened-device-tree model. >differ between different families. May be >'virtex2p', 'virtex4', or 'virtex5'. > > + iv) Xilinx Uart 16550 > + > + Xilinx UART 16550 devices are very similar to the NS16550 but with > + different register spacing and an offset from the base address. > + > + Requred properties: > + - clock-frequency : Frequency of the clock input > + - reg-offset : A value of 3 is required > + - reg-shift : A value of 2 is required > + > More devices will be defined as this spec matures. Since it is not really compatible with ns16550, shouldn't you at least specify a different "compatible" property? That way, the driver won't do incorrect accesses when you try to use an old driver with a device tree that specifies one of these. > @@ -49,6 +50,17 @@ static int __devinit of_platform_serial_setup(struct > of_device *ofdev, > > spin_lock_init(&port->lock); > port->mapbase = resource.start; > + > + /* Check for shifted address mapping */ > + prop = of_get_property(np, "reg-offset", &prop_size); > + if (prop && (prop_size == sizeof(u32))) > + port->mapbase += *prop; > + > + /* Check for registers offset within the devices address range */ > + prop = of_get_property(np, "reg-shift", &prop_size); > + if (prop && (prop_size == sizeof(u32))) > + port->regshift = *prop; > + > port->irq = irq_of_parse_and_map(np, 0); > port->iotype = UPIO_MEM; > port->type = type; This part looks good to me. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
On Wednesday 02 April 2008, Grant Likely wrote: > On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote: > > From: Stephen Neuendorffer <[EMAIL PROTECTED]> > > > > The of_serial driver queries the current-speed property and attempts > > to use it to register the custom_divisor property of the uart_port. > > However, if current-speed is not set, then this code will dereference > > a bad pointer. The fix is to only set custom_divisor when a > > current-speed property appears in the device tree. > > > > Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> > > Signed-off-by: John Linn <[EMAIL PROTECTED]> > Acked-by: Grant Likely <[EMAIL PROTECTED]> Acked-by: Arnd Bergmann <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] [POWERPC][V3] Xilinx: of_serial support for Xilinx uart 16550.
The Xilinx 16550 uart core is not a standard 16550 because it uses word-based addressing rather than byte-based addressing. With additional properties it is compatible with the open firmware 'ns16550' compatible binding. This code updates the of_serial driver to handle the reg-offset and reg-shift properties to enable this core to be used. Signed-off-by: John Linn <[EMAIL PROTECTED]> --- V3 has fixes suggested by Grant. They were incorporated and tested. Documentation/powerpc/booting-without-of.txt | 10 ++ drivers/serial/of_serial.c | 14 +- 2 files changed, 23 insertions(+), 1 deletions(-) diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 87f4d84..4066ec8 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -2539,6 +2539,16 @@ platforms are moved over to use the flattened-device-tree model. differ between different families. May be 'virtex2p', 'virtex4', or 'virtex5'. + iv) Xilinx Uart 16550 + + Xilinx UART 16550 devices are very similar to the NS16550 but with + different register spacing and an offset from the base address. + + Requred properties: + - clock-frequency : Frequency of the clock input + - reg-offset : A value of 3 is required + - reg-shift : A value of 2 is required + More devices will be defined as this spec matures. VII - Specifying interrupt information for devices diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c index 2efb892..73c47a5 100644 --- a/drivers/serial/of_serial.c +++ b/drivers/serial/of_serial.c @@ -31,7 +31,8 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev, struct resource resource; struct device_node *np = ofdev->node; const unsigned int *clk, *spd; - int ret; + const u32 *prop; + int ret, prop_size; memset(port, 0, sizeof *port); spd = of_get_property(np, "current-speed", NULL); @@ -49,6 +50,17 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev, spin_lock_init(&port->lock); port->mapbase = resource.start; + + /* Check for shifted address mapping */ + prop = of_get_property(np, "reg-offset", &prop_size); + if (prop && (prop_size == sizeof(u32))) + port->mapbase += *prop; + + /* Check for registers offset within the devices address range */ + prop = of_get_property(np, "reg-shift", &prop_size); + if (prop && (prop_size == sizeof(u32))) + port->regshift = *prop; + port->irq = irq_of_parse_and_map(np, 0); port->iotype = UPIO_MEM; port->type = type; -- 1.5.2.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] Fix a mm compile error
arch/powerpc/mm/init_32.c:102: error: conflicting types for '__initial_memory_limit_addr' arch/powerpc/mm/mmu_decl.h:51: error: previous declaration of '__initial_memory_limit_addr' was here Signed-off-by: Emil Medve <[EMAIL PROTECTED]> --- arch/powerpc/mm/init_32.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c index 555bb7e..63c5e3d 100644 --- a/arch/powerpc/mm/init_32.c +++ b/arch/powerpc/mm/init_32.c @@ -99,7 +99,7 @@ unsigned long __max_low_memory = MAX_LOW_MEM; * address of the limit of what is accessible with initial MMU setup - * 256MB usually, but only 16MB on 601. */ -unsigned long __initial_memory_limit_addr = 0x1000; +phys_addr_t __initial_memory_limit_addr = 0x1000; /* * Check for command-line options that affect what MMU_init will do. -- 1.5.4.GIT ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
On Wed, 2 Apr 2008 15:25:48 -0700 Yinghai Lu <[EMAIL PROTECTED]> wrote: > [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init > > on powerpc, > > On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <[EMAIL PROTECTED]> wrote: > > > > On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote: > > > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote: > > > > Andrew Morton wrote: > > > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL > > PROTECTED]> wrote: > > > > > > > > > >> Hi Andrew, > > > > >> > > > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power > > machine(s). > > > > >> > > > > >> [0.00] [ cut here ] > > > > >> [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240! > > > > >> [0.00] Oops: Exception in kernel mode, sig: 5 [#1] > > > > >> [0.00] SMP NR_CPUS=32 NUMA PowerMac > > > > >> [0.00] Modules linked in: > > > > >> [0.00] NIP: c03d1dcc LR: c03d1dc4 CTR: > > c002b6ac > > > > >> [0.00] REGS: c049b960 TRAP: 0700 Not tainted > > (2.6.25-rc8-mm1-autokern1) > > > > >> [0.00] MSR: 90021032 CR: 4488 XER: > > 2000 > > > > >> [0.00] TASK = c03f9c90[0] 'swapper' THREAD: > > c0498000 CPU: 0 > > > > >> [0.00] GPR00: c03d1dc4 c049bbe0 > > c04989d0 0001 > > > > >> [0.00] GPR04: d59aca40f000 0b00 > > 0010 > > > > >> [0.00] GPR08: 0004 0001 > > c0027e520800 c04bf0f0 > > > > >> [0.00] GPR12: c04bf020 c03fa900 > > > > > > >> [0.00] GPR16: > > > > > > >> [0.00] GPR20: > > 4140 > > > > >> [0.00] GPR24: 017d64b0 c03d6250 > > c0504000 > > > > >> [0.00] GPR28: cf1f8000 > > 0100 cf00 > > > > >> [0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4 > > > > >> [0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4 > > > > >> [0.00] Call Trace: > > > > >> [0.00] [c049bbe0] [c03d1dc4] > > .vmemmap_populate+0xb0/0xf4 (unreliable) > > > > >> [0.00] [c049bc70] [c03d2ee8] > > .sparse_mem_map_populate+0x38/0x60 > > > > >> [0.00] [c049bd00] [c03c242c] > > .sparse_early_mem_map_alloc+0x54/0x94 > > > > >> [0.00] [c049bd90] [c03c250c] > > .sparse_init+0xa0/0x20c > > > > >> [0.00] [c049be50] [c03ab7d0] > > .setup_arch+0x1ac/0x218 > > > > >> [0.00] [c049bee0] [c03a36ac] > > .start_kernel+0xe0/0x3fc > > > > >> [0.00] [c049bf90] [c0008594] > > .start_here_common+0x54/0xc0 > > > > >> [0.00] Instruction dump: > > > > >> [0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c > > e92289c8 e96289c0 e9090002 > > > > >> [0.00] e8eb0002 4bc575cd 6000 78630fe0 <0b03> > > 7214 7fbfe840 7fe3fb78 > > > > >> [0.00] ---[ end trace 31fd0ba7d8756001 ]--- > > > > >> [0.00] Kernel panic - not syncing: Attempted to kill the > > idle task! > > > > mm-make-mem_map-allocation-continuous.patch > > and its friends in -mm. > > > > You have to call sparse_init_one_section() on each pmap and usemap > > as we allocate - since valid_section() depends on it (which is needed > > by vmemmap_populate() to check if the section is populated or not). > > On ppc, we need to call htab_bolted_mapping() on each section and > > we need to skip existing sections. > > > > These patches tried to group all allocations together and then later > > calls sparse_init_one_section() - which is not good :( > > so try to allocate usemap at first altogether. I have to turn all the above crud into a proper changelog. I'd prefer that you do it. Unless this patch should be folded into another one, in which case it doesn't matter. > Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]> > > diff --git a/mm/sparse.c b/mm/sparse.c > index d3cb085..782ebe5 100644 > --- a/mm/sparse.c > +++ b/mm/sparse.c We shouldn't merge this patch on its own because then that will leave a non-bisectable region in the powerpc history. So which patch is this patch fixing? Lexically it applies to mm-allocate-section_map-for-sparse_init.patch (and its updates). But is that where it logically lies? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
On Wed, 2008-04-02 at 15:25 -0700, Yinghai Lu wrote:
> [PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
> so try to allocate usemap at first altogether.
>
> Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index d3cb085..782ebe5 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -294,7 +294,7 @@ void __init sparse_init(void)
> unsigned long pnum;
> struct page *map;
> unsigned long *usemap;
> - struct page **section_map;
> + unsigned long **usemap_map;
> int size;
> int node;
>
> @@ -305,27 +305,31 @@ void __init sparse_init(void)
>* make next 2M slip to one more 2M later.
>* then in big system, the memmory will have a lot hole...
>* here try to allocate 2M pages continously.
Comments are x86-64 specific. On ppc its 16MB chunks :(
> + *
> + * powerpc hope to sparse_init_one_section right after each
> + * sparse_early_mem_map_alloc, so allocate usemap_map
> + * at first.
>*/
> - size = sizeof(struct page *) * NR_MEM_SECTIONS;
> - section_map = alloc_bootmem(size);
> - if (!section_map)
> - panic("can not allocate section_map\n");
> + size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
> + usemap_map = alloc_bootmem(size);
> + if (!usemap_map)
> + panic("can not allocate usemap_map\n");
>
> for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> if (!present_section_nr(pnum))
> continue;
> - section_map[pnum] = sparse_early_mem_map_alloc(pnum);
> + usemap_map[pnum] = sparse_early_usemap_alloc(pnum);
> }
>
> for (pnum = 0; pnum < NR_MEM_SECTIONS; pnum++) {
> if (!present_section_nr(pnum))
> continue;
>
> - map = section_map[pnum];
> + map = sparse_early_mem_map_alloc(pnum);
> if (!map)
>continue;
>
> - usemap = sparse_early_usemap_alloc(pnum);
> + usemap = usemap_map[pnum];
> if (!usemap)
> continue;
You may want to move this check before doing sparse_early_mem_map_alloc
(). We are also not handling errors properly (freeing up the unused
map or usemap) if we "continue". I know the original code is this way,
but you touched it last :)
>
> @@ -333,7 +337,7 @@ void __init sparse_init(void)
> usemap);
> }
>
> - free_bootmem(__pa(section_map), size);
> + free_bootmem(__pa(usemap_map), size);
> }
>
> #ifdef CONFIG_MEMORY_HOTPLUG
Tested and boots my machine fine.
Acked-by: Badari Pulavarty <[EMAIL PROTECTED]>
Thanks,
Badari
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
[PATCH] mm: allocate usemap at first instead of mem_map in sparse_init
on powerpc,
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL
> PROTECTED]> wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power
> machine(s).
> > > >>
> > > >> [0.00] [ cut here ]
> > > >> [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > >> [0.00] Oops: Exception in kernel mode, sig: 5 [#1]
> > > >> [0.00] SMP NR_CPUS=32 NUMA PowerMac
> > > >> [0.00] Modules linked in:
> > > >> [0.00] NIP: c03d1dcc LR: c03d1dc4 CTR:
> c002b6ac
> > > >> [0.00] REGS: c049b960 TRAP: 0700 Not tainted
> (2.6.25-rc8-mm1-autokern1)
> > > >> [0.00] MSR: 90021032 CR: 4488 XER:
> 2000
> > > >> [0.00] TASK = c03f9c90[0] 'swapper' THREAD:
> c0498000 CPU: 0
> > > >> [0.00] GPR00: c03d1dc4 c049bbe0
> c04989d0 0001
> > > >> [0.00] GPR04: d59aca40f000 0b00
> 0010
> > > >> [0.00] GPR08: 0004 0001
> c0027e520800 c04bf0f0
> > > >> [0.00] GPR12: c04bf020 c03fa900
>
> > > >> [0.00] GPR16:
>
> > > >> [0.00] GPR20:
> 4140
> > > >> [0.00] GPR24: 017d64b0 c03d6250
> c0504000
> > > >> [0.00] GPR28: cf1f8000
> 0100 cf00
> > > >> [0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4
> > > >> [0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4
> > > >> [0.00] Call Trace:
> > > >> [0.00] [c049bbe0] [c03d1dc4]
> .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > >> [0.00] [c049bc70] [c03d2ee8]
> .sparse_mem_map_populate+0x38/0x60
> > > >> [0.00] [c049bd00] [c03c242c]
> .sparse_early_mem_map_alloc+0x54/0x94
> > > >> [0.00] [c049bd90] [c03c250c]
> .sparse_init+0xa0/0x20c
> > > >> [0.00] [c049be50] [c03ab7d0]
> .setup_arch+0x1ac/0x218
> > > >> [0.00] [c049bee0] [c03a36ac]
> .start_kernel+0xe0/0x3fc
> > > >> [0.00] [c049bf90] [c0008594]
> .start_here_common+0x54/0xc0
> > > >> [0.00] Instruction dump:
> > > >> [0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c e92289c8
> e96289c0 e9090002
> > > >> [0.00] e8eb0002 4bc575cd 6000 78630fe0 <0b03>
> 7214 7fbfe840 7fe3fb78
> > > >> [0.00] ---[ end trace 31fd0ba7d8756001 ]---
> > > >> [0.00] Kernel panic - not syncing: Attempted to kill the idle
> task!
>
> mm-make-mem_map-allocation-continuous.patch
> and its friends in -mm.
>
> You have to call sparse_init_one_section() on each pmap and usemap
> as we allocate - since valid_section() depends on it (which is needed
> by vmemmap_populate() to check if the section is populated or not).
> On ppc, we need to call htab_bolted_mapping() on each section and
> we need to skip existing sections.
>
> These patches tried to group all allocations together and then later
> calls sparse_init_one_section() - which is not good :(
so try to allocate usemap at first altogether.
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/mm/sparse.c b/mm/sparse.c
index d3cb085..782ebe5 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -294,7 +294,7 @@ void __init sparse_init(void)
unsigned long pnum;
struct page *map;
unsigned long *usemap;
- struct page **section_map;
+ unsigned long **usemap_map;
int size;
int node;
@@ -305,27 +305,31 @@ void __init sparse_init(void)
* make next 2M slip to one more 2M later.
* then in big system, the memmory will have a lot hole...
* here try to allocate 2M pages continously.
+*
+* powerpc hope to sparse_init_one_section right after each
+* sparse_early_mem_map_alloc, so allocate usemap_map
+* at first.
*/
- size = sizeof(struct page *) * NR_MEM_SECTIONS;
- section_map = alloc_bootmem(size);
- if (!section_map)
- panic("can not allocate section_map\n");
+ size = sizeof(unsigned long *) * NR_MEM_SECTIONS;
+ usemap_map = alloc_bootmem(size);
+ if (!usemap_map)
+
Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL
> PROTECTED]> wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power
> machine(s).
> > > >>
> > > >> [0.00] [ cut here ]
> > > >> [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > >> [0.00] Oops: Exception in kernel mode, sig: 5 [#1]
> > > >> [0.00] SMP NR_CPUS=32 NUMA PowerMac
> > > >> [0.00] Modules linked in:
> > > >> [0.00] NIP: c03d1dcc LR: c03d1dc4 CTR:
> c002b6ac
> > > >> [0.00] REGS: c049b960 TRAP: 0700 Not tainted
> (2.6.25-rc8-mm1-autokern1)
> > > >> [0.00] MSR: 90021032 CR: 4488 XER:
> 2000
> > > >> [0.00] TASK = c03f9c90[0] 'swapper' THREAD:
> c0498000 CPU: 0
> > > >> [0.00] GPR00: c03d1dc4 c049bbe0
> c04989d0 0001
> > > >> [0.00] GPR04: d59aca40f000 0b00
> 0010
> > > >> [0.00] GPR08: 0004 0001
> c0027e520800 c04bf0f0
> > > >> [0.00] GPR12: c04bf020 c03fa900
>
> > > >> [0.00] GPR16:
>
> > > >> [0.00] GPR20:
> 4140
> > > >> [0.00] GPR24: 017d64b0 c03d6250
> c0504000
> > > >> [0.00] GPR28: cf1f8000
> 0100 cf00
> > > >> [0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4
> > > >> [0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4
> > > >> [0.00] Call Trace:
> > > >> [0.00] [c049bbe0] [c03d1dc4]
> .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > >> [0.00] [c049bc70] [c03d2ee8]
> .sparse_mem_map_populate+0x38/0x60
> > > >> [0.00] [c049bd00] [c03c242c]
> .sparse_early_mem_map_alloc+0x54/0x94
> > > >> [0.00] [c049bd90] [c03c250c]
> .sparse_init+0xa0/0x20c
> > > >> [0.00] [c049be50] [c03ab7d0]
> .setup_arch+0x1ac/0x218
> > > >> [0.00] [c049bee0] [c03a36ac]
> .start_kernel+0xe0/0x3fc
> > > >> [0.00] [c049bf90] [c0008594]
> .start_here_common+0x54/0xc0
> > > >> [0.00] Instruction dump:
> > > >> [0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c e92289c8
> e96289c0 e9090002
> > > >> [0.00] e8eb0002 4bc575cd 6000 78630fe0 <0b03>
> 7214 7fbfe840 7fe3fb78
> > > >> [0.00] ---[ end trace 31fd0ba7d8756001 ]---
> > > >> [0.00] Kernel panic - not syncing: Attempted to kill the idle
> task!
> > > >>
> > > >
> > > > int __meminit vmemmap_populate(struct page *start_page,
> > > > unsigned long nr_pages, int node)
> > > > {
> > > > unsigned long mode_rw;
> > > > unsigned long start = (unsigned long)start_page;
> > > > unsigned long end = (unsigned long)(start_page + nr_pages);
> > > > unsigned long page_size = 1 <<
> mmu_psize_defs[mmu_linear_psize].shift;
> > > >
> > > > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> > > >
> > > > /* Align to the page size of the linear mapping. */
> > > > start = _ALIGN_DOWN(start, page_size);
> > > >
> > > > for (; start < end; start += page_size) {
> > > > int mapped;
> > > > void *p;
> > > >
> > > > if (vmemmap_populated(start, page_size))
> > > > continue;
> > > >
> > > > p = vmemmap_alloc_block(page_size, node);
> > > > if (!p)
> > > > return -ENOMEM;
> > > >
> > > > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > > > start, p, __pa(p));
> > > >
> > > > mapped = htab_bolt_mapping(start, start + page_size,
> > > > __pa(p), mode_rw, mmu_linear_psize,
> > > > mmu_kernel_ssize);
> > > > =>BUG_ON(mapped < 0);
> > > > }
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > Beats me. pseries? Badari has been diddling with the bolted memory
> code
> > > > in git-powerpc...
> > >
> > > One of the machines is the Power5 and another is PowerMac G5, on which
> the
> > > same kernel panic is seen.
> >
> > Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c,
Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
On Wed, Apr 2, 2008 at 12:22 PM, Badari Pulavarty <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > > Andrew Morton wrote:
> > > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL
> PROTECTED]> wrote:
> > > >
> > > >> Hi Andrew,
> > > >>
> > > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power
> machine(s).
> > > >>
> > > >> [0.00] [ cut here ]
> > > >> [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > > >> [0.00] Oops: Exception in kernel mode, sig: 5 [#1]
> > > >> [0.00] SMP NR_CPUS=32 NUMA PowerMac
> > > >> [0.00] Modules linked in:
> > > >> [0.00] NIP: c03d1dcc LR: c03d1dc4 CTR:
> c002b6ac
> > > >> [0.00] REGS: c049b960 TRAP: 0700 Not tainted
> (2.6.25-rc8-mm1-autokern1)
> > > >> [0.00] MSR: 90021032 CR: 4488 XER:
> 2000
> > > >> [0.00] TASK = c03f9c90[0] 'swapper' THREAD:
> c0498000 CPU: 0
> > > >> [0.00] GPR00: c03d1dc4 c049bbe0
> c04989d0 0001
> > > >> [0.00] GPR04: d59aca40f000 0b00
> 0010
> > > >> [0.00] GPR08: 0004 0001
> c0027e520800 c04bf0f0
> > > >> [0.00] GPR12: c04bf020 c03fa900
>
> > > >> [0.00] GPR16:
>
> > > >> [0.00] GPR20:
> 4140
> > > >> [0.00] GPR24: 017d64b0 c03d6250
> c0504000
> > > >> [0.00] GPR28: cf1f8000
> 0100 cf00
> > > >> [0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4
> > > >> [0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4
> > > >> [0.00] Call Trace:
> > > >> [0.00] [c049bbe0] [c03d1dc4]
> .vmemmap_populate+0xb0/0xf4 (unreliable)
> > > >> [0.00] [c049bc70] [c03d2ee8]
> .sparse_mem_map_populate+0x38/0x60
> > > >> [0.00] [c049bd00] [c03c242c]
> .sparse_early_mem_map_alloc+0x54/0x94
> > > >> [0.00] [c049bd90] [c03c250c]
> .sparse_init+0xa0/0x20c
> > > >> [0.00] [c049be50] [c03ab7d0]
> .setup_arch+0x1ac/0x218
> > > >> [0.00] [c049bee0] [c03a36ac]
> .start_kernel+0xe0/0x3fc
> > > >> [0.00] [c049bf90] [c0008594]
> .start_here_common+0x54/0xc0
> > > >> [0.00] Instruction dump:
> > > >> [0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c e92289c8
> e96289c0 e9090002
> > > >> [0.00] e8eb0002 4bc575cd 6000 78630fe0 <0b03>
> 7214 7fbfe840 7fe3fb78
> > > >> [0.00] ---[ end trace 31fd0ba7d8756001 ]---
> > > >> [0.00] Kernel panic - not syncing: Attempted to kill the idle
> task!
> > > >>
> > > >
> > > > int __meminit vmemmap_populate(struct page *start_page,
> > > > unsigned long nr_pages, int node)
> > > > {
> > > > unsigned long mode_rw;
> > > > unsigned long start = (unsigned long)start_page;
> > > > unsigned long end = (unsigned long)(start_page + nr_pages);
> > > > unsigned long page_size = 1 <<
> mmu_psize_defs[mmu_linear_psize].shift;
> > > >
> > > > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> > > >
> > > > /* Align to the page size of the linear mapping. */
> > > > start = _ALIGN_DOWN(start, page_size);
> > > >
> > > > for (; start < end; start += page_size) {
> > > > int mapped;
> > > > void *p;
> > > >
> > > > if (vmemmap_populated(start, page_size))
> > > > continue;
> > > >
> > > > p = vmemmap_alloc_block(page_size, node);
> > > > if (!p)
> > > > return -ENOMEM;
> > > >
> > > > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > > > start, p, __pa(p));
> > > >
> > > > mapped = htab_bolt_mapping(start, start + page_size,
> > > > __pa(p), mode_rw, mmu_linear_psize,
> > > > mmu_kernel_ssize);
> > > > =>BUG_ON(mapped < 0);
> > > > }
> > > >
> > > > return 0;
> > > > }
> > > >
> > > > Beats me. pseries? Badari has been diddling with the bolted memory
> code
> > > > in git-powerpc...
> > >
> > > One of the machines is the Power5 and another is PowerMac G5, on which
> the
> > > same kernel panic is seen.
> >
> > Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c,
RE: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
I don't think big-endian has the same context as reg-shift/reg-offset. The OpenPOC is fundamentally a 32 bit device, but ns16550 is not... If we were talking about a 32 bit device, then I'd probably agree with you, but in this case, the reg-shift (and to some extent) reg-offset have been used before and probably make more sense, I think. Steve > -Original Message- > From: Sergei Shtylyov [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 02, 2008 1:20 PM > To: John Linn > Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] > Subject: Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550. > > Hello. > > John Linn wrote: > > > The Xilinx 16550 uart core is not a standard 16550 because it uses > > word-based addressing rather than byte-based addressing. With > > additional properties it is compatible with the open firmware > > 'ns16550' compatible binding. > > > This code updates the of_serial driver to handle the reg-offset > > and reg-shift properties to enable this core to be used. > > > Signed-off-by: John Linn <[EMAIL PROTECTED]> > > > diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without- > of.txt > > index 87f4d84..af112d9 100644 > > --- a/Documentation/powerpc/booting-without-of.txt > > +++ b/Documentation/powerpc/booting-without-of.txt > > @@ -2539,6 +2539,17 @@ platforms are moved over to use the flattened-device-tree model. > >differ between different families. May be > >'virtex2p', 'virtex4', or 'virtex5'. > > > > + iv) Xilinx Uart 16550 > > + > > + Xilinx UART 16550 devices are very similar to the NS16550 such that they > > + use the ns16550 binding with properties to specify register spacing and > > + an offset from the base address. > > + > > + Requred properties: > > + - clock-frequency : Frequency of the clock input > > + - reg-offset : A value of 3 is required > > I'm proposing you to use the already existing "big-endian" property ISO > "reg-offset" (used in the nodes describing OpenPIC, for example). > > WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
On Wed, Apr 2, 2008 at 12:20 PM, John Linn <[EMAIL PROTECTED]> wrote: > Sounds good, those are easy changes and make sense. > > Since I'm a newbie, I don't know any better sometimes when I copy other > code that may not be as safe. > > The same thing, of_get_property(np, "current-speed", NULL);, is done > right above my code I added. > > Should the other code in the driver using the same method be fixed, or > just my patch? It would be good to fix the other code, but not in this patch. Write another patch to fix that. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Two MPC8641D's on a single JTAG chain with BDI2000/3000. Anyone got it to work?
Hi Guys'n'Gals, We have a board with two Freescale MPC8641D chips (ie four cores, two in each chip) on a single jtag chain, nothing else on the chain. We are unable to get BDI and WindRiver jtag debuggers to work with both chips, only the second (last) chip works. With the BDI we can configure to work with both cores in the second chip, with windriver only one core in second chip configuration works. If we split the jtag chain in the lab we can work with each processor independently with no problems. We want both to work however. On the BDI if we configure predecessor 1,8, successor 0,0 we can talk to the second chip as expected, but if we try predecessor 0,0 successor 1,8 to talk to the first chip we get nothing. Is there something else we need to configure in either the BDM or the Freescale chip to get this to work? Any suggestions or pointers to helpful resources welcome, either privately or to the list if this isn't too far off topic. Cheers Phil ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
Hello. John Linn wrote: The Xilinx 16550 uart core is not a standard 16550 because it uses word-based addressing rather than byte-based addressing. With additional properties it is compatible with the open firmware 'ns16550' compatible binding. This code updates the of_serial driver to handle the reg-offset and reg-shift properties to enable this core to be used. Signed-off-by: John Linn <[EMAIL PROTECTED]> diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 87f4d84..af112d9 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -2539,6 +2539,17 @@ platforms are moved over to use the flattened-device-tree model. differ between different families. May be 'virtex2p', 'virtex4', or 'virtex5'. + iv) Xilinx Uart 16550 + + Xilinx UART 16550 devices are very similar to the NS16550 such that they + use the ns16550 binding with properties to specify register spacing and + an offset from the base address. + + Requred properties: + - clock-frequency : Frequency of the clock input + - reg-offset : A value of 3 is required I'm proposing you to use the already existing "big-endian" property ISO "reg-offset" (used in the nodes describing OpenPIC, for example). WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] RTAS - adapt procfs interface
Paul Mackerras wrote: > Nathan Lynch writes: > > > I think this is better... the way these files are used is lame, but > > this should preserve the existing behavior. I haven't yet tested > > this, can you? > > Looks OK -- can I have a proper patch description and a signed-off-by > line for this please? Actually, my patch has the potentially undesirable consequence of allowing only one of the three flash-related proc files to be open at any time, whereas the previous behavior enforced exclusive open on a per-file basis. If you want something for 2.6.25, I think the patch Jens posted is of lower risk. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] E500 Make steal_context SMP-safe.
>From c4923d80bbd40f91c7b402db37fabb4995632b7e Mon Sep 17 00:00:00 2001
From: Randy Vinson <[EMAIL PROTECTED]>
Date: Tue, 1 Apr 2008 17:19:06 -0700
Subject: [PATCH] E500 Make steal_context SMP-safe.
When steal_context is used on SMP systems, it can steal a context in
use by one of the other processors. This patch adds context tracking to
prevent this as suggested by BenH.
Signed-off-by: Randy Vinson <[EMAIL PROTECTED]>
---
Note: This is a proof-of-concept patch. This isn't my area of expertise,
so I'd greatly appreciate any guidance I can get. I'm considering the
use of for_each_online_cpu() instead of for_each_possible_cpu() and
possibly putting the changes under a CONFIG_SMP switch to prevent unnecessary
overhead in the non-SMP case.
Thx,
Randy Vinson
arch/powerpc/mm/mmu_context_32.c | 27 +++
include/asm-powerpc/mmu_context.h |5 +
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/mmu_context_32.c b/arch/powerpc/mm/mmu_context_32.c
index cc32ba4..cf04aa8 100644
--- a/arch/powerpc/mm/mmu_context_32.c
+++ b/arch/powerpc/mm/mmu_context_32.c
@@ -34,6 +34,8 @@ unsigned long context_map[LAST_CONTEXT / BITS_PER_LONG + 1];
atomic_t nr_free_contexts;
struct mm_struct *context_mm[LAST_CONTEXT+1];
void steal_context(void);
+DEFINE_SPINLOCK(mm_lock);
+DEFINE_PER_CPU(struct mm_struct *, curr_mm);
#endif /* FEW_CONTEXTS */
/*
@@ -42,6 +44,9 @@ void steal_context(void);
void __init
mmu_context_init(void)
{
+#ifdef FEW_CONTEXTS
+ int cpu;
+#endif
/*
* Some processors have too few contexts to reserve one for
* init_mm, and require using context 0 for a normal task.
@@ -52,6 +57,8 @@ mmu_context_init(void)
next_mmu_context = FIRST_CONTEXT;
#ifdef FEW_CONTEXTS
atomic_set(&nr_free_contexts, LAST_CONTEXT - FIRST_CONTEXT + 1);
+ for_each_possible_cpu(cpu)
+ per_cpu(curr_mm, cpu) = NULL;
#endif /* FEW_CONTEXTS */
}
@@ -72,6 +79,24 @@ void
steal_context(void)
{
struct mm_struct *mm;
+ int cpu;
+ cpumask_t local_cpumask = cpumask_of_cpu(smp_processor_id());
+
+ do {
+ /* free up context `next_mmu_context' */
+ /* if we shouldn't free context 0, don't... */
+ if (next_mmu_context < FIRST_CONTEXT)
+ next_mmu_context = FIRST_CONTEXT;
+ mm = context_mm[next_mmu_context];
+ for_each_possible_cpu(cpu) {
+ if ((cpu != smp_processor_id()) &&
+ per_cpu(curr_mm, cpu) == mm) {
+ mm = NULL;
+ next_mmu_context = (next_mmu_context + 1) &
+ LAST_CONTEXT;
+ }
+ }
+ } while(!mm);
/* free up context `next_mmu_context' */
/* if we shouldn't free context 0, don't... */
@@ -80,5 +105,7 @@ steal_context(void)
mm = context_mm[next_mmu_context];
flush_tlb_mm(mm);
destroy_context(mm);
+ if (!cpus_equal(mm->cpu_vm_mask, local_cpumask))
+ flush_tlb_mm(mm);
}
#endif /* FEW_CONTEXTS */
diff --git a/include/asm-powerpc/mmu_context.h
b/include/asm-powerpc/mmu_context.h
index 9102b8b..e083b25 100644
--- a/include/asm-powerpc/mmu_context.h
+++ b/include/asm-powerpc/mmu_context.h
@@ -113,6 +113,8 @@ extern unsigned long next_mmu_context;
extern atomic_t nr_free_contexts;
extern struct mm_struct *context_mm[LAST_CONTEXT+1];
extern void steal_context(void);
+extern spinlock_t mm_lock;
+DECLARE_PER_CPU(struct mm_struct *, curr_mm);
#endif
/*
@@ -125,6 +127,7 @@ static inline void get_mmu_context(struct mm_struct *mm)
if (mm->context.id != NO_CONTEXT)
return;
#ifdef FEW_CONTEXTS
+ spin_lock(&mm_lock);
while (atomic_dec_if_positive(&nr_free_contexts) < 0)
steal_context();
#endif
@@ -138,6 +141,8 @@ static inline void get_mmu_context(struct mm_struct *mm)
mm->context.id = ctx;
#ifdef FEW_CONTEXTS
context_mm[ctx] = mm;
+ per_cpu(curr_mm, smp_processor_id()) = mm;
+ spin_unlock(&mm_lock);
#endif
}
--
1.5.4.4.551.g1658c
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
On Wed, 2008-04-02 at 18:17 +1100, Michael Ellerman wrote:
> On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> > Andrew Morton wrote:
> > > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > >> Hi Andrew,
> > >>
> > >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> > >>
> > >> [0.00] [ cut here ]
> > >> [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
> > >> [0.00] Oops: Exception in kernel mode, sig: 5 [#1]
> > >> [0.00] SMP NR_CPUS=32 NUMA PowerMac
> > >> [0.00] Modules linked in:
> > >> [0.00] NIP: c03d1dcc LR: c03d1dc4 CTR:
> > >> c002b6ac
> > >> [0.00] REGS: c049b960 TRAP: 0700 Not tainted
> > >> (2.6.25-rc8-mm1-autokern1)
> > >> [0.00] MSR: 90021032 CR: 4488 XER:
> > >> 2000
> > >> [0.00] TASK = c03f9c90[0] 'swapper' THREAD:
> > >> c0498000 CPU: 0
> > >> [0.00] GPR00: c03d1dc4 c049bbe0 c04989d0
> > >> 0001
> > >> [0.00] GPR04: d59aca40f000 0b00 0010
> > >>
> > >> [0.00] GPR08: 0004 0001 c0027e520800
> > >> c04bf0f0
> > >> [0.00] GPR12: c04bf020 c03fa900
> > >>
> > >> [0.00] GPR16:
> > >>
> > >> [0.00] GPR20:
> > >> 4140
> > >> [0.00] GPR24: 017d64b0 c03d6250
> > >> c0504000
> > >> [0.00] GPR28: cf1f8000 0100
> > >> cf00
> > >> [0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4
> > >> [0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4
> > >> [0.00] Call Trace:
> > >> [0.00] [c049bbe0] [c03d1dc4]
> > >> .vmemmap_populate+0xb0/0xf4 (unreliable)
> > >> [0.00] [c049bc70] [c03d2ee8]
> > >> .sparse_mem_map_populate+0x38/0x60
> > >> [0.00] [c049bd00] [c03c242c]
> > >> .sparse_early_mem_map_alloc+0x54/0x94
> > >> [0.00] [c049bd90] [c03c250c]
> > >> .sparse_init+0xa0/0x20c
> > >> [0.00] [c049be50] [c03ab7d0]
> > >> .setup_arch+0x1ac/0x218
> > >> [0.00] [c049bee0] [c03a36ac]
> > >> .start_kernel+0xe0/0x3fc
> > >> [0.00] [c049bf90] [c0008594]
> > >> .start_here_common+0x54/0xc0
> > >> [0.00] Instruction dump:
> > >> [0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c e92289c8
> > >> e96289c0 e9090002
> > >> [0.00] e8eb0002 4bc575cd 6000 78630fe0 <0b03> 7214
> > >> 7fbfe840 7fe3fb78
> > >> [0.00] ---[ end trace 31fd0ba7d8756001 ]---
> > >> [0.00] Kernel panic - not syncing: Attempted to kill the idle
> > >> task!
> > >>
> > >
> > > int __meminit vmemmap_populate(struct page *start_page,
> > > unsigned long nr_pages, int node)
> > > {
> > > unsigned long mode_rw;
> > > unsigned long start = (unsigned long)start_page;
> > > unsigned long end = (unsigned long)(start_page + nr_pages);
> > > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> > >
> > > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> > >
> > > /* Align to the page size of the linear mapping. */
> > > start = _ALIGN_DOWN(start, page_size);
> > >
> > > for (; start < end; start += page_size) {
> > > int mapped;
> > > void *p;
> > >
> > > if (vmemmap_populated(start, page_size))
> > > continue;
> > >
> > > p = vmemmap_alloc_block(page_size, node);
> > > if (!p)
> > > return -ENOMEM;
> > >
> > > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > > start, p, __pa(p));
> > >
> > > mapped = htab_bolt_mapping(start, start + page_size,
> > > __pa(p), mode_rw, mmu_linear_psize,
> > > mmu_kernel_ssize);
> > > =>BUG_ON(mapped < 0);
> > > }
> > >
> > > return 0;
> > > }
> > >
> > > Beats me. pseries? Badari has been diddling with the bolted memory code
> > > in git-powerpc...
> >
> > One of the machines is the Power5 and another is PowerMac G5, on which the
> > same kernel panic is seen.
>
> Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> should show what's happening in hpte_insert().
>
> cheers
>
Okay. Found it.
Root cause is:
mm-make-mem_map-allocation-continuous.patch
and its friends in -mm.
You have to call sparse_init_one_secti
RE: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
Sounds good, those are easy changes and make sense.
Since I'm a newbie, I don't know any better sometimes when I copy other
code that may not be as safe.
The same thing, of_get_property(np, "current-speed", NULL);, is done
right above my code I added.
Should the other code in the driver using the same method be fixed, or
just my patch?
Thanks for your patience,
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Grant Likely
Sent: Wednesday, April 02, 2008 12:00 PM
To: John Linn
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for
Xilinx uart 16550.
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
>
> Signed-off-by: John Linn <[EMAIL PROTECTED]>
Comments below...
> ---
> Documentation/powerpc/booting-without-of.txt | 11 +++
> drivers/serial/of_serial.c | 15 +--
> 2 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
> index 87f4d84..af112d9 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2539,6 +2539,17 @@ platforms are moved over to use the
flattened-device-tree model.
>differ between different families. May be
>'virtex2p', 'virtex4', or 'virtex5'.
>
> + iv) Xilinx Uart 16550
> +
> + Xilinx UART 16550 devices are very similar to the NS16550 such
that they
> + use the ns16550 binding with properties to specify register
spacing and
> + an offset from the base address.
> +
> + Requred properties:
> + - clock-frequency : Frequency of the clock input
> + - reg-offset : A value of 3 is required
> + - reg-shift : A value of 2 is required
> +
> More devices will be defined as this spec matures.
>
> VII - Specifying interrupt information for devices
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2efb892..af9ed48 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -30,7 +30,7 @@ static int __devinit
of_platform_serial_setup(struct of_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->node;
> - const unsigned int *clk, *spd;
> + const unsigned int *clk, *spd, *reg_offset, *reg_shift;
These should really be u32's I believe; on 64 bit architectures this
will misbehave (not an immediate practical problem, but it's best to
be explicit about these things).
> int ret;
>
> memset(port, 0, sizeof *port);
> @@ -48,7 +48,18 @@ static int __devinit
of_platform_serial_setup(struct of_device *ofdev,
> }
>
> spin_lock_init(&port->lock);
> - port->mapbase = resource.start;
> +
> + reg_offset = of_get_property(np, "reg-offset", NULL);
> + reg_shift = of_get_property(np, "reg-shift", NULL);
> +
> + if (!reg_offset)
> + port->mapbase = resource.start;
> + else
> + port->mapbase = resource.start + *reg_offset;
> +
> + if (reg_shift)
> + port->regshift = *reg_shift;
> +
This is a little unsafe since it doesn't check the property size, I'd
do the following instead:
port->mapbase = resource.start
/* Check for shifted address mapping */
prop = of_get_property(np, "reg-offset", &prop_size);
if (prop && (prop_size == sizeof(u32))
port->mapbase += *prop;
/* Check for registers offset within the devices address range */
prop = of_get_property(np, "reg-shift", &prop_size);
if (prop && (prop_size == sizeof(u32)))
port->regshift = *prop;
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based addressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the of_serial driver to handle the reg-offset
> and reg-shift properties to enable this core to be used.
>
> Signed-off-by: John Linn <[EMAIL PROTECTED]>
Comments below...
> ---
> Documentation/powerpc/booting-without-of.txt | 11 +++
> drivers/serial/of_serial.c | 15 +--
> 2 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/powerpc/booting-without-of.txt
> b/Documentation/powerpc/booting-without-of.txt
> index 87f4d84..af112d9 100644
> --- a/Documentation/powerpc/booting-without-of.txt
> +++ b/Documentation/powerpc/booting-without-of.txt
> @@ -2539,6 +2539,17 @@ platforms are moved over to use the
> flattened-device-tree model.
>differ between different families. May be
>'virtex2p', 'virtex4', or 'virtex5'.
>
> + iv) Xilinx Uart 16550
> +
> + Xilinx UART 16550 devices are very similar to the NS16550 such that
> they
> + use the ns16550 binding with properties to specify register spacing
> and
> + an offset from the base address.
> +
> + Requred properties:
> + - clock-frequency : Frequency of the clock input
> + - reg-offset : A value of 3 is required
> + - reg-shift : A value of 2 is required
> +
> More devices will be defined as this spec matures.
>
> VII - Specifying interrupt information for devices
> diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
> index 2efb892..af9ed48 100644
> --- a/drivers/serial/of_serial.c
> +++ b/drivers/serial/of_serial.c
> @@ -30,7 +30,7 @@ static int __devinit of_platform_serial_setup(struct
> of_device *ofdev,
> {
> struct resource resource;
> struct device_node *np = ofdev->node;
> - const unsigned int *clk, *spd;
> + const unsigned int *clk, *spd, *reg_offset, *reg_shift;
These should really be u32's I believe; on 64 bit architectures this
will misbehave (not an immediate practical problem, but it's best to
be explicit about these things).
> int ret;
>
> memset(port, 0, sizeof *port);
> @@ -48,7 +48,18 @@ static int __devinit of_platform_serial_setup(struct
> of_device *ofdev,
> }
>
> spin_lock_init(&port->lock);
> - port->mapbase = resource.start;
> +
> + reg_offset = of_get_property(np, "reg-offset", NULL);
> + reg_shift = of_get_property(np, "reg-shift", NULL);
> +
> + if (!reg_offset)
> + port->mapbase = resource.start;
> + else
> + port->mapbase = resource.start + *reg_offset;
> +
> + if (reg_shift)
> + port->regshift = *reg_shift;
> +
This is a little unsafe since it doesn't check the property size, I'd
do the following instead:
port->mapbase = resource.start
/* Check for shifted address mapping */
prop = of_get_property(np, "reg-offset", &prop_size);
if (prop && (prop_size == sizeof(u32))
port->mapbase += *prop;
/* Check for registers offset within the devices address range */
prop = of_get_property(np, "reg-shift", &prop_size);
if (prop && (prop_size == sizeof(u32)))
port->regshift = *prop;
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote:
> The Xilinx 16550 uart core is not a standard 16550 because it uses
> word-based addressing rather than byte-based adressing. With
> additional properties it is compatible with the open firmware
> 'ns16550' compatible binding.
>
> This code updates the ns16550 driver to use the reg-offset property
> so that the Xilinx UART 16550 can be used with it. The reg-shift
> was already being handled.
>
> Signed-off-by: John Linn <[EMAIL PROTECTED]>
Acked-by: Grant Likely <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/ns16550.c |5 +
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
> index f8f1b2f..da9d2c2 100644
> --- a/arch/powerpc/boot/ns16550.c
> +++ b/arch/powerpc/boot/ns16550.c
> @@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct
> serial_console_data *scdp)
> {
> int n;
> unsigned long reg_phys;
> + u32 reg_offset;
>
> n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
> if (n != sizeof(reg_base)) {
> @@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct
> serial_console_data *scdp)
> reg_base = (void *)reg_phys;
> }
>
> + n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
> + if (n == sizeof(reg_offset))
> + reg_base += reg_offset;
> +
> n = getprop(devp, "reg-shift", ®_shift, sizeof(reg_shift));
> if (n != sizeof(reg_shift))
> reg_shift = 0;
> --
> 1.5.2.1
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
On Wed, Apr 2, 2008 at 10:52 AM, John Linn <[EMAIL PROTECTED]> wrote: > From: Stephen Neuendorffer <[EMAIL PROTECTED]> > > The of_serial driver queries the current-speed property and attempts > to use it to register the custom_divisor property of the uart_port. > However, if current-speed is not set, then this code will dereference > a bad pointer. The fix is to only set custom_divisor when a > current-speed property appears in the device tree. > > Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> > Signed-off-by: John Linn <[EMAIL PROTECTED]> Acked-by: Grant Likely <[EMAIL PROTECTED]> Paul, can you please pick this one up for .25? It is pure bug fix. Thanks, g. > --- > drivers/serial/of_serial.c |4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c > index a64d858..2efb892 100644 > --- a/drivers/serial/of_serial.c > +++ b/drivers/serial/of_serial.c > @@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct > of_device *ofdev, > port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP > | UPF_FIXED_PORT; > port->dev = &ofdev->dev; > - port->custom_divisor = *clk / (16 * (*spd)); > + /* If current-speed was set, then try not to change it. */ > + if (spd) > + port->custom_divisor = *clk / (16 * (*spd)); > > return 0; > } > -- > 1.5.2.1 > > > > -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
On Wed, 2008-04-02 at 22:39 +0530, Kamalesh Babulal wrote:
> Michael Ellerman wrote:
> > On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> >> Andrew Morton wrote:
> >>> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> >>> wrote:
> >>>
> Hi Andrew,
>
> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
>
> [0.00] [ cut here ]
> [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
> [0.00] Oops: Exception in kernel mode, sig: 5 [#1]
> [0.00] SMP NR_CPUS=32 NUMA PowerMac
> [0.00] Modules linked in:
> [0.00] NIP: c03d1dcc LR: c03d1dc4 CTR:
> c002b6ac
> [0.00] REGS: c049b960 TRAP: 0700 Not tainted
> (2.6.25-rc8-mm1-autokern1)
> [0.00] MSR: 90021032 CR: 4488 XER:
> 2000
> [0.00] TASK = c03f9c90[0] 'swapper' THREAD:
> c0498000 CPU: 0
> [0.00] GPR00: c03d1dc4 c049bbe0 c04989d0
> 0001
> [0.00] GPR04: d59aca40f000 0b00 0010
>
> [0.00] GPR08: 0004 0001 c0027e520800
> c04bf0f0
> [0.00] GPR12: c04bf020 c03fa900
>
> [0.00] GPR16:
>
> [0.00] GPR20:
> 4140
> [0.00] GPR24: 017d64b0 c03d6250
> c0504000
> [0.00] GPR28: cf1f8000 0100
> cf00
> [0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4
> [0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4
> [0.00] Call Trace:
> [0.00] [c049bbe0] [c03d1dc4]
> .vmemmap_populate+0xb0/0xf4 (unreliable)
> [0.00] [c049bc70] [c03d2ee8]
> .sparse_mem_map_populate+0x38/0x60
> [0.00] [c049bd00] [c03c242c]
> .sparse_early_mem_map_alloc+0x54/0x94
> [0.00] [c049bd90] [c03c250c]
> .sparse_init+0xa0/0x20c
> [0.00] [c049be50] [c03ab7d0]
> .setup_arch+0x1ac/0x218
> [0.00] [c049bee0] [c03a36ac]
> .start_kernel+0xe0/0x3fc
> [0.00] [c049bf90] [c0008594]
> .start_here_common+0x54/0xc0
> [0.00] Instruction dump:
> [0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c e92289c8
> e96289c0 e9090002
> [0.00] e8eb0002 4bc575cd 6000 78630fe0 <0b03> 7214
> 7fbfe840 7fe3fb78
> [0.00] ---[ end trace 31fd0ba7d8756001 ]---
> [0.00] Kernel panic - not syncing: Attempted to kill the idle
> task!
>
> >>> int __meminit vmemmap_populate(struct page *start_page,
> >>> unsigned long nr_pages, int node)
> >>> {
> >>> unsigned long mode_rw;
> >>> unsigned long start = (unsigned long)start_page;
> >>> unsigned long end = (unsigned long)(start_page + nr_pages);
> >>> unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> >>>
> >>> mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> >>>
> >>> /* Align to the page size of the linear mapping. */
> >>> start = _ALIGN_DOWN(start, page_size);
> >>>
> >>> for (; start < end; start += page_size) {
> >>> int mapped;
> >>> void *p;
> >>>
> >>> if (vmemmap_populated(start, page_size))
> >>> continue;
> >>>
> >>> p = vmemmap_alloc_block(page_size, node);
> >>> if (!p)
> >>> return -ENOMEM;
> >>>
> >>> pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> >>> start, p, __pa(p));
> >>>
> >>> mapped = htab_bolt_mapping(start, start + page_size,
> >>> __pa(p), mode_rw, mmu_linear_psize,
> >>> mmu_kernel_ssize);
> >>> =>BUG_ON(mapped < 0);
> >>> }
> >>>
> >>> return 0;
> >>> }
> >>>
> >>> Beats me. pseries? Badari has been diddling with the bolted memory code
> >>> in git-powerpc...
> >> One of the machines is the Power5 and another is PowerMac G5, on which the
> >> same kernel panic is seen.
> >
> > Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> > should show what's happening in hpte_insert().
> >
> > cheers
> >
> Just define DEBUG_LOW did not fetch and debug information, so added some
> printk to
> htab_bolt_mapping () and pSeri
Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
Michael Ellerman wrote:
> On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
>> Andrew Morton wrote:
>>> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
>>> wrote:
>>>
Hi Andrew,
The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
[0.00] [ cut here ]
[0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
[0.00] Oops: Exception in kernel mode, sig: 5 [#1]
[0.00] SMP NR_CPUS=32 NUMA PowerMac
[0.00] Modules linked in:
[0.00] NIP: c03d1dcc LR: c03d1dc4 CTR:
c002b6ac
[0.00] REGS: c049b960 TRAP: 0700 Not tainted
(2.6.25-rc8-mm1-autokern1)
[0.00] MSR: 90021032 CR: 4488 XER:
2000
[0.00] TASK = c03f9c90[0] 'swapper' THREAD:
c0498000 CPU: 0
[0.00] GPR00: c03d1dc4 c049bbe0 c04989d0
0001
[0.00] GPR04: d59aca40f000 0b00 0010
[0.00] GPR08: 0004 0001 c0027e520800
c04bf0f0
[0.00] GPR12: c04bf020 c03fa900
[0.00] GPR16:
[0.00] GPR20:
4140
[0.00] GPR24: 017d64b0 c03d6250
c0504000
[0.00] GPR28: cf1f8000 0100
cf00
[0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4
[0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4
[0.00] Call Trace:
[0.00] [c049bbe0] [c03d1dc4]
.vmemmap_populate+0xb0/0xf4 (unreliable)
[0.00] [c049bc70] [c03d2ee8]
.sparse_mem_map_populate+0x38/0x60
[0.00] [c049bd00] [c03c242c]
.sparse_early_mem_map_alloc+0x54/0x94
[0.00] [c049bd90] [c03c250c]
.sparse_init+0xa0/0x20c
[0.00] [c049be50] [c03ab7d0]
.setup_arch+0x1ac/0x218
[0.00] [c049bee0] [c03a36ac]
.start_kernel+0xe0/0x3fc
[0.00] [c049bf90] [c0008594]
.start_here_common+0x54/0xc0
[0.00] Instruction dump:
[0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c e92289c8
e96289c0 e9090002
[0.00] e8eb0002 4bc575cd 6000 78630fe0 <0b03> 7214
7fbfe840 7fe3fb78
[0.00] ---[ end trace 31fd0ba7d8756001 ]---
[0.00] Kernel panic - not syncing: Attempted to kill the idle task!
>>> int __meminit vmemmap_populate(struct page *start_page,
>>> unsigned long nr_pages, int node)
>>> {
>>> unsigned long mode_rw;
>>> unsigned long start = (unsigned long)start_page;
>>> unsigned long end = (unsigned long)(start_page + nr_pages);
>>> unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
>>>
>>> mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
>>>
>>> /* Align to the page size of the linear mapping. */
>>> start = _ALIGN_DOWN(start, page_size);
>>>
>>> for (; start < end; start += page_size) {
>>> int mapped;
>>> void *p;
>>>
>>> if (vmemmap_populated(start, page_size))
>>> continue;
>>>
>>> p = vmemmap_alloc_block(page_size, node);
>>> if (!p)
>>> return -ENOMEM;
>>>
>>> pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
>>> start, p, __pa(p));
>>>
>>> mapped = htab_bolt_mapping(start, start + page_size,
>>> __pa(p), mode_rw, mmu_linear_psize,
>>> mmu_kernel_ssize);
>>> => BUG_ON(mapped < 0);
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> Beats me. pseries? Badari has been diddling with the bolted memory code
>>> in git-powerpc...
>> One of the machines is the Power5 and another is PowerMac G5, on which the
>> same kernel panic is seen.
>
> Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
> should show what's happening in hpte_insert().
>
> cheers
>
Just define DEBUG_LOW did not fetch and debug information, so added some printk
to
htab_bolt_mapping () and pSeries_lpar_hpte_insert ()
[boot]0012 Setup Arch
htab_bolt_mapping (vstart cf00, vend cf000100, pstart
300,mode 190, psize 4, ssize 0)
htab_bolt_mapping: calling c0888f00
_hpte_insert(group=252078, va=d59aca40f0
Re: [RESEND3 PATCH] [POWERPC] mpc5200: Amalgamated DTS fixes and updates
+ lpb {
+ model = "fsl,lpb";
+ compatible = "fsl,lpb";
Please use a more descriptive name, if you can still change the binding.
"localplus" or something like that.
Maybe it's time to start an International Obfuscated Device Tree
Contest,
to serve as a warning by example?
:-)
Segher
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
On Wed, 2008-04-02 at 09:42 -0700, Carl Love wrote:
> On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
> > On Tuesday 25 March 2008, Carl Love wrote:
> > > This patch fixes a bug in the code that records the SPU data and
> > > context switches. The buffer_mutex lock must be held when the
> > > kernel is adding data to the buffer between the kernel and the
> > > OProfile daemon. The lock is not being held in the current code
> > > base. This patch fixes the bug using work queues. The data to
> > > be passed to the daemon is caputured by the interrupt handler.
> > > The workqueue function is invoked to grab the buffer_mutex lock
> > > and add the data to the buffer.
> >
> > So what was the exact bug you're fixing with this? There was no
> > buffer_mutex before, so why do you need it now? Can't this be a
> > spinlock so you can get it from interrupt context instead of
> > using a workqueue?
>
> The generic OProfile code defines a mutex lock, called buffer_mutex, to
> protect the kernel/daemon data buffer from being writen by the kernal
> and simultaneously read by the Daemon. When adding a PPU sample the
> oprofile routine oprofile_add_ext_sample(pc, regs, i, is_kernel) is
> called from the interrupt context to request the sample be stored. The
> generic oprofile code takes care of passing the data to a non interrupt
> context where the mutex lock is held and the necessary sequence of data
> is written into the kernel/daemon data buffer. However, OProfile does
> not have any built in functions for handling the SPU. Hence, we have to
> implement the code to capture the data in the interrupt context, pass it
> to a non interrupt context and put it into the buffer. This was not
> done correctly in the original implementation. Specifically, the mutex
> lock was not being held.
>
> Writing data to the OProfile buffer consists of a sequence of items.
> For example when writing an SPU entry, first comes the escape code so
> the daemon knows this is a new entry. The next item is the SPU context
> switch code which says the data which will follow is the information
> about a new context. There is a different code to identify the data as
> an address sample. Finally the data about the SPU context switch is
> entered into the buffer. The issue is the OProfile daemon is read all
> of the entire sequence of items then process the data. Without the
> mutex lock, the daemon may read part of the sequence try to process it
> before everything is written into the buffer. When the daemon reads
> again, it doesn't see the escape code as the first item and isn't smart
> enough to realize it is part of a previous sequence. The generic
> OProfile code defines the mutex lock and calls it buffer_mutex. The
> OProfile kernel/daemon API uses the mutex lock. The mutex lock can only
> be held in a non interrupt context. The current implementation uses a
> spin lock to make sure the kernel writes each sequence if items into the
> buffer but since the API does not use a spin lock we have no way to
> prevent the daemon from reading the buffer until the entire sequence of
> items has been written to the buffer. Hence the need to hold the
> buffer_mutex lock which prevents the daemon from accessing the buffer.
>
> >
> > > Index: linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > > ===
> > > --- linux-2.6.25-rc4.orig/arch/powerpc/oprofile/cell/spu_profiler.c
> > > +++ linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > > @@ -16,6 +16,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include "pr_util.h"
> > >
> >
> > Please keep #include statements in alphabetical order, with all linux/ files
> > before the asm/ files.
> >
> > > #define TRACE_ARRAY_SIZE 1024
> > > @@ -32,9 +33,19 @@ static unsigned int profiling_interval;
> > >
> > > #define SPU_PC_MASK 0x
> > >
> > > +/* The generic OProfile code uses the buffer_mutex to protect the buffer
> > > + * between the kernel and the daemon. The SPU code needs to use the
> > > buffer
> > > + * to ensure that the kernel SPU writes complete as a single block before
> > > + * being consumed by the daemon.
> > > + */
> > > +extern struct mutex buffer_mutex;
> > > +
> > > static DEFINE_SPINLOCK(sample_array_lock);
> > > unsigned long sample_array_lock_flags;
> > >
> > > +struct work_struct spu_record_wq;
> > > +extern struct workqueue_struct *oprofile_spu_wq;
> > > +
> > > void set_spu_profiling_frequency(unsigned int freq_khz, unsigned int
> > > cycles_reset)
> > > {
> > > unsigned long ns_per_cyc;
> >
> > Never put extern statements in the implementation, they describe the
> > interface between two parts of the code and should be inside of a
> > common header.
> >
> > Why do you want to have your own workqueue instead of using the
> > global one?
It is important that the data get context switch data get recorde
Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
Ideally we get set the phys address the PHDR, but I'm not sure how to get the linker to do that. I think you want to look at "AT" in the ld manual. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 3/3][POWERPC][V2] Xilinx: boot support for Xilinx uart 16550.
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based adressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the ns16550 driver to use the reg-offset property
so that the Xilinx UART 16550 can be used with it. The reg-shift
was already being handled.
Signed-off-by: John Linn <[EMAIL PROTECTED]>
---
arch/powerpc/boot/ns16550.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/ns16550.c b/arch/powerpc/boot/ns16550.c
index f8f1b2f..da9d2c2 100644
--- a/arch/powerpc/boot/ns16550.c
+++ b/arch/powerpc/boot/ns16550.c
@@ -56,6 +56,7 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
{
int n;
unsigned long reg_phys;
+ u32 reg_offset;
n = getprop(devp, "virtual-reg", ®_base, sizeof(reg_base));
if (n != sizeof(reg_base)) {
@@ -65,6 +66,10 @@ int ns16550_console_init(void *devp, struct
serial_console_data *scdp)
reg_base = (void *)reg_phys;
}
+ n = getprop(devp, "reg-offset", ®_offset, sizeof(reg_offset));
+ if (n == sizeof(reg_offset))
+ reg_base += reg_offset;
+
n = getprop(devp, "reg-shift", ®_shift, sizeof(reg_shift));
if (n != sizeof(reg_shift))
reg_shift = 0;
--
1.5.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3][POWERPC][V2] Xilinx: of_serial support for Xilinx uart 16550.
The Xilinx 16550 uart core is not a standard 16550 because it uses
word-based addressing rather than byte-based addressing. With
additional properties it is compatible with the open firmware
'ns16550' compatible binding.
This code updates the of_serial driver to handle the reg-offset
and reg-shift properties to enable this core to be used.
Signed-off-by: John Linn <[EMAIL PROTECTED]>
---
Documentation/powerpc/booting-without-of.txt | 11 +++
drivers/serial/of_serial.c | 15 +--
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt
b/Documentation/powerpc/booting-without-of.txt
index 87f4d84..af112d9 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -2539,6 +2539,17 @@ platforms are moved over to use the
flattened-device-tree model.
differ between different families. May be
'virtex2p', 'virtex4', or 'virtex5'.
+ iv) Xilinx Uart 16550
+
+ Xilinx UART 16550 devices are very similar to the NS16550 such that they
+ use the ns16550 binding with properties to specify register spacing and
+ an offset from the base address.
+
+ Requred properties:
+ - clock-frequency : Frequency of the clock input
+ - reg-offset : A value of 3 is required
+ - reg-shift : A value of 2 is required
+
More devices will be defined as this spec matures.
VII - Specifying interrupt information for devices
diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c
index 2efb892..af9ed48 100644
--- a/drivers/serial/of_serial.c
+++ b/drivers/serial/of_serial.c
@@ -30,7 +30,7 @@ static int __devinit of_platform_serial_setup(struct
of_device *ofdev,
{
struct resource resource;
struct device_node *np = ofdev->node;
- const unsigned int *clk, *spd;
+ const unsigned int *clk, *spd, *reg_offset, *reg_shift;
int ret;
memset(port, 0, sizeof *port);
@@ -48,7 +48,18 @@ static int __devinit of_platform_serial_setup(struct
of_device *ofdev,
}
spin_lock_init(&port->lock);
- port->mapbase = resource.start;
+
+ reg_offset = of_get_property(np, "reg-offset", NULL);
+ reg_shift = of_get_property(np, "reg-shift", NULL);
+
+ if (!reg_offset)
+ port->mapbase = resource.start;
+ else
+ port->mapbase = resource.start + *reg_offset;
+
+ if (reg_shift)
+ port->regshift = *reg_shift;
+
port->irq = irq_of_parse_and_map(np, 0);
port->iotype = UPIO_MEM;
port->type = type;
--
1.5.2.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3][POWERPC][V2] of_serial: Fix possible null dereference.
From: Stephen Neuendorffer <[EMAIL PROTECTED]> The of_serial driver queries the current-speed property and attempts to use it to register the custom_divisor property of the uart_port. However, if current-speed is not set, then this code will dereference a bad pointer. The fix is to only set custom_divisor when a current-speed property appears in the device tree. Signed-off-by: Stephen Neuendorffer <[EMAIL PROTECTED]> Signed-off-by: John Linn <[EMAIL PROTECTED]> --- drivers/serial/of_serial.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/serial/of_serial.c b/drivers/serial/of_serial.c index a64d858..2efb892 100644 --- a/drivers/serial/of_serial.c +++ b/drivers/serial/of_serial.c @@ -56,7 +56,9 @@ static int __devinit of_platform_serial_setup(struct of_device *ofdev, port->flags = UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF | UPF_IOREMAP | UPF_FIXED_PORT; port->dev = &ofdev->dev; - port->custom_divisor = *clk / (16 * (*spd)); + /* If current-speed was set, then try not to change it. */ + if (spd) + port->custom_divisor = *clk / (16 * (*spd)); return 0; } -- 1.5.2.1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3] [POWERPC] [V2][RFC] of_serial and boot patches introduction
I am sending V2 series of patches that fix the OF serial driver and add support to it and the boot for the Xilinx UART 16550. The ePAPR, although not a formal spec yet, proposes allowing reg-shift for ns16550. We believe this is a reasonable approach and have implemented it in this patch series. We've tried to integrate the consensus from the previous comments also. [v1] I am sending a series of patches that fix the OF serial driver and add support to it and the boot for the Xilinx UART 16550. I think we have tried to satisfy previous concerns about UARTs which are non-standard as the Xilinx 16550 is (register spacing and offset). We would like to have these pulled into 2.6.26. Thanks, John ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote:
> On Tuesday 25 March 2008, Carl Love wrote:
> > This patch fixes a bug in the code that records the SPU data and
> > context switches. The buffer_mutex lock must be held when the
> > kernel is adding data to the buffer between the kernel and the
> > OProfile daemon. The lock is not being held in the current code
> > base. This patch fixes the bug using work queues. The data to
> > be passed to the daemon is caputured by the interrupt handler.
> > The workqueue function is invoked to grab the buffer_mutex lock
> > and add the data to the buffer.
>
> So what was the exact bug you're fixing with this? There was no
> buffer_mutex before, so why do you need it now? Can't this be a
> spinlock so you can get it from interrupt context instead of
> using a workqueue?
The generic OProfile code defines a mutex lock, called buffer_mutex, to
protect the kernel/daemon data buffer from being writen by the kernal
and simultaneously read by the Daemon. When adding a PPU sample the
oprofile routine oprofile_add_ext_sample(pc, regs, i, is_kernel) is
called from the interrupt context to request the sample be stored. The
generic oprofile code takes care of passing the data to a non interrupt
context where the mutex lock is held and the necessary sequence of data
is written into the kernel/daemon data buffer. However, OProfile does
not have any built in functions for handling the SPU. Hence, we have to
implement the code to capture the data in the interrupt context, pass it
to a non interrupt context and put it into the buffer. This was not
done correctly in the original implementation. Specifically, the mutex
lock was not being held.
Writing data to the OProfile buffer consists of a sequence of items.
For example when writing an SPU entry, first comes the escape code so
the daemon knows this is a new entry. The next item is the SPU context
switch code which says the data which will follow is the information
about a new context. There is a different code to identify the data as
an address sample. Finally the data about the SPU context switch is
entered into the buffer. The issue is the OProfile daemon is read all
of the entire sequence of items then process the data. Without the
mutex lock, the daemon may read part of the sequence try to process it
before everything is written into the buffer. When the daemon reads
again, it doesn't see the escape code as the first item and isn't smart
enough to realize it is part of a previous sequence. The generic
OProfile code defines the mutex lock and calls it buffer_mutex. The
OProfile kernel/daemon API uses the mutex lock. The mutex lock can only
be held in a non interrupt context. The current implementation uses a
spin lock to make sure the kernel writes each sequence if items into the
buffer but since the API does not use a spin lock we have no way to
prevent the daemon from reading the buffer until the entire sequence of
items has been written to the buffer. Hence the need to hold the
buffer_mutex lock which prevents the daemon from accessing the buffer.
>
> > Index: linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > ===
> > --- linux-2.6.25-rc4.orig/arch/powerpc/oprofile/cell/spu_profiler.c
> > +++ linux-2.6.25-rc4/arch/powerpc/oprofile/cell/spu_profiler.c
> > @@ -16,6 +16,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include "pr_util.h"
> >
>
> Please keep #include statements in alphabetical order, with all linux/ files
> before the asm/ files.
>
> > #define TRACE_ARRAY_SIZE 1024
> > @@ -32,9 +33,19 @@ static unsigned int profiling_interval;
> >
> > #define SPU_PC_MASK 0x
> >
> > +/* The generic OProfile code uses the buffer_mutex to protect the buffer
> > + * between the kernel and the daemon. The SPU code needs to use the buffer
> > + * to ensure that the kernel SPU writes complete as a single block before
> > + * being consumed by the daemon.
> > + */
> > +extern struct mutex buffer_mutex;
> > +
> > static DEFINE_SPINLOCK(sample_array_lock);
> > unsigned long sample_array_lock_flags;
> >
> > +struct work_struct spu_record_wq;
> > +extern struct workqueue_struct *oprofile_spu_wq;
> > +
> > void set_spu_profiling_frequency(unsigned int freq_khz, unsigned int
> > cycles_reset)
> > {
> > unsigned long ns_per_cyc;
>
> Never put extern statements in the implementation, they describe the
> interface between two parts of the code and should be inside of a
> common header.
>
> Why do you want to have your own workqueue instead of using the
> global one?
>
> > @@ -123,14 +134,14 @@ static int cell_spu_pc_collection(int cp
> > return entry;
> > }
> >
> > -
> > -static enum hrtimer_restart profile_spus(struct hrtimer *timer)
> > -{
> > - ktime_t kt;
> > +static void profile_spus_record_samples (struct work_struct *ws) {
> > + /* This routine is called
Re: [PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
On Wednesday 02 April 2008, Stefan Roese wrote: > This patch adds basic endpoint support to the 4xx PCIe driver. This should have been an RFC. Sorry I missed adding it to the subject. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 4xx: Add endpoint support to 4xx PCIe driver
This patch adds basic endpoint support to the 4xx PCIe driver.
This is done by checking whether the PCIe port is already configured as
root-complex or as endpoint. This has been done previously in U-Boot and
can be configured there dynamically by setting the "pcie_mode"
environment variable (reboot necessary of course). Here an example:
pcie_mode = 'RP:RP:EP'
Port 0 & 1 are configured as root-complex and port 2 as endpoint.
This mode will now be used in the Linux driver too.
Note: Currently we map a fixed 64MByte window to PLB address 0 (SDRAM).
This should probably be configurable via a dts property.
Signed-off-by: Stefan Roese <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/ppc4xx_pci.c | 133 +++---
1 files changed, 96 insertions(+), 37 deletions(-)
diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index d183b83..013fd05 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -563,6 +563,18 @@ struct ppc4xx_pciex_hwops
static struct ppc4xx_pciex_hwops *ppc4xx_pciex_hwops;
+static int is_endpoint(struct ppc4xx_pciex_port *port)
+{
+ u32 val;
+
+ val = mfdcri(SDR0, port->sdr_base + PESDRn_DLPSET);
+
+ if (((val >> 20) & 0xf) == PTYPE_LEGACY_ENDPOINT)
+ return 1;
+ else
+ return 0;
+}
+
#ifdef CONFIG_44x
/* Check various reset bits of the 440SPe PCIe core */
@@ -1400,28 +1412,59 @@ static void __init ppc4xx_configure_pciex_PIMs(struct
ppc4xx_pciex_port *port,
resource_size_t size = res->end - res->start + 1;
u64 sa;
- /* Calculate window size */
- sa = (0xull << ilog2(size));;
- if (res->flags & IORESOURCE_PREFETCH)
- sa |= 0x8;
+ if (port->endpoint) {
+ resource_size_t ep_addr = 0;
+ resource_size_t ep_size = 32 << 20;
- out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
- out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
+ /* Currently we map a fixed 64MByte window to PLB address
+* 0 (SDRAM). This should probably be configurable via a dts
+* property.
+*/
+
+ /* Calculate window size */
+ sa = (0xull << ilog2(ep_size));;
+
+ /* Setup BAR0 */
+ out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa) |
+PCI_BASE_ADDRESS_MEM_TYPE_64);
- /* The setup of the split looks weird to me ... let's see if it works */
- out_le32(mbase + PECFG_PIM0LAL, 0x);
- out_le32(mbase + PECFG_PIM0LAH, 0x);
- out_le32(mbase + PECFG_PIM1LAL, 0x);
- out_le32(mbase + PECFG_PIM1LAH, 0x);
- out_le32(mbase + PECFG_PIM01SAH, 0x);
- out_le32(mbase + PECFG_PIM01SAL, 0x);
+ /* Disable BAR1 & BAR2 */
+ out_le32(mbase + PECFG_BAR1MPA, 0);
+ out_le32(mbase + PECFG_BAR2HMPA, 0);
+ out_le32(mbase + PECFG_BAR2LMPA, 0);
+
+ out_le32(mbase + PECFG_PIM01SAH, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_PIM01SAL, RES_TO_U32_LOW(sa));
+
+ out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(ep_addr));
+ out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(ep_addr));
+ } else {
+ /* Calculate window size */
+ sa = (0xull << ilog2(size));;
+ if (res->flags & IORESOURCE_PREFETCH)
+ sa |= 0x8;
+
+ out_le32(mbase + PECFG_BAR0HMPA, RES_TO_U32_HIGH(sa));
+ out_le32(mbase + PECFG_BAR0LMPA, RES_TO_U32_LOW(sa));
+
+ /* The setup of the split looks weird to me ... let's see
+* if it works
+*/
+ out_le32(mbase + PECFG_PIM0LAL, 0x);
+ out_le32(mbase + PECFG_PIM0LAH, 0x);
+ out_le32(mbase + PECFG_PIM1LAL, 0x);
+ out_le32(mbase + PECFG_PIM1LAH, 0x);
+ out_le32(mbase + PECFG_PIM01SAH, 0x);
+ out_le32(mbase + PECFG_PIM01SAL, 0x);
+
+ out_le32(mbase + PCI_BASE_ADDRESS_0,
RES_TO_U32_LOW(res->start));
+ out_le32(mbase + PCI_BASE_ADDRESS_1,
RES_TO_U32_HIGH(res->start));
+ }
/* Enable inbound mapping */
out_le32(mbase + PECFG_PIMEN, 0x1);
- out_le32(mbase + PCI_BASE_ADDRESS_0, RES_TO_U32_LOW(res->start));
- out_le32(mbase + PCI_BASE_ADDRESS_1, RES_TO_U32_HIGH(res->start));
-
/* Enable I/O, Mem, and Busmaster cycles */
out_le16(mbase + PCI_COMMAND,
in_le16(mbase + PCI_COMMAND) |
@@ -1436,13 +1479,6 @@ static void __init ppc4xx_pciex_port_setup_hose(struct
ppc4xx_pciex_port *port)
Re: ARCH=ppc vs powerpc
Sorry, although it's related to linuxppc, I intended to post this question to the buildroot mailing list. -- Guillaume Dargaud http://www.gdargaud.net/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Fix CPM2 SCC1 clock initialization.
A missing break statement in a switch caused cpm2_clk_setup() to initialize SCC2 instead of SCC1. This patch fixes the bug. Signed-off-by: Laurent Pinchart <[EMAIL PROTECTED]> --- arch/powerpc/sysdev/cpm2.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c index 57ed1a4..7478e81 100644 --- a/arch/powerpc/sysdev/cpm2.c +++ b/arch/powerpc/sysdev/cpm2.c @@ -246,6 +246,7 @@ int cpm2_clk_setup(enum cpm_clk_target target, int clock, int mode) case CPM_CLK_SCC1: reg = &im_cpmux->cmx_scr; shift = 24; + break; case CPM_CLK_SCC2: reg = &im_cpmux->cmx_scr; shift = 16; -- 1.5.0 -- Laurent Pinchart CSE Semaphore Belgium Chaussée de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 pgpIDUh4QtnOV.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull powerpc.git merge branch
Paul Mackerras wrote: Bartlomiej Sieka writes: What about http://patchwork.ozlabs.org/linuxppc/patch?id=17525 ? I don't see it in the merge branch of your repository, and it would be nice to get it upstream as it fixes boot problems on some MPC5200-based boards. It needs a proper stand-alone commit message and an acked-by from Grant. The commit message should explain why you are making the changes you are making rather than just saying "the bulk of this patch is taken from http://...";. Paul, Just re-sent the patch, please see http://patchwork.ozlabs.org/linuxppc/patch?id=17678; hopefully everything is OK now. (Note that I've dropped [EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL PROTECTED] from the CC:) Regards, Bartlomiej ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RESEND3 PATCH] [POWERPC] mpc5200: Amalgamated DTS fixes and updates
DTS updates that fix booting problems:
- change to ethernet reg property
- addition of mdio and phy nodes
- removal of pci node (Motion-Pro board)
Other DTS updates:
- update i2c device tree nodes
- add lpb bus node and flash device (without partitions defined)
- add rtc i2c nodes
Signed-off-by: Marian Balakowicz <[EMAIL PROTECTED]>
Acked-by: Grant Likely <[EMAIL PROTECTED]>
---
Changes since previous submission:
- added patch description
- added a space between "phy0:" and "ethernet-phy" per David Gibson's
suggestion.
arch/powerpc/boot/dts/cm5200.dts| 37 -
arch/powerpc/boot/dts/motionpro.dts | 63 +++
arch/powerpc/boot/dts/tqm5200.dts | 42 +++
3 files changed, 112 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/boot/dts/cm5200.dts b/arch/powerpc/boot/dts/cm5200.dts
index 30737ea..c6ca631 100644
--- a/arch/powerpc/boot/dts/cm5200.dts
+++ b/arch/powerpc/boot/dts/cm5200.dts
@@ -212,13 +212,30 @@
[EMAIL PROTECTED] {
device_type = "network";
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to
setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command
finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0: [EMAIL PROTECTED] {
+ device_type = "ethernet-phy";
+ reg = <0>;
+ };
};
[EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
compatible =
"fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
reg = <3d40 40>;
interrupts = <2 10 0>;
@@ -231,4 +248,22 @@
reg = <8000 4000>;
};
};
+
+ lpb {
+ model = "fsl,lpb";
+ compatible = "fsl,lpb";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ ranges = <0 0 fc00 200>;
+
+ // 16-bit flash device at LocalPlus Bus CS0
+ [EMAIL PROTECTED],0 {
+ compatible = "cfi-flash";
+ reg = <0 0 200>;
+ bank-width = <2>;
+ device-width = <2>;
+ #size-cells = <1>;
+ #address-cells = <1>;
+ };
+ };
};
diff --git a/arch/powerpc/boot/dts/motionpro.dts
b/arch/powerpc/boot/dts/motionpro.dts
index 76951ab..2b0dde0 100644
--- a/arch/powerpc/boot/dts/motionpro.dts
+++ b/arch/powerpc/boot/dts/motionpro.dts
@@ -148,7 +148,6 @@
interrupt-parent = <&mpc5200_pic>;
};
-
[EMAIL PROTECTED] {
compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
reg = ;
@@ -209,10 +208,25 @@
[EMAIL PROTECTED] {
device_type = "network";
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
- reg = <3000 800>;
+ reg = <3000 400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
+ phy-handle = <&phy0>;
+ };
+
+ [EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,mpc5200b-mdio","fsl,mpc5200-mdio";
+ reg = <3000 400>; // fec range, since we need to
setup fec interrupts
+ interrupts = <2 5 0>; // these are for "mii command
finished", not link changes & co.
+ interrupt-parent = <&mpc5200_pic>;
+
+ phy0: [EMAIL PROTECTED] {
+ device_type = "ethernet-phy";
+ reg = <2>;
+ };
};
[EMAIL PROTECTED] {
@@ -223,11 +237,19 @@
};
[EMAIL PROTECTED] {
+ #address-cells = <1>;
+
ARCH=ppc vs powerpc
Anyone care to comment on that:
$ make ARCH=ppc linux26-menuconfig
[ -f
/home/guinevere/buildroot/project_build_ppc/genepy/linux-2.6.24/.config ] |
| cp local/genepy/linux-2.6.24.config
/home/guinevere/buildroot/project_build_pp
c/genepy/linux-2.6.24/.config
/usr/bin/make -j1 HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=powerpc
[...]
Why does ARCH change ?!?
[...]
.config:132:warning: trying to assign nonexistent symbol XILINX_ML405
[...]
$ find -name Kconfig -exec grep -H XILINX_ML405 {} \;
./toolchain_build_powerpc/linux-2.6.24/arch/ppc/platforms/4xx/Kconfig:config
XILINX_ML405
./project_build_ppc/genepy/linux-2.6.24/arch/ppc/platforms/4xx/Kconfig:config
XILINX_ML405
./toolchain_build_ppc/linux-2.6.24/arch/ppc/platforms/4xx/Kconfig:config
XILINX_ML405
Well, it's no surprise that it won't find them if it looks in the powerpc
branch...
The question is why ?
--
Guillaume Dargaud
http://www.gdargaud.net/
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2 v5] Add DIU platform code for MPC8610HPCD
On Tue, 2008-04-01 at 14:00 -0700, Andrew Morton wrote: > On Mon, 31 Mar 2008 11:23:25 -0500 > York Sun <[EMAIL PROTECTED]> wrote: > > > Add platform code to support Freescale DIU. The platform code includes > > framebuffer memory allocation, pixel format, monitor port, etc. > > > > Signed-off-by: York Sun <[EMAIL PROTECTED]> > > Signed-off-by: Timur Tabi <[EMAIL PROTECTED]> > > --- > > This patch addes platform support for Freescale DIU driver, targeting > > 2.6.26 kernel. > > > > arch/powerpc/configs/mpc8610_hpcd_defconfig | 198 > > +++ > > arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 190 > > -- > > arch/powerpc/sysdev/fsl_soc.c | 41 ++ > > arch/powerpc/sysdev/fsl_soc.h | 23 +++ > > 4 files changed, 413 insertions(+), 39 deletions(-) > > The defconfig change gets almost 100% rejects and probably isn't > appropriate here and isn't very important. I dropped that part of the > patch. > It's OK. York ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: psc and spi
Hello,
> On 1/15/08, S. Fricke <[EMAIL PROTECTED]> wrote:
> > Hello friends,
> >
> > I have on the psc3 the spi-interface of a fpga connected.
> >
> >psc3-0 - MOSI
> >psc3-1 - MISO
> >psc3-2 - CLK
> >psc3-3 - SlaveSelect
> >psc3-4 - CS-FPGA
> >psc3-5 - CS Another device
> >psc3-6 - SPI-SEL0
> >psc3-7 - SPI-SEL1
> >psc3-8/9 - Not connected
> >
> > Can I use the mpc52xx_psc_spi-driver? And if yes, how I have to use this
> > driver? Or must I write a own spi-master/slave thing? Can anyone point me
> > to a good start-position?
>
> Yes, you should be able to use the mpc52xx_psc_spi driver. You'' need
> to add the activate_cs and deactivate_cs hooks in your platform code
> to activate your SPI CS lines. You'll also need to set port_config to
> have the PSC3 pins in "CODEC3" mode.
OK, I defined a "fsl_spi_platform_data" for my "activate_cs" and
"deactivate_cs". This structure I have insert in a "spi_board_info" with
all other mandatory Informations.
When I load "mpc52xx_psc_spi", then I get a "mpc52xx-psc-spi f0002400.spi:
probe called without platform data, no (de)activate_cs function will be
called"
What is wrong in my setup or did I have forget something?
static void activate_cs(u8 cs, u8 polarity) {/* ... */ }
static void deactivate_cs(u8 cs, u8 polarity) {/* ...*/}
static struct fsl_spi_platform_data my_spi_p_data = {
.bus_num = 0x2400,
.max_chipselect = 3,
.activate_cs = activate_cs,
.deactivate_cs = deactivate_cs,
};
static struct spi_board_info my_spi_boardinfo = {
.bus_num = 0x2400,
.chip_select = 0,
.max_speed_hz = 1000,
.modalias = "my-spi-device",
.platform_data = &my_spi_p_data,
};
static int __init ipek01_spi_init(void) {
int ret;
return fsl_spi_init(&my_spi_boardinfo, 1, activate_cs, deactivate_cs);
}
device_initcall(ipek01_spi_init);
best regards,
Silvio Fricke
--
-- S. Fricke [EMAIL PROTECTED] --
Diplom-Informatiker (FH) TEL: (+49)8330-911278
Linux-Entwicklung JABBER: [EMAIL PROTECTED]
pgp4nbN8xiILb.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/11] [POWERPC] bootwrapper: Allow specifying of image physical offset
On Apr 1, 2008, at 7:58 PM, Paul Mackerras wrote: Kumar Gala writes: Hmm, need to think about that. But my initial reaction is two fold. One I don't think this information would be around and two don't we already have this problem with a kdump kernel? I'm just concerned that we have two things that have to match up - the compiled-in physical address that the kernel assumes it is running at, and the physical address where it is actually loaded. While those two things were both always 0 for embedded processors, there wasn't a problem, but now we can have a situation where a kernel binary has to be loaded at some nonzero address to work correctly, but there is no way to work out what that address is for an existing vmlinux binary. Or have I missed something? Nope, that sums up the situation pretty well. For a kdump kernel, at least for 64-bit, the physical address has to be 32MB. There is no other choice, so there is no possibility of confusion. But how do you know a vmlinux image is for kdump or not? For 85xx, would it be possible to have the kernel figure out what physical address it has been loaded at, and use that as the base address, rather than having the base address set at compile time? Yes, that is what CONFIG_RELOCATABLE is all about. That would solve my objection since it would mean that there would no longer be two things that had to be kept in sync. You could pass any value to wrapper/mkimage (subject to constraints such as it has to be a multiple of 256M) and it would work. That value could even come from a config option in the case where wrapper is invoked as part of the kernel build, but that config option shouldn't affect anything at all in the vmlinux. Ok, but I still think the issues exists when we config PHYSICAL_START to non-zero and CONFIG_RELOCATABLE=n. Ideally we get set the phys address the PHDR, but I'm not sure how to get the linker to do that. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'for-2.6.25' branch
On Apr 2, 2008, at 6:48 AM, Paul Mackerras wrote: Kumar Gala writes: Paul, any comments on sending this onto linus. I was hoping to avoid 2.6.25 coming up not support the proper device bindings for DMA and SATA. I've pulled it and I'll send it on later (or Linus can pull it directly if he wants). There is the iSeries fix from Ben H plus two other patches (one from Bartlomiej Sieka and one from Nathan Lynch) where I'm waiting for proper patch descriptions and/or signed-off-by lines. I was hoping to get those tomorrow and send the lot on to Linus. Ok, just wasn't sure what the status was. A day or two is fine. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Move phys_addr_t definition into asm/types.h
On Apr 2, 2008, at 6:53 AM, Geert Uytterhoeven wrote: On Tue, 1 Apr 2008, Kumar Gala wrote: On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote: Kumar Gala writes: Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use it in places that before would have caused recursive includes. For example to use phys_addr_t in we would have included which would have possibly included which includes . Wh recursive include. In general this looks fine. I wonder if you should use u64 rather than unsigned long long. Since CONFIG_PHYS_64BIT=n on 64-bit machines (which is itself somewhat counterintuitive) we will actually use unsigned long on 64-bit machines, so it matters less than I originally thought, but it would be worth explaining that in a comment and/or the commit message. We could change it to be: /* Physical address used by some IO functions */ #if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT) typedef u64 phys_addr_t; #else typedef u32 phys_addr_t; #endif This seems a bit more self documenting which is always nice (and I can add a comment in the commit message about CONFIG_PHYS_64BIT only making sense on ppc32). If it's counterintuitive that CONFIG_PHYS_64BIT=n on 64-bit machines, why not set it to =y in Kconfig? Its not that it =n, its that its not available. The Kconfig looks like: config PHYS_64BIT bool 'Large physical address support' if E500 depends on 44x || E500 select RESOURCES_64BIT default y if 44x We could set it to y on PPC64 as there is no harm there, but Paul would need to say he wants that done. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/4] [POWERPC] Initialize paca->current earlier
On Wed, 02 Apr 2008 18:52:09 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > This changes it so that all PACAs are statically initialized with > __current pointing to the init task. For non-0 CPUs, this is fixed > up before use. You might want to see how this impacts on Tony Breed's 1024 way patches. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpHGEIl084kB.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] [POWERPC] lockdep stacktrace support
On Wed, 02 Apr 2008 18:52:10 +1100 Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > +++ linux-work/arch/powerpc/kernel/stacktrace.c 2008-04-02 > 16:46:07.0 +1100 > @@ -0,0 +1,52 @@ > + Copyight and license statement needed. > +#include > +#include You should include for STACK_FRAME_OVERHEAD and struct pt_regs. > +#ifdef CONFIG_PPC64 > +#define MIN_STACK_FRAME 112 /* same as STACK_FRAME_OVERHEAD, in fact */ So use STACK_FRAME_OVERHEAD? > +#define FRAME_LR_SAVE 2 > +#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD + 288) Its used here already ... > +#define REGS_MARKER 0x7265677368657265ul Maybe we need to put REGS_MARKER into a header file as it already appears in two assembly files and two C files. -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpvIHwYN4pQ0.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Move phys_addr_t definition into asm/types.h
On Tue, 1 Apr 2008, Kumar Gala wrote: > On Mar 31, 2008, at 10:42 PM, Paul Mackerras wrote: > >Kumar Gala writes: > > >Moved phys_addr_t out of mmu-*.h and into asm/types.h so we can use it in > > >places that before would have caused recursive includes. > > > > > >For example to use phys_addr_t in we would have included > > > which would have possibly included which > > >includes . Wh recursive include. > > > >In general this looks fine. I wonder if you should use u64 rather > >than unsigned long long. Since CONFIG_PHYS_64BIT=n on 64-bit machines > >(which is itself somewhat counterintuitive) we will actually use > >unsigned long on 64-bit machines, so it matters less than I originally > >thought, but it would be worth explaining that in a comment and/or the > >commit message. > > We could change it to be: > > /* Physical address used by some IO functions */ > #if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT) > typedef u64 phys_addr_t; > #else > typedef u32 phys_addr_t; > #endif > > This seems a bit more self documenting which is always nice (and I can add a > comment in the commit message about CONFIG_PHYS_64BIT only making sense on > ppc32). If it's counterintuitive that CONFIG_PHYS_64BIT=n on 64-bit machines, why not set it to =y in Kconfig? With kind regards, Geert Uytterhoeven Software Architect Sony Network and Software Technology Center Europe The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium Phone:+32 (0)2 700 8453 Fax: +32 (0)2 700 8622 E-mail: [EMAIL PROTECTED] Internet: http://www.sony-europe.com/ Sony Network and Software Technology Center Europe A division of Sony Service Centre (Europe) N.V. Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium VAT BE 0413.825.160 · RPR Brussels Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Quick patch for ucc_geth, add copybreak and move TX processing to soft IRQ
This is a quick hack to make ucc_geth handle a
ping -f -l 10 gracefully. Without it, the CPU will lockup during the ping flood.
I don't have time ATM to clean it up, but if anyone wants to he is welcome :)
Commenst on the geleral approach is wanted though, why do I need to move TX
processing to soft IRQ to make the system response under heavy load?
Kernel 2.6.23
Jocke
---
drivers/net/ucc_geth.c | 85 +--
1 files changed, 59 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 038ec75..b74b298 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -73,6 +73,11 @@ static struct {
module_param_named(debug, debug.msg_enable, int, 0);
MODULE_PARM_DESC(debug, "Debug verbosity level (0=none, ..., 0x=all)");
+#define COPYBREAK_DEFAULT 256
+static unsigned int copybreak __read_mostly = COPYBREAK_DEFAULT;
+MODULE_PARM_DESC(copybreak,
+ "Maximum size of packet that is copied to a new buffer on receive");
+
static struct ucc_geth_info ugeth_primary_info = {
.uf_info = {
.bd_mem_part = MEM_PART_MURAM,
@@ -3380,14 +3385,12 @@ static int ucc_geth_start_xmit(struct sk_buff *skb,
struct net_device *dev)
#ifdef CONFIG_UGETH_TX_ON_DEMAND
struct ucc_fast_private *uccf;
#endif
- u8 *bd; /* BD pointer */
+ u8 *bd, *bd_ptr;/* BD pointer */
u32 bd_status;
u8 txQ = 0;
ugeth_vdbg("%s: IN", __FUNCTION__);
- spin_lock_irq(&ugeth->lock);
-
ugeth->stats.tx_bytes += skb->len;
/* Start from the next BD that should be filled */
@@ -3401,16 +3404,18 @@ static int ucc_geth_start_xmit(struct sk_buff *skb,
struct net_device *dev)
(ugeth->skb_curtx[txQ] +
1) & TX_RING_MOD_MASK(ugeth->ug_info->bdRingLenTx[txQ]);
- /* set up the buffer descriptor */
- out_be32(&((struct qe_bd *)bd)->buf,
- dma_map_single(NULL, skb->data, skb->len, DMA_TO_DEVICE));
+ bd_ptr = dma_map_single(NULL, skb->data, skb->len, DMA_TO_DEVICE);
/* printk(KERN_DEBUG"skb->data is 0x%x\n",skb->data); */
bd_status = (bd_status & T_W) | T_R | T_I | T_L | skb->len;
+ spin_lock_irq(&ugeth->lock);
+ /* set up the buffer descriptor */
+ out_be32(&((struct qe_bd *)bd)->buf, bd_ptr);
/* set bd status and length */
out_be32((u32 *)bd, bd_status);
+ spin_unlock_irq(&ugeth->lock);
dev->trans_start = jiffies;
@@ -3427,8 +3432,6 @@ static int ucc_geth_start_xmit(struct sk_buff *skb,
struct net_device *dev)
netif_stop_queue(dev);
}
- ugeth->txBd[txQ] = bd;
-
if (ugeth->p_scheduler) {
ugeth->cpucount[txQ]++;
/* Indicate to QE that there are more Tx bds ready for
@@ -3442,7 +3445,7 @@ static int ucc_geth_start_xmit(struct sk_buff *skb,
struct net_device *dev)
uccf = ugeth->uccf;
out_be16(uccf->p_utodr, UCC_FAST_TOD);
#endif
- spin_unlock_irq(&ugeth->lock);
+ ugeth->txBd[txQ] = bd;
return 0;
}
@@ -3454,6 +3457,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8
rxQ, int rx_work_limit
u16 length, howmany = 0;
u32 bd_status;
u8 *bdBuffer;
+ struct sk_buff *new_skb;
ugeth_vdbg("%s: IN", __FUNCTION__);
@@ -3467,6 +3471,7 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth, u8
rxQ, int rx_work_limit
bdBuffer = (u8 *) in_be32(&((struct qe_bd *)bd)->buf);
length = (u16) ((bd_status & BD_LENGTH_MASK) - 4);
skb = ugeth->rx_skbuff[rxQ][ugeth->skb_currx[rxQ]];
+ new_skb = NULL;
/* determine whether buffer is first, last, first and last
(single buffer frame) or middle (not first and not last) */
@@ -3484,6 +3489,21 @@ static int ucc_geth_rx(struct ucc_geth_private *ugeth,
u8 rxQ, int rx_work_limit
} else {
ugeth->stats.rx_packets++;
howmany++;
+ if (length < copybreak) {
+ new_skb =
+ netdev_alloc_skb(ugeth->dev, length +
NET_IP_ALIGN);
+ if (new_skb) {
+ skb_reserve(new_skb, NET_IP_ALIGN);
+ skb_copy_to_linear_data_offset(new_skb,
+
-NET_IP_ALIGN,
+
(skb->data -
+
NET_IP_ALIGN),
+ (length +
+
NET_IP_ALIGN));
+
Re: [PATCH] RTAS - adapt procfs interface
Nathan Lynch writes: > I think this is better... the way these files are used is lame, but > this should preserve the existing behavior. I haven't yet tested > this, can you? Looks OK -- can I have a proper patch description and a signed-off-by line for this please? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'for-2.6.25' branch
Kumar Gala writes: > Paul, any comments on sending this onto linus. I was hoping to avoid > 2.6.25 coming up not support the proper device bindings for DMA and > SATA. I've pulled it and I'll send it on later (or Linus can pull it directly if he wants). There is the iSeries fix from Ben H plus two other patches (one from Bartlomiej Sieka and one from Nathan Lynch) where I'm waiting for proper patch descriptions and/or signed-off-by lines. I was hoping to get those tomorrow and send the lot on to Linus. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] RTAS - adapt procfs interface
On Tuesday 01 April 2008, Nathan Lynch wrote:
> Nathan Lynch wrote:
> >
> > One could argue that the real problem is using the proc_dir_entry's
> > reference count to enforce exclusive open.
>
>
> I think this is better... the way these files are used is lame, but
> this should preserve the existing behavior. I haven't yet tested
> this, can you?
I did and it works for me...
>
>
> diff --git a/arch/powerpc/kernel/rtas_flash.c
> b/arch/powerpc/kernel/rtas_flash.c
> index f227659..00bc308 100644
> --- a/arch/powerpc/kernel/rtas_flash.c
> +++ b/arch/powerpc/kernel/rtas_flash.c
> @@ -139,7 +139,7 @@ struct rtas_validate_flash_t
> unsigned int update_results;/* Update results token */
> };
>
> -static DEFINE_SPINLOCK(flash_file_open_lock);
> +static atomic_t open_count = ATOMIC_INIT(0);
> static struct proc_dir_entry *firmware_flash_pde;
> static struct proc_dir_entry *firmware_update_pde;
> static struct proc_dir_entry *validate_pde;
> @@ -216,7 +216,7 @@ static int rtas_flash_release(struct inode *inode, struct
> file *file)
> uf->flist = NULL;
> }
>
> - atomic_dec(&dp->count);
> + atomic_dec(&open_count);
> return 0;
> }
>
> @@ -352,26 +352,17 @@ static ssize_t rtas_flash_write(struct file *file,
> const char __user *buffer,
>
> static int rtas_excl_open(struct inode *inode, struct file *file)
> {
> - struct proc_dir_entry *dp = PDE(inode);
> -
> - /* Enforce exclusive open with use count of PDE */
> - spin_lock(&flash_file_open_lock);
> - if (atomic_read(&dp->count) > 1) {
> - spin_unlock(&flash_file_open_lock);
> + if (atomic_inc_return(&open_count) > 1) {
> + atomic_dec(&open_count);
> return -EBUSY;
> }
>
> - atomic_inc(&dp->count);
> - spin_unlock(&flash_file_open_lock);
> -
> return 0;
> }
>
> static int rtas_excl_release(struct inode *inode, struct file *file)
> {
> - struct proc_dir_entry *dp = PDE(inode);
> -
> - atomic_dec(&dp->count);
> + atomic_dec(&open_count);
>
> return 0;
> }
> @@ -580,7 +571,7 @@ static int validate_flash_release(struct inode *inode,
> struct file *file)
> }
>
> /* The matching atomic_inc was in rtas_excl_open() */
> - atomic_dec(&dp->count);
> + atomic_dec(&open_count);
>
> return 0;
> }
>
Gruß,
Jens
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] RTAS - adapt procfs interface
On Tuesday 01 April 2008, Nathan Lynch wrote: > Jens Osterkamp wrote: > > > > Handling of the proc_dir_entry->count has being changed in 2.6.24-rc5. > > Do you know which commit caused the change? Yes, we bisected it to the following commit : commit 5a622f2d0f86b316b07b55a4866ecb5518dd1cf7 Author: Alexey Dobriyan <[EMAIL PROTECTED]> Date: Tue Dec 4 23:45:28 2007 -0800 proc: fix proc_dir_entry refcounting Creating PDEs with refcount 0 and "deleted" flag has problems (see below). Switch to usual scheme: * PDE is created with refcount 1 * every de_get does +1 * every de_put() and remove_proc_entry() do -1 * once refcount reaches 0, PDE is freed. This elegantly fixes at least two following races (both observed) without introducing new locks, without abusing old locks, without spreading lock_kernel(): [...] Gruß, Jens IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] [POWERPC] lockdep support for ppc64
On Wed, 2008-04-02 at 11:50 +0200, Johannes Berg wrote: > > This serie of patches adds lockdep support for 64 bits > > powerpc. Dale's patch for 32 bits still need me to review > > and test it which I'll try to do asap. > > Yay. I'll give it another try later today. Haven't tested this version on G5 yet btw :-) (though I had a previous one working internally). I tested on POWER6 pSeries and old iSeries (spent a while fixing the later). I'll run more tests tomorrow hopefully and add a few patch fixing some of the issues that lockdep already starting showing. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/11] cell: generalize io-workarounds code
On Wed, 2008-04-02 at 19:52 +0900, Ishizaki Kou wrote: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > As you said, if read/write/in/out functions take device parameter, > > > taking I/O function pointers into the dev_archdata structure should be > > > the best solution. But they don't take device parameter, and they must > > > search I/O function pointers with address parameter. I think it's > > > better they search pointers from bus bridges, because access mothod > > > for a device on its parent bus bridge, not device itself. > > > > What I meant is that if the pointers are in dev_archdata, we can > > populate with a different set of pointers for PCI vs. PCI-E. > > I'm afraid I misunderstood your opinion. > > My concern is how to find a device by address when I/O function > pointers are in dev_archdata. > > You must select the appropriate device with an address, because all > I/O functions, read/write/in/out don't have device parameter. If the > address is in MMIO space, you can set 'token' to the address to select > the device. But in IO space, you can't set 'token' to the I/O port > address. Thefore you must scan all devices to select the device. > > Do you have any better solution? No, you are right. The EEH code has a way to go back to the device but it has significant overhead. Let's stick to your current approach. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/11] cell: generalize io-workarounds code
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > As you said, if read/write/in/out functions take device parameter, > > taking I/O function pointers into the dev_archdata structure should be > > the best solution. But they don't take device parameter, and they must > > search I/O function pointers with address parameter. I think it's > > better they search pointers from bus bridges, because access mothod > > for a device on its parent bus bridge, not device itself. > > What I meant is that if the pointers are in dev_archdata, we can > populate with a different set of pointers for PCI vs. PCI-E. I'm afraid I misunderstood your opinion. My concern is how to find a device by address when I/O function pointers are in dev_archdata. You must select the appropriate device with an address, because all I/O functions, read/write/in/out don't have device parameter. If the address is in MMIO space, you can set 'token' to the address to select the device. But in IO space, you can't set 'token' to the I/O port address. Thefore you must scan all devices to select the device. Do you have any better solution? Best regards, Kou Ishizaki ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/4] [POWERPC] lockdep support for ppc64
> This serie of patches adds lockdep support for 64 bits > powerpc. Dale's patch for 32 bits still need me to review > and test it which I'll try to do asap. Yay. I'll give it another try later today. Thanks, johannes signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] [POWERPC] irqtrace support to 64-bit powerpc
This adds the low level irq tracing hooks to the powerpc architecture
needed to enable full lockdep functionality
Partly based on Johannes Berg's initial version, removing the asm
trampoline that isn't needed (thus improving perfs) and all sorts
of bits and pieces, reworking most of the assembly, etc...
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig|9 +++
arch/powerpc/kernel/entry_64.S | 27 +-
arch/powerpc/kernel/head_64.S | 47 +++-
arch/powerpc/kernel/irq.c |3 +-
arch/powerpc/kernel/ppc_ksyms.c |4 ---
arch/powerpc/kernel/setup_64.c |4 +++
include/asm-powerpc/exception.h |6 ++---
include/asm-powerpc/hw_irq.h| 13 +--
include/asm-powerpc/irqflags.h | 37 +--
include/asm-powerpc/rwsem.h | 35 ++---
include/asm-powerpc/spinlock.h |1
11 files changed, 134 insertions(+), 52 deletions(-)
--- linux-work.orig/arch/powerpc/Kconfig2008-04-02 18:30:18.0
+1100
+++ linux-work/arch/powerpc/Kconfig 2008-04-02 18:30:21.0 +1100
@@ -53,6 +53,15 @@ config STACKTRACE_SUPPORT
bool
default y
+config TRACE_IRQFLAGS_SUPPORT
+ bool
+ depends on PPC64
+ default y
+
+config LOCKDEP_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
Index: linux-work/arch/powerpc/kernel/irq.c
===
--- linux-work.orig/arch/powerpc/kernel/irq.c 2008-04-02 18:30:20.0
+1100
+++ linux-work/arch/powerpc/kernel/irq.c2008-04-02 18:30:21.0
+1100
@@ -114,7 +114,7 @@ static inline void set_soft_enabled(unsi
: : "r" (enable), "i" (offsetof(struct paca_struct, soft_enabled)));
}
-void local_irq_restore(unsigned long en)
+void raw_local_irq_restore(unsigned long en)
{
/*
* get_paca()->soft_enabled = en;
@@ -174,6 +174,7 @@ void local_irq_restore(unsigned long en)
__hard_irq_enable();
}
+EXPORT_SYMBOL(raw_local_irq_restore);
#endif /* CONFIG_PPC64 */
int show_interrupts(struct seq_file *p, void *v)
Index: linux-work/arch/powerpc/kernel/ppc_ksyms.c
===
--- linux-work.orig/arch/powerpc/kernel/ppc_ksyms.c 2008-04-02
18:11:56.0 +1100
+++ linux-work/arch/powerpc/kernel/ppc_ksyms.c 2008-04-02 18:30:21.0
+1100
@@ -45,10 +45,6 @@
#include
#include
-#ifdef CONFIG_PPC64
-EXPORT_SYMBOL(local_irq_restore);
-#endif
-
#ifdef CONFIG_PPC32
extern void transfer_to_handler(void);
extern void do_IRQ(struct pt_regs *regs);
Index: linux-work/include/asm-powerpc/hw_irq.h
===
--- linux-work.orig/include/asm-powerpc/hw_irq.h2008-04-02
18:11:56.0 +1100
+++ linux-work/include/asm-powerpc/hw_irq.h 2008-04-02 18:30:21.0
+1100
@@ -27,7 +27,7 @@ static inline unsigned long local_get_fl
return flags;
}
-static inline unsigned long local_irq_disable(void)
+static inline unsigned long raw_local_irq_disable(void)
{
unsigned long flags, zero;
@@ -39,14 +39,15 @@ static inline unsigned long local_irq_di
return flags;
}
-extern void local_irq_restore(unsigned long);
+extern void raw_local_irq_restore(unsigned long);
extern void iseries_handle_interrupts(void);
-#define local_irq_enable() local_irq_restore(1)
-#define local_save_flags(flags)((flags) = local_get_flags())
-#define local_irq_save(flags) ((flags) = local_irq_disable())
+#define raw_local_irq_enable() raw_local_irq_restore(1)
+#define raw_local_save_flags(flags)((flags) = local_get_flags())
+#define raw_local_irq_save(flags) ((flags) = raw_local_irq_disable())
-#define irqs_disabled()(local_get_flags() == 0)
+#define raw_irqs_disabled()(local_get_flags() == 0)
+#define raw_irqs_disabled_flags(flags) ((flags) == 0)
#define __hard_irq_enable()__mtmsrd(mfmsr() | MSR_EE, 1)
#define __hard_irq_disable() __mtmsrd(mfmsr() & ~MSR_EE, 1)
Index: linux-work/include/asm-powerpc/irqflags.h
===
--- linux-work.orig/include/asm-powerpc/irqflags.h 2008-04-02
18:11:56.0 +1100
+++ linux-work/include/asm-powerpc/irqflags.h 2008-04-02 18:30:21.0
+1100
@@ -2,30 +2,43 @@
* include/asm-powerpc/irqflags.h
*
* IRQ flags handling
- *
- * This file gets included from lowlevel asm headers too, to provide
- * wrapped versions of the local_irq_*() APIs, based on the
- * raw_local_irq_*() macros from the lowlevel headers.
*/
#ifndef _ASM_IRQFLAGS_H
#define _ASM_IRQFLAGS_H
+#ifndef __ASSEMBLY__
/*
* Get definitions for raw_local_save_flags(x), etc.
*/
#include
+#else
+#ifdef CONFIG_TRACE_IRQFLAGS
/*
- * Do the
[PATCH 3/4] [POWERPC] Fixup softirq preempt count
This fixes the handling of the preempt count when switching interrupt stacks so that HW interrupt properly get the softirq mask copied over from the previous stack. It also initializes the softirq stack preempt_count to 0 instead of SOFTIRQ_OFFSET, like x86, as __do_softirq() does the increment, and we hit some lockdep checks if we have it twice. That means we do run for a little while off the softirq stack with the preempt-count set to 0, which could be deadly if we try to take a softirq at that point, however we do so with interrupts disabled, so I think we are ok. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- arch/powerpc/kernel/irq.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) --- linux-work.orig/arch/powerpc/kernel/irq.c 2008-04-02 16:48:58.0 +1100 +++ linux-work/arch/powerpc/kernel/irq.c2008-04-02 16:49:36.0 +1100 @@ -310,8 +310,21 @@ void do_IRQ(struct pt_regs *regs) handler = &__do_IRQ; irqtp->task = curtp->task; irqtp->flags = 0; + + /* Copy the softirq bits in preempt_count so that the +* softirq checks work in the hardirq context. +*/ + irqtp->preempt_count = + (irqtp->preempt_count & ~SOFTIRQ_MASK) | + (curtp->preempt_count & SOFTIRQ_MASK); + call_handle_irq(irq, desc, irqtp, handler); irqtp->task = NULL; + + + /* Set any flag that may have been set on the +* alternate stack +*/ if (irqtp->flags) set_bits(irqtp->flags, &curtp->flags); } else @@ -357,7 +370,7 @@ void irq_ctx_init(void) memset((void *)softirq_ctx[i], 0, THREAD_SIZE); tp = softirq_ctx[i]; tp->cpu = i; - tp->preempt_count = SOFTIRQ_OFFSET; + tp->preempt_count = 0; memset((void *)hardirq_ctx[i], 0, THREAD_SIZE); tp = hardirq_ctx[i]; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] [POWERPC] lockdep stacktrace support
From: Christoph Hellwig <[EMAIL PROTECTED]>
I recently tried to work on lockdep for powerpc. I have preliminary
version of the stacktrace code, but had to give up on trace irqflags
support because I'm not that knowledgeable on lowlevel ppc details.
Maybe someone more faimilar with the code wants to give it another try?
My stacktrace code is below:
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig |4 +++
arch/powerpc/kernel/Makefile |1
arch/powerpc/kernel/stacktrace.c | 52 +++
3 files changed, 57 insertions(+)
--- linux-work.orig/arch/powerpc/Kconfig2008-04-02 15:46:07.0
+1100
+++ linux-work/arch/powerpc/Kconfig 2008-04-02 16:47:46.0 +1100
@@ -49,6 +49,10 @@ config IRQ_PER_CPU
bool
default y
+config STACKTRACE_SUPPORT
+ bool
+ default y
+
config RWSEM_GENERIC_SPINLOCK
bool
Index: linux-work/arch/powerpc/kernel/Makefile
===
--- linux-work.orig/arch/powerpc/kernel/Makefile2008-04-02
15:46:07.0 +1100
+++ linux-work/arch/powerpc/kernel/Makefile 2008-04-02 16:46:07.0
+1100
@@ -67,6 +67,7 @@ obj-$(CONFIG_BOOTX_TEXT) += btext.o
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_KPROBES) += kprobes.o
obj-$(CONFIG_PPC_UDBG_16550) += legacy_serial.o udbg_16550.o
+obj-$(CONFIG_STACKTRACE) += stacktrace.o
pci64-$(CONFIG_PPC64) += pci_dn.o isa-bridge.o
obj-$(CONFIG_PCI) += pci_$(CONFIG_WORD_SIZE).o $(pci64-y) \
Index: linux-work/arch/powerpc/kernel/stacktrace.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-work/arch/powerpc/kernel/stacktrace.c 2008-04-02 16:46:07.0
+1100
@@ -0,0 +1,52 @@
+
+#include
+#include
+
+
+#ifdef CONFIG_PPC64
+#define MIN_STACK_FRAME 112 /* same as STACK_FRAME_OVERHEAD, in fact */
+#define FRAME_LR_SAVE 2
+#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD + 288)
+#define REGS_MARKER 0x7265677368657265ul
+#define FRAME_MARKER12
+#else
+#define MIN_STACK_FRAME 16
+#define FRAME_LR_SAVE 1
+#define INT_FRAME_SIZE (sizeof(struct pt_regs) + STACK_FRAME_OVERHEAD)
+#define REGS_MARKER 0x72656773ul
+#define FRAME_MARKER2
+#endif
+
+
+/*
+ * Save stack-backtrace addresses into a stack_trace buffer.
+ * If all_contexts is set, all contexts (hardirq, softirq and process)
+ * are saved. If not set then only the current context is saved.
+ */
+void save_stack_trace(struct stack_trace *trace)
+{
+ unsigned long sp;
+
+ asm("mr %0,1" : "=r" (sp));
+
+ for (;;) {
+ unsigned long *stack = (unsigned long *) sp;
+ unsigned long newsp, ip;
+
+ if (!validate_sp(sp, current, MIN_STACK_FRAME))
+ return;
+
+ newsp = stack[0];
+ ip = stack[FRAME_LR_SAVE];
+
+ if (!trace->skip)
+ trace->entries[trace->nr_entries++] = ip;
+ else
+ trace->skip--;
+
+ if (trace->nr_entries >= trace->max_entries)
+ return;
+
+ sp = newsp;
+ }
+}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/4] [POWERPC] Initialize paca->current earlier
Currently, we initialize the "current" pointer in the PACA (which is used by the "current" macro in the kernel) before calling setup_system(). That means that early_setup() is called with current still "NULL" which is -not- a good idea. It happens to work so far but breaks with lockdep when early code calls printk. This changes it so that all PACAs are statically initialized with __current pointing to the init task. For non-0 CPUs, this is fixed up before use. Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> --- arch/powerpc/kernel/head_64.S |4 arch/powerpc/kernel/paca.c|3 ++- 2 files changed, 2 insertions(+), 5 deletions(-) --- linux-work.orig/arch/powerpc/kernel/head_64.S 2008-04-02 18:20:53.0 +1100 +++ linux-work/arch/powerpc/kernel/head_64.S2008-04-02 18:24:45.0 +1100 @@ -1505,10 +1505,6 @@ _INIT_GLOBAL(start_here_common) li r0,0 stdur0,-STACK_FRAME_OVERHEAD(r1) - /* ptr to current */ - LOAD_REG_IMMEDIATE(r4, init_task) - std r4,PACACURRENT(r13) - /* Load the TOC */ ld r2,PACATOC(r13) std r1,PACAKSAVE(r13) Index: linux-work/arch/powerpc/kernel/paca.c === --- linux-work.orig/arch/powerpc/kernel/paca.c 2008-04-02 18:28:07.0 +1100 +++ linux-work/arch/powerpc/kernel/paca.c 2008-04-02 18:28:22.0 +1100 @@ -72,7 +72,8 @@ struct slb_shadow slb_shadow[] __cacheli .paca_index = (number), /* Paca Index */\ .kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL, \ .hw_cpu_id = 0x,\ - .slb_shadow_ptr = &slb_shadow[number], + .slb_shadow_ptr = &slb_shadow[number], \ + .__current = &init_task, #ifdef CONFIG_PPC_ISERIES #define PACA_INIT_ISERIES(number) \ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/4] [POWERPC] lockdep support for ppc64
[Not to merge just yet ... almost] This serie of patches adds lockdep support for 64 bits powerpc. Dale's patch for 32 bits still need me to review and test it which I'll try to do asap. It needs the iSeries hardirq enable fix that I posted earlier (which is probably 2.6.25 material). Note that we can already see potential problems exposed by it. So far on my list: - something wrong with iseries veth. Haven't got to figure out what yet, could be a false positive - possible deadlock with the device-tree rwlock. The one that I caught with lockdep here is pSeries rtas_set_rtc_time() calls rtas_token() from softirq, which does on of_find_property(), which takes the read lock. Other things can call prom_add_propety() which can take the write lock, while softirqs are enabled -> boom. Maybe we should forbid OF device-tree access from IRQs and thus things that need to use rtas_token() will have to cache the token. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
On Wed, 2008-04-02 at 12:38 +0530, Kamalesh Babulal wrote:
> Andrew Morton wrote:
> > On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi Andrew,
> >>
> >> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
> >>
> >> [0.00] [ cut here ]
> >> [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
> >> [0.00] Oops: Exception in kernel mode, sig: 5 [#1]
> >> [0.00] SMP NR_CPUS=32 NUMA PowerMac
> >> [0.00] Modules linked in:
> >> [0.00] NIP: c03d1dcc LR: c03d1dc4 CTR:
> >> c002b6ac
> >> [0.00] REGS: c049b960 TRAP: 0700 Not tainted
> >> (2.6.25-rc8-mm1-autokern1)
> >> [0.00] MSR: 90021032 CR: 4488 XER:
> >> 2000
> >> [0.00] TASK = c03f9c90[0] 'swapper' THREAD:
> >> c0498000 CPU: 0
> >> [0.00] GPR00: c03d1dc4 c049bbe0 c04989d0
> >> 0001
> >> [0.00] GPR04: d59aca40f000 0b00 0010
> >>
> >> [0.00] GPR08: 0004 0001 c0027e520800
> >> c04bf0f0
> >> [0.00] GPR12: c04bf020 c03fa900
> >>
> >> [0.00] GPR16:
> >>
> >> [0.00] GPR20:
> >> 4140
> >> [0.00] GPR24: 017d64b0 c03d6250
> >> c0504000
> >> [0.00] GPR28: cf1f8000 0100
> >> cf00
> >> [0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4
> >> [0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4
> >> [0.00] Call Trace:
> >> [0.00] [c049bbe0] [c03d1dc4]
> >> .vmemmap_populate+0xb0/0xf4 (unreliable)
> >> [0.00] [c049bc70] [c03d2ee8]
> >> .sparse_mem_map_populate+0x38/0x60
> >> [0.00] [c049bd00] [c03c242c]
> >> .sparse_early_mem_map_alloc+0x54/0x94
> >> [0.00] [c049bd90] [c03c250c]
> >> .sparse_init+0xa0/0x20c
> >> [0.00] [c049be50] [c03ab7d0]
> >> .setup_arch+0x1ac/0x218
> >> [0.00] [c049bee0] [c03a36ac]
> >> .start_kernel+0xe0/0x3fc
> >> [0.00] [c049bf90] [c0008594]
> >> .start_here_common+0x54/0xc0
> >> [0.00] Instruction dump:
> >> [0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c e92289c8
> >> e96289c0 e9090002
> >> [0.00] e8eb0002 4bc575cd 6000 78630fe0 <0b03> 7214
> >> 7fbfe840 7fe3fb78
> >> [0.00] ---[ end trace 31fd0ba7d8756001 ]---
> >> [0.00] Kernel panic - not syncing: Attempted to kill the idle task!
> >>
> >
> > int __meminit vmemmap_populate(struct page *start_page,
> > unsigned long nr_pages, int node)
> > {
> > unsigned long mode_rw;
> > unsigned long start = (unsigned long)start_page;
> > unsigned long end = (unsigned long)(start_page + nr_pages);
> > unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
> >
> > mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
> >
> > /* Align to the page size of the linear mapping. */
> > start = _ALIGN_DOWN(start, page_size);
> >
> > for (; start < end; start += page_size) {
> > int mapped;
> > void *p;
> >
> > if (vmemmap_populated(start, page_size))
> > continue;
> >
> > p = vmemmap_alloc_block(page_size, node);
> > if (!p)
> > return -ENOMEM;
> >
> > pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> > start, p, __pa(p));
> >
> > mapped = htab_bolt_mapping(start, start + page_size,
> > __pa(p), mode_rw, mmu_linear_psize,
> > mmu_kernel_ssize);
> > => BUG_ON(mapped < 0);
> > }
> >
> > return 0;
> > }
> >
> > Beats me. pseries? Badari has been diddling with the bolted memory code
> > in git-powerpc...
>
> One of the machines is the Power5 and another is PowerMac G5, on which the
> same kernel panic is seen.
Can you enable DEBUG_LOW in arch/powerpc/platforms/pseries/lpar.c, that
should show what's happening in hpte_insert().
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing lis
Re: [BUG] 2.6.25-rc8-mm1 kernel panic while bootup on powerpc
Andrew Morton wrote:
> On Wed, 02 Apr 2008 11:55:36 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
>> Hi Andrew,
>>
>> The 2.6.25-rc8-mm1 kernel panic's while bootup on the power machine(s).
>>
>> [0.00] [ cut here ]
>> [0.00] kernel BUG at arch/powerpc/mm/init_64.c:240!
>> [0.00] Oops: Exception in kernel mode, sig: 5 [#1]
>> [0.00] SMP NR_CPUS=32 NUMA PowerMac
>> [0.00] Modules linked in:
>> [0.00] NIP: c03d1dcc LR: c03d1dc4 CTR:
>> c002b6ac
>> [0.00] REGS: c049b960 TRAP: 0700 Not tainted
>> (2.6.25-rc8-mm1-autokern1)
>> [0.00] MSR: 90021032 CR: 4488 XER: 2000
>> [0.00] TASK = c03f9c90[0] 'swapper' THREAD: c0498000
>> CPU: 0
>> [0.00] GPR00: c03d1dc4 c049bbe0 c04989d0
>> 0001
>> [0.00] GPR04: d59aca40f000 0b00 0010
>>
>> [0.00] GPR08: 0004 0001 c0027e520800
>> c04bf0f0
>> [0.00] GPR12: c04bf020 c03fa900
>>
>> [0.00] GPR16:
>>
>> [0.00] GPR20:
>> 4140
>> [0.00] GPR24: 017d64b0 c03d6250
>> c0504000
>> [0.00] GPR28: cf1f8000 0100
>> cf00
>> [0.00] NIP [c03d1dcc] .vmemmap_populate+0xb8/0xf4
>> [0.00] LR [c03d1dc4] .vmemmap_populate+0xb0/0xf4
>> [0.00] Call Trace:
>> [0.00] [c049bbe0] [c03d1dc4]
>> .vmemmap_populate+0xb0/0xf4 (unreliable)
>> [0.00] [c049bc70] [c03d2ee8]
>> .sparse_mem_map_populate+0x38/0x60
>> [0.00] [c049bd00] [c03c242c]
>> .sparse_early_mem_map_alloc+0x54/0x94
>> [0.00] [c049bd90] [c03c250c] .sparse_init+0xa0/0x20c
>> [0.00] [c049be50] [c03ab7d0] .setup_arch+0x1ac/0x218
>> [0.00] [c049bee0] [c03a36ac] .start_kernel+0xe0/0x3fc
>> [0.00] [c049bf90] [c0008594]
>> .start_here_common+0x54/0xc0
>> [0.00] Instruction dump:
>> [0.00] 7fe3fb78 7ca02a14 4082000c 3860fff4 483c e92289c8
>> e96289c0 e9090002
>> [0.00] e8eb0002 4bc575cd 6000 78630fe0 <0b03> 7214
>> 7fbfe840 7fe3fb78
>> [0.00] ---[ end trace 31fd0ba7d8756001 ]---
>> [0.00] Kernel panic - not syncing: Attempted to kill the idle task!
>>
>
> int __meminit vmemmap_populate(struct page *start_page,
> unsigned long nr_pages, int node)
> {
> unsigned long mode_rw;
> unsigned long start = (unsigned long)start_page;
> unsigned long end = (unsigned long)(start_page + nr_pages);
> unsigned long page_size = 1 << mmu_psize_defs[mmu_linear_psize].shift;
>
> mode_rw = _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX;
>
> /* Align to the page size of the linear mapping. */
> start = _ALIGN_DOWN(start, page_size);
>
> for (; start < end; start += page_size) {
> int mapped;
> void *p;
>
> if (vmemmap_populated(start, page_size))
> continue;
>
> p = vmemmap_alloc_block(page_size, node);
> if (!p)
> return -ENOMEM;
>
> pr_debug("vmemmap %08lx allocated at %p, physical %08lx.\n",
> start, p, __pa(p));
>
> mapped = htab_bolt_mapping(start, start + page_size,
> __pa(p), mode_rw, mmu_linear_psize,
> mmu_kernel_ssize);
> =>BUG_ON(mapped < 0);
> }
>
> return 0;
> }
>
> Beats me. pseries? Badari has been diddling with the bolted memory code
> in git-powerpc...
One of the machines is the Power5 and another is PowerMac G5, on which the
same kernel panic is seen.
--
Thanks & Regards,
Kamalesh Babulal,
Linux Technology Center,
IBM, ISTL.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
