* Re: which driver for uartlite with 2.6.17?
From: David Bolcsfoldi @ 2006-10-13 16:47 UTC (permalink / raw)
To: Robert Corley; +Cc: linux linuxppc-embedded
In-Reply-To: <20061013155908.4944.qmail@web56302.mail.re3.yahoo.com>
Hi :-)
Good question. Well I was unaware of the fact that there were other
uartlite drivers so you should take mine off that list. Peter's driver
is slated for inclusion in the mainline and I am currently in the
process of adding a few things to it.
For 2.6.17 support you should probably just remove the IRQF_DISABLED
flag and change IRQF_SAMPLE_RANDOM to SA_SAMPLE_RANDOM in the
request_irq call and it should work. I am unaware of any other
important differences between the two releases affecting this driver.
Cheers,
David
On 10/13/06, Robert Corley <rcorley@aegis-inc.net> wrote:
> All,
>
> Based on what was posted recently, it appears that there is more than one uartlite driver
> floating about.
>
> Can someone please inform me of which driver works for which kernel?
>
> Here is what I see
>
> D. Lynch 2.6.15 polled, (Pico E12 board specific?)
> P. Korsgaard 2.6.18 interrupt driven, official lanana.org nodes
> D. Bolcsfoldi 2.6.18 interrupt driven
>
> patch locations:
> D. Lynch http://ozlabs.org/pipermail/linuxppc-embedded/2006-January/021592.html
> P. Korsgaard http://lkml.org/lkml/2006/9/13/71
> D. Bolcsfoldi http://ozlabs.org/pipermail/linuxppc-embedded/2006-October/024697.html
>
> Comments?
>
> And, lastly, I need a driver for 2.6.17. Can someone point me in the right direction?
> I have tried Peter's driver but it fails to compile, showing this:
>
> CC drivers/serial/serial_core.o
> CC drivers/serial/uartlite.o
> drivers/serial/uartlite.c: In function `ulite_startup':
> drivers/serial/uartlite.c:199: error: `IRQF_DISABLED' undeclared (first use in this function)
> drivers/serial/uartlite.c:199: error: (Each undeclared identifier is reported only once
> drivers/serial/uartlite.c:199: error: for each function it appears in.)
> drivers/serial/uartlite.c:199: error: `IRQF_SAMPLE_RANDOM' undeclared (first use in this function)
> make[2]: *** [drivers/serial/uartlite.o] Error 1
> make[1]: *** [drivers/serial] Error 2
> make: *** [drivers] Error 2
>
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Olof Johansson @ 2006-10-13 16:54 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160726663.4792.222.camel@localhost.localdomain>
On Fri, 13 Oct 2006 18:04:22 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> There are currently two versions of the functions for applying the
> feature fixups, one for CPU features and one for firmware features. In
> addition, they are both in assembly and with separate implementations
> for 32 and 64 bits. identify_cpu() is also implemented in assembly and
> separately for 32 and 64 bits.
>
> This patch replaces them with a pair of C functions. The call sites are
> slightly moved on ppc64 as well to be called from C instead of from
> assembly, though it's a very small change, and thus shouldn't cause any
> problem.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
>
> Index: linux-cell/arch/powerpc/kernel/head_64.S
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/head_64.S 2006-10-13 16:04:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/head_64.S 2006-10-13 16:43:05.000000000 +1000
> @@ -1580,11 +1580,6 @@ _STATIC(__start_initialization_iSeries)
> li r0,0
> stdu r0,-STACK_FRAME_OVERHEAD(r1)
>
> - LOAD_REG_IMMEDIATE(r3,cpu_specs)
> - LOAD_REG_IMMEDIATE(r4,cur_cpu_spec)
> - li r5,0
> - bl .identify_cpu
> -
> LOAD_REG_IMMEDIATE(r2,__toc_start)
> addi r2,r2,0x4000
> addi r2,r2,0x4000
> @@ -1964,13 +1959,6 @@ _STATIC(start_here_multiplatform)
> addi r2,r2,0x4000
> add r2,r2,r26
>
> - LOAD_REG_IMMEDIATE(r3, cpu_specs)
> - add r3,r3,r26
> - LOAD_REG_IMMEDIATE(r4,cur_cpu_spec)
> - add r4,r4,r26
> - mr r5,r26
> - bl .identify_cpu
> -
> /* Do very early kernel initializations, including initial hash table,
> * stab and slb setup before we turn on relocation. */
>
> @@ -2000,13 +1988,6 @@ _STATIC(start_here_common)
> li r0,0
> stdu r0,-STACK_FRAME_OVERHEAD(r1)
>
> - /* Apply the CPUs-specific fixups (nop out sections not relevant
> - * to this CPU
> - */
> - li r3,0
> - bl .do_cpu_ftr_fixups
> - bl .do_fw_ftr_fixups
> -
> /* ptr to current */
> LOAD_REG_IMMEDIATE(r4, init_task)
> std r4,PACACURRENT(r13)
> Index: linux-cell/arch/powerpc/kernel/misc_64.S
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/misc_64.S 2006-10-13 16:04:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/misc_64.S 2006-10-13 16:40:14.000000000 +1000
> @@ -246,130 +246,6 @@ _GLOBAL(__flush_dcache_icache)
> isync
> blr
>
> -/*
> - * identify_cpu and calls setup_cpu
> - * In: r3 = base of the cpu_specs array
> - * r4 = address of cur_cpu_spec
> - * r5 = relocation offset
> - */
> -_GLOBAL(identify_cpu)
> - mfpvr r7
> -1:
> - lwz r8,CPU_SPEC_PVR_MASK(r3)
> - and r8,r8,r7
> - lwz r9,CPU_SPEC_PVR_VALUE(r3)
> - cmplw 0,r9,r8
> - beq 1f
> - addi r3,r3,CPU_SPEC_ENTRY_SIZE
> - b 1b
> -1:
> - sub r0,r3,r5
> - std r0,0(r4)
> - ld r4,CPU_SPEC_SETUP(r3)
> - cmpdi 0,r4,0
> - add r4,r4,r5
> - beqlr
> - ld r4,0(r4)
> - add r4,r4,r5
> - mtctr r4
> - /* Calling convention for cpu setup is r3=offset, r4=cur_cpu_spec */
> - mr r4,r3
> - mr r3,r5
> - bctr
> -
> -/*
> - * do_cpu_ftr_fixups - goes through the list of CPU feature fixups
> - * and writes nop's over sections of code that don't apply for this cpu.
> - * r3 = data offset (not changed)
> - */
> -_GLOBAL(do_cpu_ftr_fixups)
> - /* Get CPU 0 features */
> - LOAD_REG_IMMEDIATE(r6,cur_cpu_spec)
> - sub r6,r6,r3
> - ld r4,0(r6)
> - sub r4,r4,r3
> - ld r4,CPU_SPEC_FEATURES(r4)
> - /* Get the fixup table */
> - LOAD_REG_IMMEDIATE(r6,__start___ftr_fixup)
> - sub r6,r6,r3
> - LOAD_REG_IMMEDIATE(r7,__stop___ftr_fixup)
> - sub r7,r7,r3
> - /* Do the fixup */
> -1: cmpld r6,r7
> - bgelr
> - addi r6,r6,32
> - ld r8,-32(r6) /* mask */
> - and r8,r8,r4
> - ld r9,-24(r6) /* value */
> - cmpld r8,r9
> - beq 1b
> - ld r8,-16(r6) /* section begin */
> - ld r9,-8(r6) /* section end */
> - subf. r9,r8,r9
> - beq 1b
> - /* write nops over the section of code */
> - /* todo: if large section, add a branch at the start of it */
> - srwi r9,r9,2
> - mtctr r9
> - sub r8,r8,r3
> - lis r0,0x60000000@h /* nop */
> -3: stw r0,0(r8)
> - andi. r10,r4,CPU_FTR_SPLIT_ID_CACHE@l
> - beq 2f
> - dcbst 0,r8 /* suboptimal, but simpler */
> - sync
> - icbi 0,r8
> -2: addi r8,r8,4
> - bdnz 3b
> - sync /* additional sync needed on g4 */
> - isync
> - b 1b
> -
> -/*
> - * do_fw_ftr_fixups - goes through the list of firmware feature fixups
> - * and writes nop's over sections of code that don't apply for this firmware.
> - * r3 = data offset (not changed)
> - */
> -_GLOBAL(do_fw_ftr_fixups)
> - /* Get firmware features */
> - LOAD_REG_IMMEDIATE(r6,powerpc_firmware_features)
> - sub r6,r6,r3
> - ld r4,0(r6)
> - /* Get the fixup table */
> - LOAD_REG_IMMEDIATE(r6,__start___fw_ftr_fixup)
> - sub r6,r6,r3
> - LOAD_REG_IMMEDIATE(r7,__stop___fw_ftr_fixup)
> - sub r7,r7,r3
> - /* Do the fixup */
> -1: cmpld r6,r7
> - bgelr
> - addi r6,r6,32
> - ld r8,-32(r6) /* mask */
> - and r8,r8,r4
> - ld r9,-24(r6) /* value */
> - cmpld r8,r9
> - beq 1b
> - ld r8,-16(r6) /* section begin */
> - ld r9,-8(r6) /* section end */
> - subf. r9,r8,r9
> - beq 1b
> - /* write nops over the section of code */
> - /* todo: if large section, add a branch at the start of it */
> - srwi r9,r9,2
> - mtctr r9
> - sub r8,r8,r3
> - lis r0,0x60000000@h /* nop */
> -3: stw r0,0(r8)
> -BEGIN_FTR_SECTION
> - dcbst 0,r8 /* suboptimal, but simpler */
> - sync
> - icbi 0,r8
> -END_FTR_SECTION_IFSET(CPU_FTR_SPLIT_ID_CACHE)
> - addi r8,r8,4
> - bdnz 3b
> - sync /* additional sync needed on g4 */
> - isync
> - b 1b
>
> #if defined(CONFIG_PPC_PMAC) || defined(CONFIG_PPC_MAPLE)
> /*
> Index: linux-cell/arch/powerpc/kernel/setup-common.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/setup-common.c 2006-10-13 16:04:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/setup-common.c 2006-10-13 16:39:03.000000000 +1000
> @@ -520,3 +520,39 @@ void __init setup_panic(void)
> {
> atomic_notifier_chain_register(&panic_notifier_list, &ppc_panic_block);
> }
> +
> +void do_feature_fixups(unsigned long offset, unsigned long value,
> + void *fixup_start, void *fixup_end)
> +{
> + struct fixup_entry {
> + unsigned long mask;
> + unsigned long value;
> + unsigned int *start;
> + unsigned int *end;
> + } *fcur, *fend;
> +
> + fcur = fixup_start;
> + fend = fixup_end;
> +
> + for (; fcur < fend; fcur++) {
> + unsigned int *pstart, *pend, *p;
> +
> + if ((value & fcur->mask) == fcur->value)
> + continue;
> +
> + /* These PTRRELOCs will disappear once the new scheme for
> + * modules and vdso is implemented
> + */
> + pstart = PTRRELOC(fcur->start);
> + pend = PTRRELOC(fcur->end);
> +
> + for (p = pstart; p < pend; p++) {
> + *p = 0x60000000u;
> + asm volatile ("dcbst 0, %0" : : "r" (p));
> + }
> + asm volatile ("sync" : : : "memory");
> + for (p = pstart; p < pend; p++)
> + asm volatile ("icbi 0,%0" : : "r" (p));
> + asm volatile ("sync; isync" : : : "memory");
You can advance the pointer with L1_CACHE_BYTES/sizeof(int) per
iteration in the second loop here.
> + }
> +}
> Index: linux-cell/arch/powerpc/kernel/setup.h
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/setup.h 2006-10-13 16:04:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/setup.h 2006-10-13 16:06:24.000000000 +1000
> @@ -1,9 +1,12 @@
> #ifndef _POWERPC_KERNEL_SETUP_H
> #define _POWERPC_KERNEL_SETUP_H
>
> -void check_for_initrd(void);
> -void do_init_bootmem(void);
> -void setup_panic(void);
> +extern void check_for_initrd(void);
> +extern void do_init_bootmem(void);
> +extern void setup_panic(void);
> +extern void do_feature_fixups(unsigned long offset, unsigned long value,
> + void *fixup_start, void *fixup_end);
> +
> extern int do_early_xmon;
>
> #endif /* _POWERPC_KERNEL_SETUP_H */
> Index: linux-cell/arch/powerpc/kernel/setup_32.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/setup_32.c 2006-10-13 16:04:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/setup_32.c 2006-10-13 16:38:21.000000000 +1000
> @@ -90,7 +90,9 @@ int ucache_bsize;
> */
> unsigned long __init early_init(unsigned long dt_ptr)
> {
> + extern unsigned int __start___ftr_fixup, __stop___ftr_fixup;
> unsigned long offset = reloc_offset();
> + struct cpu_spec *spec;
>
> /* First zero the BSS -- use memset_io, some platforms don't have
> * caches on yet */
> @@ -100,8 +102,11 @@ unsigned long __init early_init(unsigned
> * Identify the CPU type and fix up code sections
> * that depend on which cpu we have.
> */
> - identify_cpu(offset, 0);
> - do_cpu_ftr_fixups(offset);
> + spec = identify_cpu(offset);
> +
> + do_feature_fixups(offset, spec->cpu_features,
> + PTRRELOC(&__start___ftr_fixup),
> + PTRRELOC(&__stop___ftr_fixup));
>
> return KERNELBASE + offset;
> }
> Index: linux-cell/arch/powerpc/kernel/setup_64.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/setup_64.c 2006-10-13 16:04:10.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/setup_64.c 2006-10-13 16:42:44.000000000 +1000
> @@ -170,6 +170,9 @@ void __init setup_paca(int cpu)
>
> void __init early_setup(unsigned long dt_ptr)
> {
> + /* Identify CPU type */
> + identify_cpu(0);
> +
> /* Assume we're on cpu 0 for now. Don't write to the paca yet! */
> setup_paca(0);
>
> @@ -346,8 +349,19 @@ static void __init initialize_cache_info
> */
> void __init setup_system(void)
> {
> + extern unsigned int __start___ftr_fixup, __stop___ftr_fixup;
> + extern unsigned int __start___fw_ftr_fixup, __stop___fw_ftr_fixup;
> +
> DBG(" -> setup_system()\n");
>
> + /* Apply the CPUs-specific and firmware specific fixups to kernel
> + * text (nop out sections not relevant to this CPU or this firmware)
> + */
> + do_feature_fixups(0, cur_cpu_spec->cpu_features,
> + &__start___ftr_fixup, &__stop___ftr_fixup);
> + do_feature_fixups(0, powerpc_firmware_features,
> + &__start___fw_ftr_fixup, &__stop___fw_ftr_fixup);
> +
> /*
> * Unflatten the device-tree passed by prom_init or kexec
> */
> Index: linux-cell/arch/powerpc/kernel/cputable.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/cputable.c 2006-10-06 13:47:54.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/cputable.c 2006-10-13 16:47:31.000000000 +1000
> @@ -73,7 +73,7 @@ extern void __restore_cpu_ppc970(void);
> #define PPC_FEATURE_SPE_COMP 0
> #endif
>
> -struct cpu_spec cpu_specs[] = {
> +static struct cpu_spec cpu_specs[] = {
> #ifdef CONFIG_PPC64
> { /* Power3 */
> .pvr_mask = 0xffff0000,
> @@ -1152,3 +1152,25 @@ struct cpu_spec cpu_specs[] = {
> #endif /* !CLASSIC_PPC */
> #endif /* CONFIG_PPC32 */
> };
> +
> +struct cpu_spec *identify_cpu(unsigned long offset)
> +{
> + struct cpu_spec *s = cpu_specs;
> + struct cpu_spec **cur = &cur_cpu_spec;
> + unsigned int pvr = mfspr(SPRN_PVR);
> + int i;
> +
> + s = PTRRELOC(s);
> + cur = PTRRELOC(cur);
> +
> + if (*cur != NULL)
> + return PTRRELOC(*cur);
> +
> + for (i = 0; i < ARRAY_SIZE(cpu_specs); i++,s++)
> + if ((pvr & s->pvr_mask) == s->pvr_value) {
> + *cur = cpu_specs + i;
> + return s;
> + }
> + BUG();
> + return NULL;
> +}
> Index: linux-cell/arch/powerpc/kernel/misc_32.S
> ===================================================================
> --- linux-cell.orig/arch/powerpc/kernel/misc_32.S 2006-10-06 13:47:54.000000000 +1000
> +++ linux-cell/arch/powerpc/kernel/misc_32.S 2006-10-13 16:26:43.000000000 +1000
> @@ -102,80 +102,6 @@ _GLOBAL(reloc_got2)
> blr
>
> /*
> - * identify_cpu,
> - * called with r3 = data offset and r4 = CPU number
> - * doesn't change r3
> - */
> -_GLOBAL(identify_cpu)
> - addis r8,r3,cpu_specs@ha
> - addi r8,r8,cpu_specs@l
> - mfpvr r7
> -1:
> - lwz r5,CPU_SPEC_PVR_MASK(r8)
> - and r5,r5,r7
> - lwz r6,CPU_SPEC_PVR_VALUE(r8)
> - cmplw 0,r6,r5
> - beq 1f
> - addi r8,r8,CPU_SPEC_ENTRY_SIZE
> - b 1b
> -1:
> - addis r6,r3,cur_cpu_spec@ha
> - addi r6,r6,cur_cpu_spec@l
> - sub r8,r8,r3
> - stw r8,0(r6)
> - blr
> -
> -/*
> - * do_cpu_ftr_fixups - goes through the list of CPU feature fixups
> - * and writes nop's over sections of code that don't apply for this cpu.
> - * r3 = data offset (not changed)
> - */
> -_GLOBAL(do_cpu_ftr_fixups)
> - /* Get CPU 0 features */
> - addis r6,r3,cur_cpu_spec@ha
> - addi r6,r6,cur_cpu_spec@l
> - lwz r4,0(r6)
> - add r4,r4,r3
> - lwz r4,CPU_SPEC_FEATURES(r4)
> -
> - /* Get the fixup table */
> - addis r6,r3,__start___ftr_fixup@ha
> - addi r6,r6,__start___ftr_fixup@l
> - addis r7,r3,__stop___ftr_fixup@ha
> - addi r7,r7,__stop___ftr_fixup@l
> -
> - /* Do the fixup */
> -1: cmplw 0,r6,r7
> - bgelr
> - addi r6,r6,16
> - lwz r8,-16(r6) /* mask */
> - and r8,r8,r4
> - lwz r9,-12(r6) /* value */
> - cmplw 0,r8,r9
> - beq 1b
> - lwz r8,-8(r6) /* section begin */
> - lwz r9,-4(r6) /* section end */
> - subf. r9,r8,r9
> - beq 1b
> - /* write nops over the section of code */
> - /* todo: if large section, add a branch at the start of it */
> - srwi r9,r9,2
> - mtctr r9
> - add r8,r8,r3
> - lis r0,0x60000000@h /* nop */
> -3: stw r0,0(r8)
> - andi. r10,r4,CPU_FTR_SPLIT_ID_CACHE@l
> - beq 2f
> - dcbst 0,r8 /* suboptimal, but simpler */
> - sync
> - icbi 0,r8
> -2: addi r8,r8,4
> - bdnz 3b
> - sync /* additional sync needed on g4 */
> - isync
> - b 1b
> -
> -/*
> * call_setup_cpu - call the setup_cpu function for this cpu
> * r3 = data offset, r24 = cpu number
> *
> Index: linux-cell/include/asm-powerpc/cputable.h
> ===================================================================
> --- linux-cell.orig/include/asm-powerpc/cputable.h 2006-10-13 16:00:28.000000000 +1000
> +++ linux-cell/include/asm-powerpc/cputable.h 2006-10-13 16:19:51.000000000 +1000
> @@ -89,8 +89,7 @@ struct cpu_spec {
>
> extern struct cpu_spec *cur_cpu_spec;
>
> -extern void identify_cpu(unsigned long offset, unsigned long cpu);
> -extern void do_cpu_ftr_fixups(unsigned long offset);
> +extern struct cpu_spec *identify_cpu(unsigned long offset);
>
> #endif /* __ASSEMBLY__ */
>
> Index: linux-cell/include/asm-powerpc/system.h
> ===================================================================
> --- linux-cell.orig/include/asm-powerpc/system.h 2006-10-06 13:48:24.000000000 +1000
> +++ linux-cell/include/asm-powerpc/system.h 2006-10-13 16:24:45.000000000 +1000
> @@ -378,7 +378,11 @@ extern unsigned long reloc_offset(void);
> extern unsigned long add_reloc_offset(unsigned long);
> extern void reloc_got2(unsigned long);
>
> +#ifdef CONFIG_PPC64
> +#define PTRRELOC(x) x
> +#else
> #define PTRRELOC(x) ((typeof(x)) add_reloc_offset((unsigned long)(x)))
> +#endif
>
> static inline void create_instruction(unsigned long addr, unsigned int instr)
> {
> Index: linux-cell/arch/powerpc/platforms/iseries/setup.c
> ===================================================================
> --- linux-cell.orig/arch/powerpc/platforms/iseries/setup.c 2006-10-06 13:47:54.000000000 +1000
> +++ linux-cell/arch/powerpc/platforms/iseries/setup.c 2006-10-13 16:49:14.000000000 +1000
> @@ -694,6 +694,11 @@ void * __init iSeries_early_setup(void)
> {
> unsigned long phys_mem_size;
>
> + /* Identify CPU type. This is done again by the common code later
> + * on but calling this function multiple times is fine.
> + */
> + identify_cpu(0);
> +
> powerpc_firmware_features |= FW_FEATURE_ISERIES;
> powerpc_firmware_features |= FW_FEATURE_LPAR;
>
>
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Graphic issues (emulating VGA bios on IBM Maple)
From: jf simon @ 2006-10-13 17:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1160604978.4792.12.camel@localhost.localdomain>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii; format=flowed, Size: 509 bytes --]
Benjamin Herrenschmidt wrote:
>>[C000000000BFFE60] [C0000000003CCC9C] .radeonfb_old_init+0x164/0x188
>>
>>
>
>Try getting rid of the old radeonfb and see if that works.
>
>Ben.
>
>
>
>
Thanks. It is now working. I have X running on my screen now.
-jfs
___________________________________________________________________________
Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions !
Demandez à ceux qui savent sur Yahoo! Questions/Réponses
http://fr.answers.yahoo.com
^ permalink raw reply
* Re: [PATCH] powerpc: Add mktree utility to arch/powerpc/boot
From: Josh Boyer @ 2006-10-13 18:25 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <452FBB67.4060509@am.sony.com>
On Fri, 2006-10-13 at 09:14 -0700, Geoff Levand wrote:
> Josh Boyer wrote:
> > + * Makes a tree bootable image for IBM Evaluation boards.
> > + * Basically, just take a zImage, skip the ELF header, and stuff
> > + * a 32 byte header on the front.
>
> I guess you mean on some standard bootloader that comes with
> IBM Evaluation boards? Should this comment reflect that this
> operation is required by that bootloader, not the hardware?
Yes, this is needed for the standard bootloader on some boards.
However, neither the bootloader or the HW are doing what the comment
says. That is what mktree.c itself does, so I think it's correctly
describing what's going on.
BTW, this is simply a copy of the mktree.c that's been in
arch/ppc/boot/simple for years. I'm simply adding it to arch/powerpc in
preparation for some more 4xx merge work to follow.
josh
^ permalink raw reply
* Re: [PATCH] powerpc: Add mktree utility to arch/powerpc/boot
From: Josh Boyer @ 2006-10-13 18:26 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, paulus
In-Reply-To: <452FBB67.4060509@am.sony.com>
On Fri, 2006-10-13 at 09:14 -0700, Geoff Levand wrote:
> Josh Boyer wrote:
> > + * Makes a tree bootable image for IBM Evaluation boards.
> > + * Basically, just take a zImage, skip the ELF header, and stuff
> > + * a 32 byte header on the front.
>
> I guess you mean on some standard bootloader that comes with
> IBM Evaluation boards? Should this comment reflect that this
> operation is required by that bootloader, not the hardware?
Yes, this is needed for the standard bootloader on some boards.
However, neither the bootloader or the HW are doing what the comment
says. That is what mktree.c itself does, so I think it's correctly
describing what's going on.
BTW, this is simply a copy of the mktree.c that's been in
arch/ppc/boot/simple for years. I'm simply adding it to arch/powerpc in
preparation for some more 4xx merge work to follow.
josh
^ permalink raw reply
* kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-13 18:41 UTC (permalink / raw)
To: linuxppc-dev, linux-kernel, Christoph Lameter
Hi Folks,
Am seeing a crash on a power5 LPAR when booting the linux-2.6 git
tree. It's fairly early during boot, so I've included the whole log
below. This partition has 8 procs, (shared, including threads), and
512M RAM.
A bisect claims:
765c4507af71c39aba21006bbd3ec809fe9714ff is first bad commit
commit 765c4507af71c39aba21006bbd3ec809fe9714ff
Author: Christoph Lameter <clameter@sgi.com>
Date: Wed Sep 27 01:50:08 2006 -0700
[PATCH] GFP_THISNODE for the slab allocator
Am willing to dig deeper, but looking for pointers on what to poke next.
Thanks,
-Will
-----------------------------------------------------
ppc64_pft_size = 0x18
physicalMemorySize = 0x22000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address = 0x0000000000000000
htab_hash_mask = 0x1ffff
-----------------------------------------------------
Linux version 2.6.19-rc1-gb8a3ad5b (willschm@airbag2) (gcc version 4.1.0
(SUSE Linux)) #56 SMP Fri Oct 13 13:06:18 CDT 2006
[boot]0012 Setup Arch
No ramdisk, default root is /dev/sda2
EEH: No capable adapters found
PPC64 nvram contains 7168 bytes
Zone PFN ranges:
DMA 0 -> 139264
Normal 139264 -> 139264
early_node_map[3] active PFN ranges
1: 0 -> 32768
0: 32768 -> 90112
1: 90112 -> 139264
[boot]0015 Setup Done
Built 2 zonelists. Total pages: 136576
Kernel command line: root=/dev/sda3 xmon=on
[boot]0020 XICS Init
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
freeing bootmem node 0
freeing bootmem node 1
Memory: 530256k/557056k available (5508k kernel code, 30468k reserved,
2224k data, 543k bss, 244k init)
kernel BUG in __cache_alloc_node
at /development/kernels/linux-2.6.git/mm/slab.c:3177!
cpu 0x0: Vector: 700 (Program Check) at [c0000000007938d0]
pc: c0000000000b3c78: .__cache_alloc_node+0x44/0x1e8
lr: c0000000000b3ec8: .fallback_alloc+0xac/0xf0
sp: c000000000793b50
msr: 8000000000021032
current = 0xc000000000583a90
paca = 0xc000000000584300
pid = 0, comm = swapper
kernel BUG in __cache_alloc_node
at /development/kernels/linux-2.6.git/mm/slab.c:3177!
enter ? for help
[c000000000793c00] c0000000000b3ec8 .fallback_alloc+0xac/0xf0
[c000000000793ca0] c0000000000b4478 .kmem_cache_zalloc+0xc8/0x11c
[c000000000793d40] c0000000000b6624 .kmem_cache_create+0x1e8/0x5e0
[c000000000793e30] c00000000053e834 .kmem_cache_init+0x1d8/0x4b0
[c000000000793ef0] c000000000524748 .start_kernel+0x244/0x328
[c000000000793f90] c0000000000084f8 .start_here_common+0x54/0x5c
0:mon>
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-13 19:05 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1160764895.11239.14.camel@farscape>
On Fri, 13 Oct 2006, Will Schmidt wrote:
> Am seeing a crash on a power5 LPAR when booting the linux-2.6 git
> tree. It's fairly early during boot, so I've included the whole log
> below. This partition has 8 procs, (shared, including threads), and
> 512M RAM.
This looks like slab bootstrap. You are bootstrapping while having
zonelists build with zones that are only going to be populated later?
This will lead to incorrect NUMA placement of lots of slab structures on
bootup.
Check if the patch below may cure the oops. Your memory is likely
still placed on the wrong numa nodes since we have to fallback from
the intended node.
Index: linux-2.6/mm/slab.c
===================================================================
--- linux-2.6.orig/mm/slab.c 2006-10-13 11:59:55.000000000 -0700
+++ linux-2.6/mm/slab.c 2006-10-13 12:03:15.000000000 -0700
@@ -3154,7 +3154,8 @@ void *fallback_alloc(struct kmem_cache *
for (z = zonelist->zones; *z && !obj; z++)
if (zone_idx(*z) <= ZONE_NORMAL &&
- cpuset_zone_allowed(*z, flags))
+ cpuset_zone_allowed(*z, flags) &&
+ (*z)->free_pages)
obj = __cache_alloc_node(cache,
flags | __GFP_THISNODE,
zone_to_nid(*z));
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-13 19:53 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0610131158270.26311@schroedinger.engr.sgi.com>
On Fri, 2006-13-10 at 12:05 -0700, Christoph Lameter wrote:
> On Fri, 13 Oct 2006, Will Schmidt wrote:
>
> > Am seeing a crash on a power5 LPAR when booting the linux-2.6 git
> > tree. It's fairly early during boot, so I've included the whole log
> > below. This partition has 8 procs, (shared, including threads), and
> > 512M RAM.
>
> This looks like slab bootstrap. You are bootstrapping while having
> zonelists build with zones that are only going to be populated later?
> This will lead to incorrect NUMA placement of lots of slab structures on
> bootup.
I dont think so.. but it's not an area I'm very familiar with. one
of the other PPC folks might chime in with something here.
>
> Check if the patch below may cure the oops. Your memory is likely
> still placed on the wrong numa nodes since we have to fallback from
> the intended node.
Nope, no change with this patch.
>
> Index: linux-2.6/mm/slab.c
> ===================================================================
> --- linux-2.6.orig/mm/slab.c 2006-10-13 11:59:55.000000000 -0700
> +++ linux-2.6/mm/slab.c 2006-10-13 12:03:15.000000000 -0700
> @@ -3154,7 +3154,8 @@ void *fallback_alloc(struct kmem_cache *
>
> for (z = zonelist->zones; *z && !obj; z++)
> if (zone_idx(*z) <= ZONE_NORMAL &&
> - cpuset_zone_allowed(*z, flags))
> + cpuset_zone_allowed(*z, flags) &&
> + (*z)->free_pages)
> obj = __cache_alloc_node(cache,
> flags | __GFP_THISNODE,
> zone_to_nid(*z));
^ permalink raw reply
* uartlite with 2.6.17 kernel and kernel early text messages
From: Robert Corley @ 2006-10-13 20:44 UTC (permalink / raw)
To: linux linuxppc-embedded
I am still trying to get the UARTLITE to work with 2.6 and a plb_temac desi=
gn. I am using EDK 7.1. I have generated the edk files and copied xparame=
ters_ml300.h to arch/ppc/platforms/4xx/xparameters.xparameters_ml403.h=0A=
=0AIn an effort to get past the "Rebooting to System ACE Configuration Addr=
ess 6..." message, I have selected "support for early boot texts over seria=
l port" in kernel debugging.=0A=0AFYI, I'm using Peter's patches to create =
the uartlite.c and associated files and have selected the uartlite using ma=
ke menuconfig.=0A=0AThe first error is as follows:=0Aathena startup_network=
# make ARCH=3Dppc zImage.initrd=0A CHK include/linux/version.h=0A CH=
K include/linux/compile.h=0Adnsdomainname: Unknown host=0A CC arc=
h/ppc/syslib/gen550_dbg.o=0Aarch/ppc/syslib/gen550_dbg.c:36: error: `RS_TAB=
LE_SIZE' undeclared here (not in a function)=0Aarch/ppc/syslib/gen550_dbg.c=
:38: error: empty scalar initializer=0Aarch/ppc/syslib/gen550_dbg.c:38: err=
or: (near initialization for `rs_table')=0Aarch/ppc/syslib/gen550_dbg.c:36:=
error: storage size of `rs_table' isn't known=0Aarch/ppc/syslib/gen550_dbg=
.c:36: warning: 'rs_table' defined but not used=0Amake[1]: *** [arch/ppc/sy=
slib/gen550_dbg.o] Error 1=0Amake: *** [arch/ppc/syslib] Error 2=0A=0Aso, I=
modified the gen550_dbg.c file to #include the xparameters.h, where the RS=
_TABLE_SIZE is defined=0A but still get more errors. Here they are:=0A=0A =
CHK include/linux/version.h=0A CHK include/linux/compile.h=0Adnsd=
omainname: Unknown host=0A CC arch/ppc/syslib/gen550_dbg.o=0Aarch/ppc=
/syslib/gen550_dbg.c:37: error: `XPAR_UARTNS550_0_CLOCK_FREQ_HZ' undeclared=
here (not in a function)=0Aarch/ppc/syslib/gen550_dbg.c:37: error: initial=
izer element is not constant=0Aarch/ppc/syslib/gen550_dbg.c:37: error: (nea=
r initialization for `rs_table[0].baud_base')=0Aarch/ppc/syslib/gen550_dbg.=
c:37: error: `XPAR_INTC_0_UARTNS550_0_VEC_ID' undeclared here (not in a fun=
ction)=0Aarch/ppc/syslib/gen550_dbg.c:37: error: initializer element is not=
constant=0Aarch/ppc/syslib/gen550_dbg.c:37: error: (near initialization fo=
r `rs_table[0].irq')=0Aarch/ppc/syslib/gen550_dbg.c:37: error: `XPAR_UARTNS=
550_0_BASEADDR' undeclared here (not in a function)=0Aarch/ppc/syslib/gen55=
0_dbg.c:37: error: initializer element is not constant=0Aarch/ppc/syslib/ge=
n550_dbg.c:37: error: (near initialization for `rs_table[0].iomem_base')=0A=
arch/ppc/syslib/gen550_dbg.c:37: error: initializer element is not constant=
=0Aarch/ppc/syslib/gen550_dbg.c:37: error: (near initialization for `rs_tab=
le[0]')=0Amake[1]: *** [arch/ppc/syslib/gen550_dbg.o] Error 1=0Amake: *** [=
arch/ppc/syslib] Error 2=0A=0AQuestions:=0A=0A1. Now, is this an issue w=
ith the UARTLITE driver or is it just not supported for early messaging?=0A=
2. What am I missing w.r.t. getting something out of the serial port?=0A3=
. I am assuming that the boot args for a initrd boot are: "console=3Dtt=
yUL0 ip=3Doff root=3D/dev/ram rw", correct?=0A=0A-corley=0A=0A
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Will Schmidt @ 2006-10-13 20:57 UTC (permalink / raw)
To: Christoph Lameter; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1160769226.11239.22.camel@farscape>
On Fri, 2006-13-10 at 14:53 -0500, Will Schmidt wrote:
> On Fri, 2006-13-10 at 12:05 -0700, Christoph Lameter wrote:
> > On Fri, 13 Oct 2006, Will Schmidt wrote:
> >
> > > Am seeing a crash on a power5 LPAR when booting the linux-2.6 git
> > > tree. It's fairly early during boot, so I've included the whole log
> > > below. This partition has 8 procs, (shared, including threads), and
> > > 512M RAM.
> >
> > This looks like slab bootstrap. You are bootstrapping while having
> > zonelists build with zones that are only going to be populated later?
> > This will lead to incorrect NUMA placement of lots of slab structures on
> > bootup.
>
> I dont think so.. but it's not an area I'm very familiar with. one
> of the other PPC folks might chime in with something here.
>
> >
> > Check if the patch below may cure the oops. Your memory is likely
> > still placed on the wrong numa nodes since we have to fallback from
> > the intended node.
>
> Nope, no change with this patch.
>
Here is another boot log, with that patch applied, and with a numa=debug
parm.
-----------------------------------------------------
ppc64_pft_size = 0x18
physicalMemorySize = 0x22000000
ppc64_caches.dcache_line_size = 0x80
ppc64_caches.icache_line_size = 0x80
htab_address = 0x0000000000000000
htab_hash_mask = 0x1ffff
-----------------------------------------------------
Linux version 2.6.19-rc1-gb8a3ad5b-dirty (willschm@airbag2) (gcc version
4.1.0 (SUSE Linux)) #60 SMP Fri Oct 13 14:48:20 CDT 2006
[boot]0012 Setup Arch
NUMA associativity depth for CPU/Memory: 3
adding cpu 0 to node 0
node 0
NODE_DATA() = c000000015ffee80
start_paddr = 8000000
end_paddr = 16000000
bootmap_paddr = 15ffc000
reserve_bootmem ffc0000 40000
reserve_bootmem 15ffc000 2000
reserve_bootmem 15ffee80 1180
node 1
NODE_DATA() = c000000021ff7c80
start_paddr = 0
end_paddr = 22000000
bootmap_paddr = 21ff2000
reserve_bootmem 0 847000
reserve_bootmem 264b000 9000
reserve_bootmem 77b2000 84e000
reserve_bootmem 21ff2000 5000
reserve_bootmem 21ff7c80 1180
reserve_bootmem 21ff8e58 71a4
No ramdisk, default root is /dev/sda2
EEH: No capable adapters found
PPC64 nvram contains 7168 bytes
Zone PFN ranges:
DMA 0 -> 139264
Normal 139264 -> 139264
early_node_map[3] active PFN ranges
1: 0 -> 32768
0: 32768 -> 90112
1: 90112 -> 139264
[boot]0015 Setup Done
Built 2 zonelists. Total pages: 136576
Kernel command line: root=/dev/sda3 xmon=on numa=debug
[boot]0020 XICS Init
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
freeing bootmem node 0
freeing bootmem node 1
Memory: 530256k/557056k available (5508k kernel code, 30468k reserved,
2224k data, 543k bss, 244k init)
kernel BUG in __cache_alloc_node
at /development/kernels/linux-2.6.git/mm/slab.c:3178!
cpu 0x0: Vector: 700 (Program Check) at [c0000000007938d0]
pc: c0000000000b3c78: .__cache_alloc_node+0x44/0x1e8
lr: c0000000000b3ed4: .fallback_alloc+0xb8/0xfc
sp: c000000000793b50
msr: 8000000000021032
current = 0xc000000000583a90
paca = 0xc000000000584300
pid = 0, comm = swapper
kernel BUG in __cache_alloc_node
at /development/kernels/linux-2.6.git/mm/slab.c:3178!
enter ? for help
[c000000000793c00] c0000000000b3ed4 .fallback_alloc+0xb8/0xfc
[c000000000793ca0] c0000000000b4484 .kmem_cache_zalloc+0xc8/0x11c
[c000000000793d40] c0000000000b6630 .kmem_cache_create+0x1e8/0x5e0
[c000000000793e30] c00000000053e834 .kmem_cache_init+0x1d8/0x4b0
[c000000000793ef0] c000000000524748 .start_kernel+0x244/0x328
[c000000000793f90] c0000000000084f8 .start_here_common+0x54/0x5c
0:mon>
^ permalink raw reply
* Re: preempt crash in 2.6.18
From: Vitaly Bordug @ 2006-10-13 21:21 UTC (permalink / raw)
To: Rune Torgersen; +Cc: linuxppc-dev
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B07B397@ismail.innsys.innovsys.com>
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
On Fri, 13 Oct 2006 09:16:52 -0500
Rune Torgersen wrote:
>
> This is from a Freescale 8265 running 2.6.18
> Anyone have any idea what this is and how to fix it?
>
Yes. Actually, I recall alike thing and used to fix with proper spin-locking if the
cascade PCI irq, which apparently does do_irq that seems to confuse preempt counters.
Just a pure guess.
Hope it helps.
-Vitaly
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Nathan Lynch @ 2006-10-13 21:22 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, linux-kernel, Christoph Lameter
In-Reply-To: <1160773040.11239.28.camel@farscape>
Will Schmidt wrote:
> On Fri, 2006-13-10 at 14:53 -0500, Will Schmidt wrote:
> > On Fri, 2006-13-10 at 12:05 -0700, Christoph Lameter wrote:
> > > On Fri, 13 Oct 2006, Will Schmidt wrote:
> > >
> > > > Am seeing a crash on a power5 LPAR when booting the linux-2.6 git
> > > > tree. It's fairly early during boot, so I've included the whole log
> > > > below. This partition has 8 procs, (shared, including threads), and
> > > > 512M RAM.
> > >
> > > This looks like slab bootstrap. You are bootstrapping while having
> > > zonelists build with zones that are only going to be populated later?
> > > This will lead to incorrect NUMA placement of lots of slab structures on
> > > bootup.
> >
> > I dont think so.. but it's not an area I'm very familiar with. one
> > of the other PPC folks might chime in with something here.
> >
> > >
> > > Check if the patch below may cure the oops. Your memory is likely
> > > still placed on the wrong numa nodes since we have to fallback from
> > > the intended node.
> >
> > Nope, no change with this patch.
> >
>
> Here is another boot log, with that patch applied, and with a numa=debug
> parm.
>
> -----------------------------------------------------
> ppc64_pft_size = 0x18
> physicalMemorySize = 0x22000000
> ppc64_caches.dcache_line_size = 0x80
> ppc64_caches.icache_line_size = 0x80
> htab_address = 0x0000000000000000
> htab_hash_mask = 0x1ffff
> -----------------------------------------------------
> Linux version 2.6.19-rc1-gb8a3ad5b-dirty (willschm@airbag2) (gcc version
> 4.1.0 (SUSE Linux)) #60 SMP Fri Oct 13 14:48:20 CDT 2006
> [boot]0012 Setup Arch
> NUMA associativity depth for CPU/Memory: 3
> adding cpu 0 to node 0
> node 0
> NODE_DATA() = c000000015ffee80
> start_paddr = 8000000
> end_paddr = 16000000
> bootmap_paddr = 15ffc000
> reserve_bootmem ffc0000 40000
> reserve_bootmem 15ffc000 2000
> reserve_bootmem 15ffee80 1180
> node 1
> NODE_DATA() = c000000021ff7c80
> start_paddr = 0
> end_paddr = 22000000
Strange, node 0 appears to be in the middle of node 1.
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Anton Blanchard @ 2006-10-13 21:34 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, linux-kernel, Christoph Lameter
In-Reply-To: <20061013212202.GG28620@localdomain>
Hi,
> Strange, node 0 appears to be in the middle of node 1.
Its an odd setup and may be a firmware issue but Ive seen it a number of
times on POWER5 boxes.
Anton
^ permalink raw reply
* Eeek! page_mapcount(page) went negative! (-1) -2.6.16.2 kernel
From: agnel juni @ 2006-10-13 21:48 UTC (permalink / raw)
To: linux linuxppc-embedded
In-Reply-To: <20061013204442.52818.qmail@web56308.mail.re3.yahoo.com>
[-- Attachment #1: Type: text/plain, Size: 3354 bytes --]
Hello all,
We are working on System ACE driver ported for AMCC44x based custom platform, on linux kernel-2.6.16.2
We have formatted the flash with FAT16 filesystem as System ACE supports only that.
We are able to run all the filessytem commands except that 'mount' shows inconsisten behaviour.
I have turned off the "Use full SLAB allocator" option under kernel configuration.
With this, when mount fails I see Kernel throwing Oops sometimes.
Any suggestions to debug this are greatly appreciated.
################# Kernel Oops #######################
# mount -t msdos /dev/xsysace /mnt/
Bad pte = df452f3cdf452f3c, process = exe, vm_flags = 75, vaddr = fe11a64
Call Trace:
[DFF97DE8] [C000958C] show_stack+0x48/0x194 (unreliable)
[DFF97E18] [C00470CC] print_bad_pte+0x44/0x54
[DFF97E20] [C0049694] __handle_mm_fault+0x900/0x930
[DFF97E78] [C000A174] do_page_fault+0x268/0x4fc
[DFF97F40] [C0001FE0] handle_page_fault+0xc/0x80
VM: killing process exe
swap_free: Bad swap file entry 62696e2f
swap_free: Bad swap file entry 026f7800
swap_free: Bad swap file entry 30c070c3
swap_free: Bad swap file entry b8df44b2
swap_free: Bad swap file entry c0df44b2
Bad pte = 5800000001, process = ???, vm_flags = 75, vaddr = fe12000
Call Trace:
[DFF97D28] [C000958C] show_stack+0x48/0x194 (unreliable)
[DFF97D58] [C00470CC] print_bad_pte+0x44/0x54
[DFF97D60] [C0047168] vm_normal_page+0x8c/0x94
[DFF97D68] [C004794C] unmap_vmas+0x424/0x5c8
[DFF97DF8] [C004CAC8] exit_mmap+0x60/0xec
[DFF97E18] [C0016C3C] mmput+0x50/0xd4
[DFF97E28] [C001B228] exit_mm+0x120/0x1a0
[DFF97E40] [C001B864] do_exit+0x11c/0x77c
[DFF97E78] [C000A2A4] do_page_fault+0x398/0x4fc
[DFF97F40] [C0001FE0] handle_page_fault+0xc/0x80
Eeek! page_mapcount(page) went negative! (-1)
page->flags = 400
page->count = 1
page->mapping = 00000000
kernel BUG in page_remove_rmap at mm/rmap.c:560!
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C004E620 LR: C004E698 CTR: 00000000
REGS: dff97ca8 TRAP: 0700 Not tainted (2.6.16.2)
MSR: 00029000 <EE,ME> CR: 24022022 XER: 00000000
TASK = df463000[610] 'exe' THREAD: dff96000
GPR00: C004E698 DFF97D58 DF463000 0000001E 00000FBC FFFFFFFF C0240000 C01F0C0C
GPR08: C01F0000 00000001 00000000 C0240000 00000000 10065ABC DFC46D10 0FF08FFF
GPR16: C0243C18 00000000 FFFFFFFF FFFFFFFF 00000000 0FF09000 DFD2AA50 DF4821FC
GPR24: 00000000 DFF97D74 A1FF0000 00000001 0FF09000 C0259000 0FE13000 C0259000
NIP [C004E620] page_remove_rmap+0x68/0xe4
LR [C004E698] page_remove_rmap+0xe0/0xe4
Call Trace:
[DFF97D58] [C004E698] page_remove_rmap+0xe0/0xe4 (unreliable)
[DFF97D68] [C004799C] unmap_vmas+0x474/0x5c8
[DFF97DF8] [C004CAC8] exit_mmap+0x60/0xec
[DFF97E18] [C0016C3C] mmput+0x50/0xd4
[DFF97E28] [C001B228] exit_mm+0x120/0x1a0
[DFF97E40] [C001B864] do_exit+0x11c/0x77c
[DFF97E78] [C000A2A4] do_page_fault+0x398/0x4fc
[DFF97F40] [C0001FE0] handle_page_fault+0xc/0x80
Instruction dump:
83e1000c 38210010 7c0803a6 4e800020 801f0008 3c60c01c 3863d5e0 35200001
41800034 813f0008 39290001 55290ffe <0f090000> 38600010 3880ffff 4bff07b1
Fixing recursive fault but reboot is needed!
Thanks
Junita
---------------------------------
Find out what India is talking about on - Yahoo! Answers India
Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get it NOW
[-- Attachment #2: Type: text/html, Size: 3833 bytes --]
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Mike Kravetz @ 2006-10-13 22:01 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, linux-kernel, Christoph Lameter
In-Reply-To: <20061013212202.GG28620@localdomain>
On Fri, Oct 13, 2006 at 04:22:02PM -0500, Nathan Lynch wrote:
> Will Schmidt wrote:
> > NUMA associativity depth for CPU/Memory: 3
> > adding cpu 0 to node 0
> > node 0
> > NODE_DATA() = c000000015ffee80
> > start_paddr = 8000000
> > end_paddr = 16000000
> > bootmap_paddr = 15ffc000
> > reserve_bootmem ffc0000 40000
> > reserve_bootmem 15ffc000 2000
> > reserve_bootmem 15ffee80 1180
> > node 1
> > NODE_DATA() = c000000021ff7c80
> > start_paddr = 0
> > end_paddr = 22000000
>
> Strange, node 0 appears to be in the middle of node 1.
IIRC, this is fairly common. Or, it was on the system/LPAR I had access
to. I'd check again, but I lost easy access to that system. :(
--
Mike
^ permalink raw reply
* Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177!
From: Christoph Lameter @ 2006-10-13 22:22 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1160773040.11239.28.camel@farscape>
Here is another fall back fix checking if the slab has already been setup
for this node. MPOL_INTERLEAVE could redirect the allocation.
Index: linux-2.6.19-rc1-mm1/mm/slab.c
===================================================================
--- linux-2.6.19-rc1-mm1.orig/mm/slab.c 2006-10-10 21:47:12.949563383 -0500
+++ linux-2.6.19-rc1-mm1/mm/slab.c 2006-10-13 17:21:31.937863714 -0500
@@ -3158,12 +3158,15 @@ void *fallback_alloc(struct kmem_cache *
struct zone **z;
void *obj = NULL;
- for (z = zonelist->zones; *z && !obj; z++)
+ for (z = zonelist->zones; *z && !obj; z++) {
+ int nid = zone_to_nid(*z);
+
if (zone_idx(*z) <= ZONE_NORMAL &&
- cpuset_zone_allowed(*z, flags))
+ cpuset_zone_allowed(*z, flags) &&
+ cache->nodelists[nid])
obj = __cache_alloc_node(cache,
- flags | __GFP_THISNODE,
- zone_to_nid(*z));
+ flags | __GFP_THISNODE, nid);
+ }
return obj;
}
^ permalink raw reply
* Re: uartlite with 2.6.17 kernel and kernel early text messages
From: Michael Galassi @ 2006-10-13 22:26 UTC (permalink / raw)
To: Robert Corley; +Cc: linux linuxppc-embedded
In-Reply-To: <20061013204442.52818.qmail@web56308.mail.re3.yahoo.com>
>In an effort to get past the "Rebooting to System ACE Configuration
>Address 6..." message, I have selected "support for early boot texts
>over serial port" in kernel debugging.
This will not work. Unfortunately linux here shows its roots as PS OS,
there is a vast amount of hardcoded NS8250/NS16550 knowledge in there.
I'd started modularizing this so we could use a UART lite but the more I
dug the lower my motivation. This is really ugly code in an area that
is of virtually no interest. For now get rid of support for early boot
texts over serial port" and use your JTAG to read the buffers if you
panic before the console is up and running.
-michael
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Benjamin Herrenschmidt @ 2006-10-13 22:36 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev list
In-Reply-To: <20061013115457.7b36a7c3@localhost.localdomain>
> You can advance the pointer with L1_CACHE_BYTES/sizeof(int) per
> iteration in the second loop here.
Yeah, I suppose so. Though I'm not 100% confident we get L1_CACHE_BYTES
on all cpus, for example, PA6T is 64 bytes ;) We could use
cur_cpu_spec->icache_bsize but that would involve ugly RELOC's to get it
right on 32 bits. I decided not to care for now.
Ben.
^ permalink raw reply
* Re: preempt crash in 2.6.18
From: Benjamin Herrenschmidt @ 2006-10-13 23:14 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-dev
In-Reply-To: <20061014012105.6ca4ff05@localhost.localdomain>
On Sat, 2006-10-14 at 01:21 +0400, Vitaly Bordug wrote:
> On Fri, 13 Oct 2006 09:16:52 -0500
> Rune Torgersen wrote:
>
> >
> > This is from a Freescale 8265 running 2.6.18
> > Anyone have any idea what this is and how to fix it?
> >
> Yes. Actually, I recall alike thing and used to fix with proper spin-locking if the
> cascade PCI irq, which apparently does do_irq that seems to confuse preempt counters.
>
> Just a pure guess.
How so ? Cascades shouldn't do do_IRQ with the new irq code anyway
unless this is still arch/ppc, they should do either __do_IRQ or better,
generic_handle_irq().
Ben.
^ permalink raw reply
* Re: Recently removed io accessors
From: Paul Mackerras @ 2006-10-13 23:20 UTC (permalink / raw)
To: Peter Korsgaard; +Cc: linuxppc-dev, sfr
In-Reply-To: <87slhstxlk.fsf@sleipner.barco.com>
Peter Korsgaard writes:
> We're using the smsc9117
> (http://www.smsc.com/main/datasheets/9117.pdf) connected over a 16bit
> EMC bus (together with a spansion 29PL127 flash) to a Xilinx V4FX FPGA
> with a 405 core in it.
>
> LSB of the processor is connected to LSB of of the 9117 (and same for
> the flash) and so on.
>
> Reading the byte test register of the 9117 (supposed to contain
> 0x87654321) gives:
>
> Endian register set to little endian (default at powerup):
> RedBoot> x -b 0x8e000064 -2 -l 4
> 8E000064: 4321 8765
> RedBoot> x -b 0x8e000064 -4 -l 4
> 8E000064: 43218765
Which is neither big-endian nor little-endian, but something more like
vax-endian (or pdp11-endian), but not exactly that either - vax-endian
would be 65872143. What a mess.
> And with it set to big endian:
> RedBoot> x -b 0x8e000064 -2 -l 4
> 8E000064: 8765 4321
> RedBoot> x -b 0x8e000064 -4 -l 4
> 8E000064: 87654321
Clearly the "big endian" bit on the chip doesn't actually switch
between little-endian and big-endian at all, but just acts to invert
the 0x2 bit of the address...
So the two hardware bogosities taken together leave you with only one
combination that is anything like usable. I suggest that you code up
a loop of readw (or equivalent) in the driver with a big comment
explaining why you need to do it that way.
Paul.
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Stephen Rothwell @ 2006-10-14 1:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20061013115457.7b36a7c3@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 435 bytes --]
Hi Olof,
On Fri, 13 Oct 2006 11:54:57 -0500 Olof Johansson <olof@lixom.net> wrote:
>
... lots of stuff deleted ...
Could you please trim your replies to just areasonable amount of context,
please. You are not the only one who is at fault here, but yours was the
example that came my way just as I needed to point out the problem.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Olof Johansson @ 2006-10-14 1:58 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20061014114259.0cf258ed.sfr@canb.auug.org.au>
On Sat, 14 Oct 2006 11:42:59 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Olof,
>
> On Fri, 13 Oct 2006 11:54:57 -0500 Olof Johansson <olof@lixom.net> wrote:
> >
> ... lots of stuff deleted ...
>
> Could you please trim your replies to just areasonable amount of context,
> please. You are not the only one who is at fault here, but yours was the
> example that came my way just as I needed to point out the problem.
I normally try to do it, I think I might have been sloppy lately.
Thanks for the reminder.
-Olof
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Olof Johansson @ 2006-10-14 2:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160779006.4792.269.camel@localhost.localdomain>
On Sat, 14 Oct 2006 08:36:46 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > You can advance the pointer with L1_CACHE_BYTES/sizeof(int) per
> > iteration in the second loop here.
>
> Yeah, I suppose so. Though I'm not 100% confident we get L1_CACHE_BYTES
> on all cpus, for example, PA6T is 64 bytes ;) We could use
> cur_cpu_spec->icache_bsize but that would involve ugly RELOC's to get it
> right on 32 bits. I decided not to care for now.
Ugh, yeah, I remember this when I did the patches but forgot about it
now. L1_CACHE_BYTES is used in a number of places, but overall used as
the largest value needed to bump between lines to avoid false sharing.
The other early places seems to have used hardcoded constants. I guess
it's better to just loop over every word like you're already doing. It
still avoids a barrier on every iteration.
-Olof
^ permalink raw reply
* Re: [PATCH 1/5] powerpc: consolidate feature fixup code
From: Olof Johansson @ 2006-10-14 2:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1160726663.4792.222.camel@localhost.localdomain>
On Fri, 13 Oct 2006 18:04:22 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> There are currently two versions of the functions for applying the
> feature fixups, one for CPU features and one for firmware features. In
> addition, they are both in assembly and with separate implementations
> for 32 and 64 bits. identify_cpu() is also implemented in assembly and
> separately for 32 and 64 bits.
>
> This patch replaces them with a pair of C functions. The call sites are
> slightly moved on ppc64 as well to be called from C instead of from
> assembly, though it's a very small change, and thus shouldn't cause any
> problem.
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Olof Johansson <olof@lixom.net>
^ permalink raw reply
* Re: [PATCH 21/21]: powerpc/cell spidernet DMA coalescing
From: Joel Schopp @ 2006-10-14 2:12 UTC (permalink / raw)
To: Linas Vepstas
Cc: akpm, jeff, Arnd Bergmann, netdev, James K Lewis, linux-kernel,
linuxppc-dev
In-Reply-To: <20061010212324.GR4381@austin.ibm.com>
Linas Vepstas wrote:
> The current driver code performs 512 DMA mappns of a bunch of
> 32-byte structures. This is silly, as they are all in contiguous
> memory. Ths patch changes the code to DMA map the entie area
> with just one call.
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Cc: James K Lewis <jklewis@us.ibm.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
While this patch wasn't useful in the current cell implementation of pci_map_single
it sounds like people are going to be making changes to that sometime. In light of
that new information (new to me anyway) this should probably go in after all. Sorry
for causing trouble.
Acked-by: Joel Schopp <jschopp@austin.ibm.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox