Re: Lock-up on PPC64
On Wed, 7 Jan 2009, malc wrote: > On Wed, 7 Jan 2009, Benjamin Herrenschmidt wrote: > > > > > > As you wish :) I've written some ad-hoc stuff in the failing path which > > > manually triggers sysrq and then sends the klogctl output via network > > > and here it is: > > > > Allright, something's unclear to me. What do you mean by the system goes > > down then ? The kernel appears to be working at least to a certain > > extent if you manage to trigger a sysrq from userspace... And from what > > I see, it looks that all processes are somewhere in schedule. > > > > So what is precisely your symptom here ? After writing valgrind tool that was simulating Cell XER.SO syscall (mis)behaviour (pre ab598b6680f1e74c267d1547ee352f3e1e530f89 that is) and banging my had against the wall for a while trying to figure out which of the failing syscalls was responsible, i've tried to be simple and after only ~30 minutes came up with this, rather short, piece of code that knocks pre XER.SO patched kernels out cold: gcc -o xer -x assembler /dev/stdin -nostdlib
[patch 07/10] powerpc: Randomise the brk region
Randomize the heap.
before:
tundro2:~ # sleep 1 & cat /proc/${!}/maps | grep heap
10017000-10118000 rw-p 10017000 00:00 0 [heap]
10017000-10118000 rw-p 10017000 00:00 0 [heap]
10017000-10118000 rw-p 10017000 00:00 0 [heap]
10017000-10118000 rw-p 10017000 00:00 0 [heap]
10017000-10118000 rw-p 10017000 00:00 0 [heap]
after
tundro2:~ # sleep 1 & cat /proc/${!}/maps | grep heap
19419000-1951a000 rw-p 19419000 00:00 0 [heap]
325ff000-3270 rw-p 325ff000 00:00 0 [heap]
1a97c000-1aa7d000 rw-p 1a97c000 00:00 0 [heap]
1cc6-1cd61000 rw-p 1cc6 00:00 0 [heap]
1afa9000-1b0aa000 rw-p 1afa9000 00:00 0 [heap]
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/include/asm/elf.h
===
--- linux-2.6.orig/arch/powerpc/include/asm/elf.h 2009-02-20
16:06:32.0 +1100
+++ linux-2.6/arch/powerpc/include/asm/elf.h2009-02-22 11:58:02.0
+1100
@@ -275,6 +275,9 @@
(0x7ff >> (PAGE_SHIFT - 12)) : \
(0x3 >> (PAGE_SHIFT - 12)))
+extern unsigned long arch_randomize_brk(struct mm_struct *mm);
+#define arch_randomize_brk arch_randomize_brk
+
#endif /* __KERNEL__ */
/*
Index: linux-2.6/arch/powerpc/kernel/process.c
===
--- linux-2.6.orig/arch/powerpc/kernel/process.c2009-02-20
16:06:32.0 +1100
+++ linux-2.6/arch/powerpc/kernel/process.c 2009-02-22 11:58:02.0
+1100
@@ -1131,3 +1131,26 @@
sp -= get_random_int() & ~PAGE_MASK;
return sp & ~0xf;
}
+
+static inline unsigned long brk_rnd(void)
+{
+unsigned long rnd = 0;
+
+ /* 8MB for 32bit, 1GB for 64bit */
+ if (is_32bit_task())
+ rnd = (long)(get_random_int() % (1<<(23-PAGE_SHIFT)));
+ else
+ rnd = (long)(get_random_int() % (1<<(30-PAGE_SHIFT)));
+
+ return rnd << PAGE_SHIFT;
+}
+
+unsigned long arch_randomize_brk(struct mm_struct *mm)
+{
+ unsigned long ret = PAGE_ALIGN(mm->brk + brk_rnd());
+
+ if (ret < mm->brk)
+ return mm->brk;
+
+ return ret;
+}
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 01/10] powerpc: Move is_32bit_task
Move is_32bit_task into asm/thread_info.h, that allows us to test for
32/64bit tasks without an ugly CONFIG_PPC64 ifdef.
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/include/asm/thread_info.h
===
--- linux-2.6.orig/arch/powerpc/include/asm/thread_info.h 2009-02-20
13:44:37.0 +1100
+++ linux-2.6/arch/powerpc/include/asm/thread_info.h2009-02-20
16:03:02.0 +1100
@@ -154,6 +154,13 @@
ti->local_flags |= _TLF_RESTORE_SIGMASK;
set_bit(TIF_SIGPENDING, &ti->flags);
}
+
+#ifdef CONFIG_PPC64
+#define is_32bit_task()(test_thread_flag(TIF_32BIT))
+#else
+#define is_32bit_task()(1)
+#endif
+
#endif /* !__ASSEMBLY__ */
#endif /* __KERNEL__ */
Index: linux-2.6/arch/powerpc/kernel/signal.h
===
--- linux-2.6.orig/arch/powerpc/kernel/signal.h 2009-02-20 13:44:34.0
+1100
+++ linux-2.6/arch/powerpc/kernel/signal.h 2009-02-20 13:45:33.0
+1100
@@ -39,22 +39,12 @@
#ifdef CONFIG_PPC64
-static inline int is_32bit_task(void)
-{
- return test_thread_flag(TIF_32BIT);
-}
-
extern int handle_rt_signal64(int signr, struct k_sigaction *ka,
siginfo_t *info, sigset_t *set,
struct pt_regs *regs);
#else /* CONFIG_PPC64 */
-static inline int is_32bit_task(void)
-{
- return 1;
-}
-
static inline int handle_rt_signal64(int signr, struct k_sigaction *ka,
siginfo_t *info, sigset_t *set,
struct pt_regs *regs)
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 09/10] powerpc: Increase stack gap on 64bit binaries
On 64bit there is a possibility our stack and mmap randomisation will put the two close enough such that we can't expand our stack to match the ulimit specified. To avoid this, start the upper mmap address at 1GB + 128MB below the top of our address space, so in the worst case we end up with the same ~128MB hole as in 32bit. This works because we randomise the stack over a 1GB range. Signed-off-by: Anton Blanchard --- Index: linux-2.6/arch/powerpc/mm/mmap.c === --- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-21 09:52:23.0 +1100 +++ linux-2.6/arch/powerpc/mm/mmap.c2009-02-21 10:36:36.0 +1100 @@ -30,9 +30,16 @@ /* * Top of mmap area (just below the process stack). * - * Leave an at least ~128 MB hole. + * Leave at least a ~128 MB hole on 32bit applications. + * + * On 64bit applications we randomise the stack by 1GB so we need to + * space our mmap start address by a further 1GB, otherwise there is a + * chance the mmap area will end up closer to the stack than our ulimit + * requires. */ -#define MIN_GAP (128*1024*1024) +#define MIN_GAP32 (128*1024*1024) +#define MIN_GAP64 ((128 + 1024)*1024*1024UL) +#define MIN_GAP ((is_32bit_task()) ? MIN_GAP32 : MIN_GAP64) #define MAX_GAP (TASK_SIZE/6*5) static inline int mmap_is_legacy(void) -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 10/10] powerpc: Randomise PIEs
Randomise ELF_ET_DYN_BASE, which is used when loading position independent
executables.
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/include/asm/elf.h
===
--- linux-2.6.orig/arch/powerpc/include/asm/elf.h 2009-02-22
21:18:04.0 +1100
+++ linux-2.6/arch/powerpc/include/asm/elf.h2009-02-22 21:34:49.0
+1100
@@ -178,7 +178,8 @@
the loader. We need to make sure that it is out of the way of the program
that it will "exec", and that there is sufficient room for the brk. */
-#define ELF_ET_DYN_BASE (0x2000)
+extern unsigned long randomize_et_dyn(unsigned long base);
+#define ELF_ET_DYN_BASE(randomize_et_dyn(0x2000))
/*
* Our registers are always unsigned longs, whether we're a 32 bit
Index: linux-2.6/arch/powerpc/kernel/process.c
===
--- linux-2.6.orig/arch/powerpc/kernel/process.c2009-02-22
21:21:14.0 +1100
+++ linux-2.6/arch/powerpc/kernel/process.c 2009-02-22 21:36:02.0
+1100
@@ -1154,3 +1154,13 @@
return ret;
}
+
+unsigned long randomize_et_dyn(unsigned long base)
+{
+ unsigned long ret = PAGE_ALIGN(base + brk_rnd());
+
+ if (ret < base)
+ return base;
+
+ return ret;
+}
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 04/10] powerpc: Randomise mmap start address
Randomise mmap start address - 8MB on 32bit and 1GB on 64bit tasks.
Until ppc32 uses the mmap.c functionality, this is ppc64 specific.
Before:
# ./test & cat /proc/${!}/maps|tail -2|head -1
f75fe000-f7fff000 rw-p f75fe000 00:00 0
f75fe000-f7fff000 rw-p f75fe000 00:00 0
f75fe000-f7fff000 rw-p f75fe000 00:00 0
f75fe000-f7fff000 rw-p f75fe000 00:00 0
f75fe000-f7fff000 rw-p f75fe000 00:00 0
After:
# ./test & cat /proc/${!}/maps|tail -2|head -1
f718b000-f7b8c000 rw-p f718b000 00:00 0
f7551000-f7f52000 rw-p f7551000 00:00 0
f6ee7000-f78e8000 rw-p f6ee7000 00:00 0
f74d4000-f7ed5000 rw-p f74d4000 00:00 0
f6e9d000-f789e000 rw-p f6e9d000 00:00 0
Similar for 64bit, but with 1GB of scatter:
# ./test & cat /proc/${!}/maps|tail -2|head -1
fffb97b5000-fffb97b6000 rw-p fffb97b5000 00:00 0
fffce9a3000-fffce9a4000 rw-p fffce9a3000 00:00 0
fffeaaf2000-fffeaaf3000 rw-p fffeaaf2000 00:00 0
fffd88ac000-fffd88ad000 rw-p fffd88ac000 00:00 0
fffbc62e000-fffbc62f000 rw-p fffbc62e000 00:00 0
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/mm/mmap.c
===
--- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-20 13:46:35.0
+1100
+++ linux-2.6/arch/powerpc/mm/mmap.c2009-02-20 13:47:23.0 +1100
@@ -24,6 +24,7 @@
#include
#include
+#include
#include
/*
@@ -45,6 +46,20 @@
return sysctl_legacy_va_layout;
}
+static unsigned long mmap_rnd(void)
+{
+ unsigned long rnd = 0;
+
+ if (current->flags & PF_RANDOMIZE) {
+ /* 8MB for 32bit, 1GB for 64bit */
+ if (is_32bit_task())
+ rnd = (long)(get_random_int() % (1<<(23-PAGE_SHIFT)));
+ else
+ rnd = (long)(get_random_int() % (1<<(30-PAGE_SHIFT)));
+ }
+ return rnd << PAGE_SHIFT;
+}
+
static inline unsigned long mmap_base(void)
{
unsigned long gap = current->signal->rlim[RLIMIT_STACK].rlim_cur;
@@ -54,7 +69,7 @@
else if (gap > MAX_GAP)
gap = MAX_GAP;
- return TASK_SIZE - (gap & PAGE_MASK);
+ return PAGE_ALIGN(TASK_SIZE - gap - mmap_rnd());
}
/*
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 03/10] powerpc: Rearrange mmap.c
Rearrange mmap.c to better match the x86 version.
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/mm/mmap.c
===
--- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-20 13:40:26.0
+1100
+++ linux-2.6/arch/powerpc/mm/mmap.c2009-02-20 13:41:06.0 +1100
@@ -34,6 +34,17 @@
#define MIN_GAP (128*1024*1024)
#define MAX_GAP (TASK_SIZE/6*5)
+static inline int mmap_is_legacy(void)
+{
+ if (current->personality & ADDR_COMPAT_LAYOUT)
+ return 1;
+
+ if (current->signal->rlim[RLIMIT_STACK].rlim_cur == RLIM_INFINITY)
+ return 1;
+
+ return sysctl_legacy_va_layout;
+}
+
static inline unsigned long mmap_base(void)
{
unsigned long gap = current->signal->rlim[RLIMIT_STACK].rlim_cur;
@@ -46,17 +57,6 @@
return TASK_SIZE - (gap & PAGE_MASK);
}
-static inline int mmap_is_legacy(void)
-{
- if (current->personality & ADDR_COMPAT_LAYOUT)
- return 1;
-
- if (current->signal->rlim[RLIMIT_STACK].rlim_cur == RLIM_INFINITY)
- return 1;
-
- return sysctl_legacy_va_layout;
-}
-
/*
* This function, called very early during the creation of a new
* process VM image, sets up which VM layout function to use:
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 06/10] powerpc: Randomise lower bits of stack address
Randomise the lower bits of the stack address. More randomisation is good for
security but the scatter can also help with SMT threads that share an L1. A
quick test case shows this working:
int main()
{
int sp;
printf("%x\n", (unsigned long)&sp & 4095);
}
before:
80
80
80
80
80
after:
610
490
300
6b0
d80
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/include/asm/system.h
===
--- linux-2.6.orig/arch/powerpc/include/asm/system.h2009-02-20
13:39:05.0 +1100
+++ linux-2.6/arch/powerpc/include/asm/system.h 2009-02-20 13:51:39.0
+1100
@@ -531,7 +531,7 @@
#define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
#endif
-#define arch_align_stack(x) (x)
+extern unsigned long arch_align_stack(unsigned long sp);
/* Used in very early kernel initialization. */
extern unsigned long reloc_offset(void);
Index: linux-2.6/arch/powerpc/kernel/process.c
===
--- linux-2.6.orig/arch/powerpc/kernel/process.c2009-02-20
13:39:05.0 +1100
+++ linux-2.6/arch/powerpc/kernel/process.c 2009-02-20 13:51:39.0
+1100
@@ -34,6 +34,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -1122,3 +1124,10 @@
}
#endif /* THREAD_SHIFT < PAGE_SHIFT */
+
+unsigned long arch_align_stack(unsigned long sp)
+{
+ if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
+ sp -= get_random_int() & ~PAGE_MASK;
+ return sp & ~0xf;
+}
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 00/10] PowerPC address space randomisation
The following set of patches adds randomisation of mmaps, heap and position independent executables, and increases the randomisation applied to the stack on 64bit binaries. -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 08/10] powerpc: Ensure random space between stack and mmaps
get_random_int() returns the same value within a 1 jiffy interval. This means
that the mmap and stack regions will almost always end up the same distance
apart, making a relative offset based attack possible.
To fix this, shift the randomness we use for the mmap region by 1 bit.
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/mm/mmap.c
===
--- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-22 11:58:54.0
+1100
+++ linux-2.6/arch/powerpc/mm/mmap.c2009-02-22 12:05:01.0 +1100
@@ -46,6 +46,14 @@
return sysctl_legacy_va_layout;
}
+/*
+ * Since get_random_int() returns the same value within a 1 jiffy window,
+ * we will almost always get the same randomisation for the stack and mmap
+ * region. This will mean the relative distance between stack and mmap will
+ * be the same.
+ *
+ * To avoid this we can shift the randomness by 1 bit.
+ */
static unsigned long mmap_rnd(void)
{
unsigned long rnd = 0;
@@ -53,11 +61,11 @@
if (current->flags & PF_RANDOMIZE) {
/* 8MB for 32bit, 1GB for 64bit */
if (is_32bit_task())
- rnd = (long)(get_random_int() % (1<<(23-PAGE_SHIFT)));
+ rnd = (long)(get_random_int() % (1<<(22-PAGE_SHIFT)));
else
- rnd = (long)(get_random_int() % (1<<(30-PAGE_SHIFT)));
+ rnd = (long)(get_random_int() % (1<<(29-PAGE_SHIFT)));
}
- return rnd << PAGE_SHIFT;
+ return (rnd << PAGE_SHIFT) * 2;
}
static inline unsigned long mmap_base(void)
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 02/10] powerpc: Use new layout for 64bit binaries
We currently place mmaps just below the stack on 32bit, but leave them
in the middle of the address space on 64bit:
0010-0012 r-xp 0010 00:00 0[vdso]
1000-1001 r-xp 08:06 179534 /tmp/sleep
1001-1002 rw-p 08:06 179534 /tmp/sleep
1002-1013 rw-p 1002 00:00 0[heap]
400-403 r-xp 08:06 440743 /lib64/ld-2.9.so
403-404 rw-p 0002 08:06 440743 /lib64/ld-2.9.so
405-41f r-xp 08:06 440671 /lib64/libc-2.9.so
41f-420 r--p 0019 08:06 440671 /lib64/libc-2.9.so
420-422 rw-p 001a 08:06 440671 /lib64/libc-2.9.so
422-4000823 rw-p 422 00:00 0
fbc-fd1 rw-p feb 00:00 0 [stack]
Right now it isn't an issue, but at some stage we will run into mmap or
hugetlb allocation issues. Using the same layout as 32bit gives us a
some breathing room. This matches what x86-64 is doing too.
0010-00103000 r-xp 0010 00:00 0[vdso]
1000-10001000 r-xp 08:06 554894 /tmp/test
1001-10011000 r--p 08:06 554894 /tmp/test
10011000-10012000 rw-p 1000 08:06 554894 /tmp/test
10012000-10113000 rw-p 10012000 00:00 0[heap]
fffefdf7000-7df8000 rw-p fffefdf7000 00:00 0
7df8000-7f97000 r-xp 08:06 130591 /lib64/libc-2.9.so
7f97000-7fa6000 ---p 0019f000 08:06 130591 /lib64/libc-2.9.so
7fa6000-7faa000 r--p 0019e000 08:06 130591 /lib64/libc-2.9.so
7faa000-7fc rw-p 001a2000 08:06 130591 /lib64/libc-2.9.so
7fc-7fc4000 rw-p 7fc 00:00 0
7fc4000-7fec000 r-xp 08:06 130663 /lib64/ld-2.9.so
7fee000-7ff rw-p 7fee000 00:00 0
7ffa000-7ffb000 rw-p 7ffa000 00:00 0
7ffb000-7ffc000 r--p 00027000 08:06 130663 /lib64/ld-2.9.so
7ffc000-7fff000 rw-p 00028000 08:06 130663 /lib64/ld-2.9.so
7fff000-800 rw-p 7fff000 00:00 0
fc59000-fc6e000 rw-p ffeb000 00:00 0 [stack]
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/mm/mmap.c
===
--- linux-2.6.orig/arch/powerpc/mm/mmap.c 2009-02-20 13:39:05.0
+1100
+++ linux-2.6/arch/powerpc/mm/mmap.c2009-02-20 13:40:26.0 +1100
@@ -48,12 +48,6 @@
static inline int mmap_is_legacy(void)
{
- /*
-* Force standard allocation for 64 bit programs.
-*/
- if (!test_thread_flag(TIF_32BIT))
- return 1;
-
if (current->personality & ADDR_COMPAT_LAYOUT)
return 1;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 05/10] powerpc: More stack randomisation for 64bit binaries
At the moment we randomise the stack by 8MB on 32bit and 64bit tasks. Since we
have a lot more address space to play with on 64bit, lets do what x86 does and
increase that randomisation to 1GB:
before:
# for i in seq `1 10` ; do sleep 1 & cat /proc/${!}/maps | grep stack; done
febc000-fed1000 rw-p ffeb000 00:00 0 [stack]
ff5a000-ff6f000 rw-p ffeb000 00:00 0 [stack]
fdb2000-fdc7000 rw-p ffeb000 00:00 0 [stack]
fd3e000-fd53000 rw-p ffeb000 00:00 0 [stack]
fad9000-faee000 rw-p ffeb000 00:00 0 [stack]
after:
# for i in seq `1 10` ; do sleep 1 & cat /proc/${!}/maps | grep stack; done
5c27000-5c3c000 rw-p ffeb000 00:00 0 [stack]
fffebe5e000-fffebe73000 rw-p ffeb000 00:00 0 [stack]
fffcb298000-fffcb2ad000 rw-p ffeb000 00:00 0 [stack]
fffc719d000-fffc71b2000 rw-p ffeb000 00:00 0 [stack]
fffe01af000-fffe01c4000 rw-p ffeb000 00:00 0 [stack]
Signed-off-by: Anton Blanchard
---
Index: linux-2.6/arch/powerpc/include/asm/elf.h
===
--- linux-2.6.orig/arch/powerpc/include/asm/elf.h 2009-02-20
13:39:05.0 +1100
+++ linux-2.6/arch/powerpc/include/asm/elf.h2009-02-20 13:51:20.0
+1100
@@ -270,6 +270,11 @@
int uses_interp);
#define VDSO_AUX_ENT(a,b) NEW_AUX_ENT(a,b);
+/* 1GB for 64bit, 8MB for 32bit */
+#define STACK_RND_MASK (is_32bit_task() ? \
+ (0x7ff >> (PAGE_SHIFT - 12)) : \
+ (0x3 >> (PAGE_SHIFT - 12)))
+
#endif /* __KERNEL__ */
/*
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: CPU hotplug /sys entries are missing on 2.6.28 [PATCH]
On Wed, 18 Feb 2009 22:18:21 +0100
Giuliano Pochini wrote:
> /sys/devices/system/cpu/cpu*/online don't exist anymore.
I think I found the bug. Is this patch ok ?
Signed-off-by: Giuliano Pochini
--- linux-2.6.29-rc5/arch/powerpc/platforms/powermac/setup.c__orig
2009-02-14 00:31:30.0 +0100
+++ linux-2.6.29-rc5/arch/powerpc/platforms/powermac/setup.c2009-02-21
22:44:14.0 +0100
@@ -746,4 +746,7 @@ define_machine(powermac) {
#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PPC64)
.cpu_die= pmac_cpu_die,
#endif
+#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PPC32)
+ .cpu_die= generic_mach_cpu_die,
+#endif
};
--
Giuliano.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Lock-up on PPC64
On Sun, 2009-02-22 at 11:35 +0300, malc wrote: > After writing valgrind tool that was simulating Cell XER.SO syscall > (mis)behaviour (pre ab598b6680f1e74c267d1547ee352f3e1e530f89 that is) > and banging my had against the wall for a while trying to figure out > which of the failing syscalls was responsible, i've tried to be simple > and after only ~30 minutes came up with this, rather short, piece of > code that knocks pre XER.SO patched kernels out cold: > > gcc -o xer -x assembler /dev/stdin -nostdlib < .globl _start > _start: > addis 0,0,0x8000 > mtxer 0 > addi 0,0,1 > sc Allright, but the XER patch fixes it... interesting. Oh well, I'll try to figure out at some stage where we get something wrong in those old kernels. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Can not get "new" MPC8313e-RDB to boot "as-shipped" flash image
Hello, This is getting frustrating and I am beginning to think someone messed this board up and returned it. I would think it would boot up the default flash image out of the box with very little trouble. Board is a MPC8313e-RDB Rev A4. I set the dip switches per the instructions, S4 all off and S3 all on. Uboot comes up but I can not boot either the default images in the flash or images I built with ltib and tftped. I did not touch the flash. I get WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND and ERROR: /chosen node create failed - must RESET the board to recover. The board resets. A friend has the same board but his U-Boot is Version 1.3.0 (Jun 19 2008 - 13:41:53) MPC83XX and some environment variables are different. I do not have the BOOTCMD variable but entered it manually. I tried searching for on a solution but it is confusing because if aliases are needed why does the default dtb in the flash omit them? This is what happens: U-Boot 1.3.3 (Dec 8 2008 - 09:51:15) MPC83XX Reset Status: CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz Board: Freescale MPC8313ERDB I2C: ready DRAM: 128 MB FLASH: 8 MB In:serial Out: serial Err: serial Net: TSEC0, TSEC1 [PRIME] => bootm fe10 fe30 fe70 ## Booting kernel from Legacy Image at fe10 ... Image Name: Linux-2.6.20 Created: 2007-08-24 14:59:01 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1722821 Bytes = 1.6 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Flattened Device Tree blob at fe70 Booting using the fdt blob at 0xfe70 ## Loading init Ramdisk from Legacy Image at fe30 ... Image Name: uboot ext2 ramdisk rootfs Created: 2007-08-24 15:01:41 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:2831355 Bytes = 2.7 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Device Tree to 007fd000, end 007f ... OK WARNING: could not set linux,stdout-path FDT_ERR_NOTFOUND. ERROR: /chosen node create failed - must RESET the board to recover. Resetting the board. U-Boot 1.3.3 (Dec 8 2008 - 09:51:15) MPC83XX Reset Status: Software Hard, External/Internal Soft, External/Internal Hard CPU: e300c3, MPC8313E, Rev: 1.0 at 333.333 MHz, CSB: 166.666 MHz Board: Freescale MPC8313ERDB I2C: ready DRAM: 128 MB FLASH: 8 MB In:serial Out: serial Err: serial Net: TSEC0, TSEC1 [PRIME] => 73 Eric ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Wire up /proc/vmallocinfo to our ioremap()
This adds the necessary bits and pieces to powerpc implementation of
ioremap to benefit from caller tracking in /proc/vmallocinfo, at least
for ioremap's done after mem init as the older ones aren't tracked.
Signed-off-by: Benjamin Herrenschmidt
---
arch/powerpc/include/asm/io.h|6 ++
arch/powerpc/include/asm/machdep.h |2 +-
arch/powerpc/mm/pgtable_32.c | 14 +++---
arch/powerpc/mm/pgtable_64.c | 25 +
arch/powerpc/platforms/cell/io-workarounds.c |4 ++--
arch/powerpc/platforms/iseries/setup.c |2 +-
6 files changed, 38 insertions(+), 15 deletions(-)
--- linux-work.orig/arch/powerpc/include/asm/io.h 2009-02-04
15:37:43.0 +1100
+++ linux-work/arch/powerpc/include/asm/io.h2009-02-04 15:38:30.0
+1100
@@ -632,6 +632,9 @@ static inline void iosync(void)
* ioremap_flags and cannot be hooked (but can be used by a hook on one
* of the previous ones)
*
+ * * __ioremap_caller is the same as above but takes an explicit caller
+ * reference rather than using __builtin_return_address(0)
+ *
* * __iounmap, is the low level implementation used by iounmap and cannot
* be hooked (but can be used by a hook on iounmap)
*
@@ -646,6 +649,9 @@ extern void iounmap(volatile void __iome
extern void __iomem *__ioremap(phys_addr_t, unsigned long size,
unsigned long flags);
+extern void __iomem *__ioremap_caller(phys_addr_t, unsigned long size,
+ unsigned long flags, void *caller);
+
extern void __iounmap(volatile void __iomem *addr);
extern void __iomem * __ioremap_at(phys_addr_t pa, void *ea,
Index: linux-work/arch/powerpc/include/asm/machdep.h
===
--- linux-work.orig/arch/powerpc/include/asm/machdep.h 2009-02-04
15:35:20.0 +1100
+++ linux-work/arch/powerpc/include/asm/machdep.h 2009-02-04
15:35:25.0 +1100
@@ -90,7 +90,7 @@ struct machdep_calls {
void(*tce_flush)(struct iommu_table *tbl);
void __iomem * (*ioremap)(phys_addr_t addr, unsigned long size,
- unsigned long flags);
+ unsigned long flags, void *caller);
void(*iounmap)(volatile void __iomem *token);
#ifdef CONFIG_PM
Index: linux-work/arch/powerpc/mm/pgtable_32.c
===
--- linux-work.orig/arch/powerpc/mm/pgtable_32.c2009-02-04
15:40:22.0 +1100
+++ linux-work/arch/powerpc/mm/pgtable_32.c 2009-02-04 15:41:43.0
+1100
@@ -129,7 +129,8 @@ pgtable_t pte_alloc_one(struct mm_struct
void __iomem *
ioremap(phys_addr_t addr, unsigned long size)
{
- return __ioremap(addr, size, _PAGE_NO_CACHE | _PAGE_GUARDED);
+ return __ioremap_caller(addr, size, _PAGE_NO_CACHE | _PAGE_GUARDED,
+ __builtin_return_address(0));
}
EXPORT_SYMBOL(ioremap);
@@ -143,13 +144,20 @@ ioremap_flags(phys_addr_t addr, unsigned
/* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */
flags &= ~(_PAGE_USER | _PAGE_EXEC | _PAGE_HWEXEC);
- return __ioremap(addr, size, flags);
+ return __ioremap_caller(addr, size, flags, __builtin_return_address(0));
}
EXPORT_SYMBOL(ioremap_flags);
void __iomem *
__ioremap(phys_addr_t addr, unsigned long size, unsigned long flags)
{
+ return __ioremap_caller(addr, size, flags, __builtin_return_address(0));
+}
+
+void __iomem *
+__ioremap_caller(phys_addr_t addr, unsigned long size, unsigned long flags,
+void *caller)
+{
unsigned long v, i;
phys_addr_t p;
int err;
@@ -212,7 +220,7 @@ __ioremap(phys_addr_t addr, unsigned lon
if (mem_init_done) {
struct vm_struct *area;
- area = get_vm_area(size, VM_IOREMAP);
+ area = get_vm_area_caller(size, VM_IOREMAP, caller);
if (area == 0)
return NULL;
v = (unsigned long) area->addr;
Index: linux-work/arch/powerpc/mm/pgtable_64.c
===
--- linux-work.orig/arch/powerpc/mm/pgtable_64.c2009-02-04
15:31:20.0 +1100
+++ linux-work/arch/powerpc/mm/pgtable_64.c 2009-02-04 15:50:54.0
+1100
@@ -144,8 +144,8 @@ void __iounmap_at(void *ea, unsigned lon
unmap_kernel_range((unsigned long)ea, size);
}
-void __iomem * __ioremap(phys_addr_t addr, unsigned long size,
-unsigned long flags)
+void __iomem * __ioremap_caller(phys_addr_t addr, unsigned long size,
+ unsigned long flags, void *caller)
{
phys_addr_t paligned;
void __iomem *ret;
@@ -168,8 +168,9 @@ void __iomem * __ioremap(phys_addr_t add
if (mem_init
[PATCH 1/2] Deindentify identify_cpu()
The for-loop body of identify_cpu() has gotten a little big, so move the
loop body logic into a separate function. No other changes.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/cputable.c | 122 +---
1 files changed, 64 insertions(+), 58 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 923f87a..944bd01 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1762,74 +1762,80 @@ static struct cpu_spec __initdata cpu_specs[] = {
static struct cpu_spec the_cpu_spec;
-struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)
+static void __init setup_cpu_spec(unsigned long offset, struct cpu_spec *s)
{
- struct cpu_spec *s = cpu_specs;
struct cpu_spec *t = &the_cpu_spec;
- int i;
-
- s = PTRRELOC(s);
t = PTRRELOC(t);
- for (i = 0; i < ARRAY_SIZE(cpu_specs); i++,s++)
- if ((pvr & s->pvr_mask) == s->pvr_value) {
- /*
-* If we are overriding a previous value derived
-* from the real PVR with a new value obtained
-* using a logical PVR value, don't modify the
-* performance monitor fields.
-*/
- if (t->num_pmcs && !s->num_pmcs) {
- t->cpu_name = s->cpu_name;
- t->cpu_features = s->cpu_features;
- t->cpu_user_features = s->cpu_user_features;
- t->icache_bsize = s->icache_bsize;
- t->dcache_bsize = s->dcache_bsize;
- t->cpu_setup = s->cpu_setup;
- t->cpu_restore = s->cpu_restore;
- t->platform = s->platform;
- /*
-* If we have passed through this logic once
-* before and have pulled the default case
-* because the real PVR was not found inside
-* cpu_specs[], then we are possibly running in
-* compatibility mode. In that case, let the
-* oprofiler know which set of compatibility
-* counters to pull from by making sure the
-* oprofile_cpu_type string is set to that of
-* compatibility mode. If the oprofile_cpu_type
-* already has a value, then we are possibly
-* overriding a real PVR with a logical one,
and,
-* in that case, keep the current value for
-* oprofile_cpu_type.
-*/
- if (t->oprofile_cpu_type == NULL)
- t->oprofile_cpu_type =
s->oprofile_cpu_type;
- } else
- *t = *s;
- *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
+ /*
+* If we are overriding a previous value derived from the real
+* PVR with a new value obtained using a logical PVR value,
+* don't modify the performance monitor fields.
+*/
+ if (t->num_pmcs && !s->num_pmcs) {
+ t->cpu_name = s->cpu_name;
+ t->cpu_features = s->cpu_features;
+ t->cpu_user_features = s->cpu_user_features;
+ t->icache_bsize = s->icache_bsize;
+ t->dcache_bsize = s->dcache_bsize;
+ t->cpu_setup = s->cpu_setup;
+ t->cpu_restore = s->cpu_restore;
+ t->platform = s->platform;
+ /*
+* If we have passed through this logic once before and
+* have pulled the default case because the real PVR was
+* not found inside cpu_specs[], then we are possibly
+* running in compatibility mode. In that case, let the
+* oprofiler know which set of compatibility counters to
+* pull from by making sure the oprofile_cpu_type string
+* is set to that of compatibility mode. If the
+* oprofile_cpu_type already has a value, then we are
+* possibly overriding a real PVR with a logical one,
+* and, in that case, keep the current value for
+* oprofile_cpu_type.
+*/
+ if (t->oprofile_cpu_type == NULL)
+ t->oprofile_cpu_type = s->oprofile_cpu_type;
+ } else
+ *t = *s;
+
+ *PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
- /*
-* Set the base pla
[PATCH 2/2] Make sure we copy all cpu_spec features except PMC related ones
When identify_cpu() is called a second time with a logical PVR, it
only copies a subset of the cpu_spec fields so as to avoid overwriting
the performance monitor fields that were initialized based on the
real PVR.
However some of the other, non performance monitor related fields are
also not copied:
* pvr_mask
* pvr_value
* mmu_features
* machine_check
The fact that pvr_mask is not copied can result in show_cpuinfo()
showing the cpu as "unknown", if we override an unknown PVR with a
logical one - as reported by Shaggy.
So change the logic to copy all fields, and then put back the PMC
related ones in the case that we're overwriting a real PVR with a
logical one.
Signed-off-by: Michael Ellerman
---
arch/powerpc/kernel/cputable.c | 28
1 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 944bd01..77febd3 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1765,22 +1765,27 @@ static struct cpu_spec the_cpu_spec;
static void __init setup_cpu_spec(unsigned long offset, struct cpu_spec *s)
{
struct cpu_spec *t = &the_cpu_spec;
+ struct cpu_spec old;
+
t = PTRRELOC(t);
+ old = *t;
+
+ /* Copy everything, then do fixups */
+ *t = *s;
/*
* If we are overriding a previous value derived from the real
* PVR with a new value obtained using a logical PVR value,
* don't modify the performance monitor fields.
*/
- if (t->num_pmcs && !s->num_pmcs) {
- t->cpu_name = s->cpu_name;
- t->cpu_features = s->cpu_features;
- t->cpu_user_features = s->cpu_user_features;
- t->icache_bsize = s->icache_bsize;
- t->dcache_bsize = s->dcache_bsize;
- t->cpu_setup = s->cpu_setup;
- t->cpu_restore = s->cpu_restore;
- t->platform = s->platform;
+ if (old.num_pmcs && !s->num_pmcs) {
+ t->num_pmcs = old.num_pmcs;
+ t->pmc_type = old.pmc_type;
+ t->oprofile_type = old.oprofile_type;
+ t->oprofile_mmcra_sihv = old.oprofile_mmcra_sihv;
+ t->oprofile_mmcra_sipr = old.oprofile_mmcra_sipr;
+ t->oprofile_mmcra_clear = old.oprofile_mmcra_clear;
+
/*
* If we have passed through this logic once before and
* have pulled the default case because the real PVR was
@@ -1794,10 +1799,9 @@ static void __init setup_cpu_spec(unsigned long offset,
struct cpu_spec *s)
* and, in that case, keep the current value for
* oprofile_cpu_type.
*/
- if (t->oprofile_cpu_type == NULL)
+ if (old.oprofile_cpu_type == NULL)
t->oprofile_cpu_type = s->oprofile_cpu_type;
- } else
- *t = *s;
+ }
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 01/13] sdhci: Add quirk for controllers with no end-of-busy IRQ
On Sat, Feb 21, 2009 at 05:05:04PM +0100, Pierre Ossman wrote: > On Fri, 20 Feb 2009 20:33:08 +0300 > Anton Vorontsov wrote: > > > From: Ben Dooks > > > > The Samsung SDHCI (and FSL eSDHC) controller block seems to fail > > to generate an INT_DATA_END after the transfer has completed and > > the bus busy state finished. > > > > Changes in e809517f6fa5803a5a1cd56026f0e2190fc13d5c to use the > > new busy method are the cause of the behaviour change. > > > > Signed-off-by: Ben Dooks > > Signed-off-by: Anton Vorontsov > > --- > > Any objections to me merging this right away? It is needed for another > controller. none from me. sorry about the delay, moving servers. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Add support for using doorbells for SMP IPI
On Thu, 2009-02-12 at 17:54 -0600, Kumar Gala wrote:
> The e500mc supports the new msgsnd/doorbell mechanisms that were added in
> the Power ISA 2.05 architecture. We use the normal level doorbell for
> doing SMP IPIs at this point.
Any reason why you don't use the tag ? I'm not too familiar with the
doorbell stuff just yet but can't you use that instead of doing those
atomics ?
On thing we also need to look at is change our low level msg send to
take a CPU mask.
This will be better generically and we need a good cpu mask based IPI
for the TLB stuff anyway. Volunteer ? :-)
Cheers,
Ben.
> Signed-off-by: Kumar Gala
> ---
> arch/powerpc/include/asm/cputable.h |4 ++-
> arch/powerpc/include/asm/dbell.h | 43 +
> arch/powerpc/kernel/Makefile |2 +-
> arch/powerpc/kernel/dbell.c | 44
> ++
> arch/powerpc/kernel/head_fsl_booke.S |6 -
> arch/powerpc/kernel/traps.c | 21
> 6 files changed, 117 insertions(+), 3 deletions(-)
> create mode 100644 arch/powerpc/include/asm/dbell.h
> create mode 100644 arch/powerpc/kernel/dbell.c
>
> diff --git a/arch/powerpc/include/asm/cputable.h
> b/arch/powerpc/include/asm/cputable.h
> index 4911104..fca1611 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -145,6 +145,7 @@ extern const char *powerpc_base_platform;
> #define CPU_FTR_USE_TB ASM_CONST(0x0040)
> #define CPU_FTR_L2CSRASM_CONST(0x0080)
> #define CPU_FTR_601 ASM_CONST(0x0100)
> +#define CPU_FTR_DBELLASM_CONST(0x0200)
> #define CPU_FTR_CAN_NAP ASM_CONST(0x0400)
> #define CPU_FTR_L3CR ASM_CONST(0x0800)
> #define CPU_FTR_L3_DISABLE_NAP ASM_CONST(0x1000)
> @@ -373,7 +374,8 @@ extern const char *powerpc_base_platform;
> CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
> #define CPU_FTRS_E500MC (CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | \
> CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_NODSISRALIGN | \
> - CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE)
> + CPU_FTR_L2CSR | CPU_FTR_LWSYNC | CPU_FTR_NOEXECUTE | \
> + CPU_FTR_DBELL)
> #define CPU_FTRS_GENERIC_32 (CPU_FTR_COMMON | CPU_FTR_NODSISRALIGN)
>
> /* 64-bit CPUs */
> diff --git a/arch/powerpc/include/asm/dbell.h
> b/arch/powerpc/include/asm/dbell.h
> new file mode 100644
> index 000..501189a
> --- /dev/null
> +++ b/arch/powerpc/include/asm/dbell.h
> @@ -0,0 +1,43 @@
> +/*
> + * Copyright 2009 Freescale Semicondutor, Inc.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version
> + * 2 of the License, or (at your option) any later version.
> + *
> + * provides masks and opcode images for use by code generation, emulation
> + * and for instructions that older assemblers might not know about
> + */
> +#ifndef _ASM_POWERPC_DBELL_H
> +#define _ASM_POWERPC_DBELL_H
> +
> +#include
> +#include
> +
> +#include
> +
> +#define PPC_DBELL_MSG_BRDCAST(0x0400)
> +#define PPC_DBELL_TYPE(x)(((x) & 0xf) << 28)
> +enum ppc_dbell {
> + PPC_DBELL = 0, /* doorbell */
> + PPC_DBELL_CRIT = 1, /* critical doorbell */
> + PPC_G_DBELL = 2,/* guest doorbell */
> + PPC_G_DBELL_CRIT = 3, /* guest critical doorbell */
> + PPC_G_DBELL_MC = 4, /* guest mcheck doorbell */
> +};
> +
> +#ifdef CONFIG_SMP
> +extern unsigned long dbell_smp_message[NR_CPUS];
> +extern void smp_dbell_message_pass(int target, int msg);
> +#endif
> +
> +static inline void ppc_msgsnd(enum ppc_dbell type, u32 flags, u32 tag)
> +{
> + u32 msg = PPC_DBELL_TYPE(type) | (flags & PPC_DBELL_MSG_BRDCAST) |
> + (tag & 0x07ff);
> +
> + __asm__ __volatile__ (PPC_MSGSND(%0) : : "r" (msg));
> +}
> +
> +#endif /* _ASM_POWERPC_DBELL_H */
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index d159921..f420844 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -61,7 +61,7 @@ obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o \
> obj64-$(CONFIG_HIBERNATION) += swsusp_asm64.o
> obj-$(CONFIG_MODULES)+= module.o module_$(CONFIG_WORD_SIZE).o
> obj-$(CONFIG_44x)+= cpu_setup_44x.o
> -obj-$(CONFIG_FSL_BOOKE) += cpu_setup_fsl_booke.o
> +obj-$(CONFIG_FSL_BOOKE) += cpu_setup_fsl_booke.o dbell.o
>
> extra-$(CONFIG_PPC_STD_MMU) := head_32.o
> extra-$(CONFIG_PPC64):= head_64.o
> diff --git a/arch/powerpc/kernel/dbell.c b/arch/powerpc/kernel/dbell.c
> new file mode 100644
> index 000..1493734
> --- /dev/null
> +++ b/ar
powerpc 4xx power-management feature
I have a AMCC Kilauea board and I want to use linux power-management feature on it. But it seems that there's no power-management codes for the powerpc 4xx series. I think the device-tree source for the Kilauea should be modified first. Is there anyone who has tried it before? Please help me. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/PATCH] powerpc: provide APIs for validating and updating DABR
> +/* for reprogramming DABR/DAC during restart of a checkpointed task */ > +extern bool debugreg_valid(unsigned long val); > +extern void debugreg_update(struct task_struct *task, unsigned long val); > + Please keep the "index" here. We may want to add support for IABR, and there is some WIP to add support for multiple DACs and IACs on BookE processors. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch] powerpc: estimate G5 cpufreq transition latency
On Thu, 2009-02-19 at 18:07 +0100, Nick Piggin wrote:
> Setting G5's cpu frequency transition latency to CPUFREQ_ETERNAL stops
> ondemand governor from working. I measured the latency using sched_clock
> and haven't seen much higher than 11000ns, so I set this to 12000ns for
> my configuration. Possibly other configurations will be different?
> Ideally the generic code would be able to measure it in case the platform
> does not provide it.
>
> But this simple patch at least makes it throttle again.
>
> Signed-off-by: Nick Piggin
> ---
Oh well, I've never used ondemand but some userspace stuff instead :-)
No objection appart from the change to drivers/cpufreq/cpufreq.c which
should be in a separate patch to whoever maintains that code :-)
Cheers,
Ben.
> Index: linux-2.6/arch/powerpc/platforms/powermac/cpufreq_64.c
> ===
> --- linux-2.6.orig/arch/powerpc/platforms/powermac/cpufreq_64.c
> 2009-02-20 01:42:41.0 +1100
> +++ linux-2.6/arch/powerpc/platforms/powermac/cpufreq_64.c2009-02-20
> 01:50:15.0 +1100
> @@ -86,6 +86,7 @@
>
> static DEFINE_MUTEX(g5_switch_mutex);
>
> +static unsigned long transition_latency;
>
> #ifdef CONFIG_PMAC_SMU
>
> @@ -357,7 +358,7 @@
>
> static int g5_cpufreq_cpu_init(struct cpufreq_policy *policy)
> {
> - policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL;
> + policy->cpuinfo.transition_latency = transition_latency;
> policy->cur = g5_cpu_freqs[g5_query_freq()].frequency;
> /* secondary CPUs are tied to the primary one by the
>* cpufreq core if in the secondary policy we tell it that
> @@ -500,6 +501,7 @@
> g5_cpu_freqs[1].frequency = max_freq/2;
>
> /* Set callbacks */
> + transition_latency = 12000;
> g5_switch_freq = g5_scom_switch_freq;
> g5_query_freq = g5_scom_query_freq;
> freq_method = "SCOM";
> @@ -675,6 +677,7 @@
> g5_cpu_freqs[1].frequency = min_freq;
>
> /* Set callbacks */
> + transition_latency = CPUFREQ_ETERNAL;
> g5_switch_volt = g5_pfunc_switch_volt;
> g5_switch_freq = g5_pfunc_switch_freq;
> g5_query_freq = g5_pfunc_query_freq;
> Index: linux-2.6/drivers/cpufreq/cpufreq.c
> ===
> --- linux-2.6.orig/drivers/cpufreq/cpufreq.c 2009-02-20 01:42:43.0
> +1100
> +++ linux-2.6/drivers/cpufreq/cpufreq.c 2009-02-20 01:50:15.0
> +1100
> @@ -1559,9 +1559,11 @@
> else {
> printk(KERN_WARNING "%s governor failed, too long"
> " transition latency of HW, fallback"
> -" to %s governor\n",
> +" to %s governor (latency=%lld max=%lld)\n",
> policy->governor->name,
> -gov->name);
> +gov->name,
> +policy->cpuinfo.transition_latency,
> +policy->governor->max_transition_latency);
> policy->governor = gov;
> }
> }
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Newby trying to get Ethernet going on MPC83xx series device.
> -Original Message- > From: linuxppc-dev-bounces+dusharaj=optiscan@ozlabs.org > [mailto:linuxppc-dev-bounces+dusharaj=optiscan@ozlabs.org] On > Behalf Of Dushara Jayasinghe > Sent: Friday, 20 February 2009 6:18 PM > To: 'Michael Bergandi' > Cc: linuxppc-dev@ozlabs.org; Aggrwal Poonam-B10812; Timur Tabi > Subject: RE: Newby trying to get Ethernet going on MPC83xx series > device. Hi all, I've solved this issue. I was passing the wrong .dtb file to the kernel. Sorry for adding noise the list. Thanks again for all you help. D ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Problem with decrementer interrupt
In the handler for decrementer interrupt...there is a call to a C function... Now if the call is removed...the decrementer interrupt works perfectly fine... But if the C function is present, then the decrementer interrupt stops coming after say 5-6 times... Not able to find any reasoning for the same... Has anyone come across this kind of problem?If yes, am i missing something? Regards, Sumedh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PowerPC 7447A Paging table Search
Thanks a lot...Its working now... Regards, Sumedh On Thu, Feb 12, 2009 at 7:28 PM, Kumar Gala wrote: > > On Feb 12, 2009, at 3:59 AM, sumedh tirodkar wrote: > >> How will i confirm if PowerPC 7447A processor has or does not have a >> dedicated hardware for page table search algorithm? >> If it does not have, then which interrupt handler is written for page >> address translation mechanism? > > It has one and linux uses it. > > - k > ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
