[RFC][PATCH] powerpc: Use the #address-cells information to parse memory/reg
Use the #address-cells, #size-cells information to parse the memory/reg info
from device tree.
The format of memory/reg is based on the #address-cells,#size-cells. Currently,
the kexec-tools doesn't use the above values in parsing the memory/reg values.
Hence the kexec cannot handle cases where #address-cells, #size-cells are
different, (for e.g, PPC440X ).
This patch introduces a read_memory_region_limits(), which parses the
memory/reg contents based on the values of #address-cells and #size-cells.
Changed the add_usable_mem_property() to accept FILE* fp instead of int fd,
as most of the other users of read_memory_region_limits() deals with FILE*.
Signed-off-by: Suzuki K. Poulose
---
kexec/arch/ppc/crashdump-powerpc.c | 23 --
kexec/arch/ppc/fs2dt.c | 31 ++--
kexec/arch/ppc/kexec-ppc.c | 136 ++---
kexec/arch/ppc/kexec-ppc.h |6 +
4 files changed, 118 insertions(+), 78 deletions(-)
Index: kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
===
--- kexec-tools-2.0.4.orig/kexec/arch/ppc/kexec-ppc.c
+++ kexec-tools-2.0.4/kexec/arch/ppc/kexec-ppc.c
@@ -26,6 +26,7 @@
#include "config.h"
+unsigned long dt_address_cells = 0, dt_size_cells = 0;
uint64_t rmo_top;
unsigned long long crash_base = 0, crash_size = 0;
unsigned long long initrd_base = 0, initrd_size = 0;
@@ -34,6 +35,92 @@ unsigned int rtas_base, rtas_size;
int max_memory_ranges;
const char *ramdisk;
+/*
+ * Reads the #address-cells and #size-cells on this platform.
+ * This is used to parse the memory/reg info from the device-tree
+ */
+int init_memory_region_info()
+{
+ size_t res = 0;
+ FILE *fp;
+ char *file;
+
+ file = "/proc/device-tree/#address-cells";
+ fp = fopen(file, "r");
+ if (!fp) {
+ fprintf(stderr,"Unable to open %s\n", file);
+ return -1;
+ }
+
+ res = fread(&dt_address_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,"Error reading %s\n", file);
+ return -1;
+ }
+ fclose(fp);
+ dt_address_cells *= sizeof(unsigned long);
+
+ file = "/proc/device-tree/#size-cells";
+ fp = fopen(file, "r");
+ if (!fp) {
+ fprintf(stderr,"Unable to open %s\n", file);
+ return -1;
+ }
+
+ res = fread(&dt_size_cells,sizeof(unsigned long),1,fp);
+ if (res != 1) {
+ fprintf(stderr,"Error reading %s\n", file);
+ return -1;
+ }
+ fclose(fp);
+ dt_size_cells *= sizeof(unsigned long);
+
+ return 0;
+}
+
+#define MAXBYTES 128
+/*
+ * Reads the memory region info from the device-tree node pointed
+ * by @fp and fills the *start, *end with the boundaries of the region
+ */
+int read_memory_region_limits(FILE* fp, unsigned long long *start,
+ unsigned long long *end)
+{
+ char buf[MAXBYTES];
+ unsigned long *p;
+ unsigned long nbytes = dt_address_cells + dt_size_cells;
+
+ if (fread(buf, 1, MAXBYTES, fp) != nbytes) {
+ fprintf(stderr, "Error reading the memory region info\n");
+ return -1;
+ }
+
+ p = (unsigned long*)buf;
+ if (dt_address_cells == sizeof(unsigned long)) {
+ *start = p[0];
+ p++;
+ } else if (dt_address_cells == sizeof(unsigned long long)) {
+ *start = ((unsigned long long *)p)[0];
+ p = (unsigned long long *)p + 1;
+ } else {
+ fprintf(stderr,"Unsupported value for #address-cells : %ld\n",
+ dt_address_cells);
+ return -1;
+ }
+
+ if (dt_size_cells == sizeof(unsigned long))
+ *end = *start + p[0];
+ else if (dt_size_cells == sizeof(unsigned long long))
+ *end = *start + ((unsigned long long *)p)[0];
+ else {
+ fprintf(stderr,"Unsupported value for #size-cells : %ld\n",
+ dt_size_cells);
+ return -1;
+ }
+
+ return 0;
+}
+
void arch_reuse_initrd(void)
{
reuse_initrd = 1;
@@ -182,9 +269,6 @@ static int sort_base_ranges(void)
return 0;
}
-
-#define MAXBYTES 128
-
static int realloc_memory_ranges(void)
{
size_t memory_range_len;
@@ -248,6 +332,8 @@ static int get_base_ranges(void)
return -1;
}
while ((mentry = readdir(dmem)) != NULL) {
+ unsigned long long start, end;
+
if (strcmp(mentry->d_name, "reg"))
continue;
strcat(fname, "/reg");
@@ -257,8 +343,7 @@ static int get_base_ranges(void)
closedir(dir);
return -1;
RE: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 driver
> -Original Message- > From: linuxppc-dev-bounces+priyanka.jain=freescale@lists.ozlabs.org > [mailto:linuxppc-dev- > bounces+priyanka.jain=freescale@lists.ozlabs.org] On Behalf Of > Wolfram Sang > Sent: Thursday, May 26, 2011 2:40 PM > To: Jain Priyanka-B32167 > Cc: a.zu...@towertech.it; a...@linux-foundation.org; linuxppc- > d...@lists.ozlabs.org; rtc-li...@googlegroups.com; p_gortma...@yahoo.com > Subject: Re: [PATCH] Add support for pt7c4338 (rtc device) in rtc-ds1307 > driver > > On Thu, May 26, 2011 at 12:33:29PM +0530, Priyanka Jain wrote: > > > PT7C4338 chip is being manufactured by Pericom Technology Inc. > > It is a serial real-time clock which provides: > > 1)Low-power clock/calendar. > > 2)Programmable square-wave output. > > It has 56 bytes of nonvolatile RAM. > > Its register set is same as that of rtc device: DS1307. > > > > Signed-off-by: Priyanka Jain > > So it is identical to ds1307? Then why not name your platform_device > simply 'ds1307'? Yes, It is possible to directly use platform device 'ds1307' in device tree. But I have one query of how to capture the information that pericom, pt7c4338 device is compatible with dallas, ds1307. Can it be done in somewhere in some document or some code. Actually for pt7c4338 device driver, I actually started by asking if there is any already existing rtc device driver which is compatible with pericom pt7c4338 device on mailing list and as there was no answer or help then, I actually ended up writing device driver for that and then on the suggestion using ds1307 device driver for this. Thanks Priyanka > > Regards, > >Wolfram > > -- > Pengutronix e.K. | Wolfram Sang > | > Industrial Linux Solutions | http://www.pengutronix.de/ > | ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Patch "seqlock: Don't smp_rmb in seqlock reader spin loop" has been added to the 2.6.33-longterm tree
This is a note to let you know that I've just added the patch titled
seqlock: Don't smp_rmb in seqlock reader spin loop
to the 2.6.33-longterm tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.33.git;a=summary
The filename of the patch is:
seqlock-don-t-smp_rmb-in-seqlock-reader-spin-loop.patch
and it can be found in the queue-2.6.33 subdirectory.
If you, or anyone else, feels it should not be added to the 2.6.33 longterm
tree,
please let know about it.
>From 5db1256a5131d3b133946fa02ac9770a784e6eb2 Mon Sep 17 00:00:00 2001
From: Milton Miller
Date: Thu, 12 May 2011 04:13:54 -0500
Subject: seqlock: Don't smp_rmb in seqlock reader spin loop
From: Milton Miller
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller
Cc:
Cc: Linus Torvalds
Cc: Andi Kleen
Cc: Nick Piggin
Cc: Benjamin Herrenschmidt
Cc: Anton Blanchard
Cc: Paul McKenney
Acked-by: Eric Dumazet
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
include/linux/seqlock.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
unsigned ret;
repeat:
- ret = sl->sequence;
- smp_rmb();
+ ret = ACCESS_ONCE(sl->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
+ smp_rmb();
return ret;
}
Patches currently in longterm-queue-2.6.33 which might be from milt...@bga.com
are
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Patch "seqlock: Don't smp_rmb in seqlock reader spin loop" has been added to the 2.6.32-longterm tree
This is a note to let you know that I've just added the patch titled
seqlock: Don't smp_rmb in seqlock reader spin loop
to the 2.6.32-longterm tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/longterm/longterm-queue-2.6.32.git;a=summary
The filename of the patch is:
seqlock-don-t-smp_rmb-in-seqlock-reader-spin-loop.patch
and it can be found in the queue-2.6.32 subdirectory.
If you, or anyone else, feels it should not be added to the 2.6.32 longterm
tree,
please let know about it.
>From 5db1256a5131d3b133946fa02ac9770a784e6eb2 Mon Sep 17 00:00:00 2001
From: Milton Miller
Date: Thu, 12 May 2011 04:13:54 -0500
Subject: seqlock: Don't smp_rmb in seqlock reader spin loop
From: Milton Miller
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller
Cc:
Cc: Linus Torvalds
Cc: Andi Kleen
Cc: Nick Piggin
Cc: Benjamin Herrenschmidt
Cc: Anton Blanchard
Cc: Paul McKenney
Acked-by: Eric Dumazet
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
include/linux/seqlock.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
unsigned ret;
repeat:
- ret = sl->sequence;
- smp_rmb();
+ ret = ACCESS_ONCE(sl->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
+ smp_rmb();
return ret;
}
Patches currently in longterm-queue-2.6.32 which might be from milt...@bga.com
are
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Patch "seqlock: Don't smp_rmb in seqlock reader spin loop" has been added to the 2.6.39-stable tree
This is a note to let you know that I've just added the patch titled
seqlock: Don't smp_rmb in seqlock reader spin loop
to the 2.6.39-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
seqlock-don-t-smp_rmb-in-seqlock-reader-spin-loop.patch
and it can be found in the queue-2.6.39 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 5db1256a5131d3b133946fa02ac9770a784e6eb2 Mon Sep 17 00:00:00 2001
From: Milton Miller
Date: Thu, 12 May 2011 04:13:54 -0500
Subject: seqlock: Don't smp_rmb in seqlock reader spin loop
From: Milton Miller
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller
Cc:
Cc: Linus Torvalds
Cc: Andi Kleen
Cc: Nick Piggin
Cc: Benjamin Herrenschmidt
Cc: Anton Blanchard
Cc: Paul McKenney
Acked-by: Eric Dumazet
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
include/linux/seqlock.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
unsigned ret;
repeat:
- ret = sl->sequence;
- smp_rmb();
+ ret = ACCESS_ONCE(sl->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
+ smp_rmb();
return ret;
}
Patches currently in stable-queue which might be from milt...@bga.com are
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Patch "seqlock: Don't smp_rmb in seqlock reader spin loop" has been added to the 2.6.38-stable tree
This is a note to let you know that I've just added the patch titled
seqlock: Don't smp_rmb in seqlock reader spin loop
to the 2.6.38-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
seqlock-don-t-smp_rmb-in-seqlock-reader-spin-loop.patch
and it can be found in the queue-2.6.38 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let know about it.
>From 5db1256a5131d3b133946fa02ac9770a784e6eb2 Mon Sep 17 00:00:00 2001
From: Milton Miller
Date: Thu, 12 May 2011 04:13:54 -0500
Subject: seqlock: Don't smp_rmb in seqlock reader spin loop
From: Milton Miller
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and return are consistent.
A multi-threaded core in the lab didn't like the update
from 2.6.35 to 2.6.36, to the point it would hang during
boot when multiple threads were active. Bisection showed
af5ab277ded04bd9bc6b048c5a2f0e7d70ef0867 (clockevents:
Remove the per cpu tick skew) as the culprit and it is
supported with stack traces showing xtime_lock waits including
tick_do_update_jiffies64 and/or update_vsyscall.
Experimentation showed the combination of cpu_relax and smp_rmb
was significantly slowing the progress of other threads sharing
the core, and this patch is effective in avoiding the hang.
A theory is the rmb is affecting the whole core while the
cpu_relax is causing a resource rebalance flush, together they
cause an interfernce cadance that is unbroken when the seqlock
reader has interrupts disabled.
At first I was confused why the refactor in
3c22cd5709e8143444a6d08682a87f4c57902df3 (kernel: optimise
seqlock) didn't affect this patch application, but after some
study that affected seqcount not seqlock. The new seqcount was
not factored back into the seqlock. I defer that the future.
While the removal of the timer interrupt offset created
contention for the xtime lock while a cpu does the
additonal work to update the system clock, the seqlock
implementation with the tight rmb spin loop goes back much
further, and is just waiting for the right trigger.
Signed-off-by: Milton Miller
Cc:
Cc: Linus Torvalds
Cc: Andi Kleen
Cc: Nick Piggin
Cc: Benjamin Herrenschmidt
Cc: Anton Blanchard
Cc: Paul McKenney
Acked-by: Eric Dumazet
Link: http://lkml.kernel.org/r/%3Cseqlock-rmb%40mdm.bga.com%3E
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
---
include/linux/seqlock.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/linux/seqlock.h
+++ b/include/linux/seqlock.h
@@ -88,12 +88,12 @@ static __always_inline unsigned read_seq
unsigned ret;
repeat:
- ret = sl->sequence;
- smp_rmb();
+ ret = ACCESS_ONCE(sl->sequence);
if (unlikely(ret & 1)) {
cpu_relax();
goto repeat;
}
+ smp_rmb();
return ret;
}
Patches currently in stable-queue which might be from milt...@bga.com are
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
On Sun, 2011-05-29 at 23:16 +0400, Andrey Gusev wrote: > 28.05.2011 22:09, Tabi Timur-B04825 пишет: > > On Sat, May 28, 2011 at 2:55 AM, Andrey Gusev wrote: > >> Hi! > >> A kernel 2.6.39 doesn't boot on my POWER MAC G4. A kernel 2.6.38.6 with > >> almost the same config boots without any problems. > > Have you tried using git-bisect to isolate the commit that breaks? > > > Fortunately, the rc1 is booted. I made git bisect: > I have errors on building bad kernels: > arch/powerpc/platforms/powermac/smp.c: In function ‘smp_core99_cpu_notify’: > arch/powerpc/platforms/powermac/smp.c:855:7: error: > ‘pmac_tb_clock_chip_host’ undeclared (first use in this function) > arch/powerpc/platforms/powermac/smp.c:855:7: note: each undeclared > identifier is reported only once for each function it appears in This is an SMP machine ? If not, does it work with a UP kernel ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
* Peter Zijlstra wrote: > But face it, you can argue until you're blue in the face, That is not a technical argument though - and i considered and answered every valid technical argument made by you and Thomas. You were either not able to or not willing to counter them. > [...] but both tglx and I will NAK any and all patches that extend > perf/ftrace beyond the passive observing role. The thing is, perf is *already* well beyond the 'passive observer' role: we already generate lots of 'action' in response to events. We generate notification signals, we write events - all of which can (and does) modify program behavior. So what's your point? There's no "passive observer" role really - it's apparently just that you dislike this use of instrumentation while you approve of other uses. Thanks, Ingo ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
28.05.2011 22:09, Tabi Timur-B04825 пишет: On Sat, May 28, 2011 at 2:55 AM, Andrey Gusev wrote: Hi! A kernel 2.6.39 doesn't boot on my POWER MAC G4. A kernel 2.6.38.6 with almost the same config boots without any problems. Have you tried using git-bisect to isolate the commit that breaks? Fortunately, the rc1 is booted. I made git bisect: andrey@power-debian:~/trash/build/kernel/git$ git bisect log # bad: [a6360dd37e1a144ed11e6548371bade559a1e4df] Linux 2.6.39-rc3 # good: [0ce790e7d736cedc563e1fb4e998babf5a4dbc3d] Linux 2.6.39-rc1 git bisect start 'v2.6.39-rc3' 'v2.6.39-rc1' # bad: [d14f5b810b49c7dbd1a01be1c6d3641d46090080] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 git bisect bad d14f5b810b49c7dbd1a01be1c6d3641d46090080 # good: [84daeb09ef2b11cb0b29e100766e38e206c8bc47] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6 git bisect good 84daeb09ef2b11cb0b29e100766e38e206c8bc47 # bad: [fb9a7d76da108d120efb2258ea83b18dbbb2ecdd] Merge branch 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip git bisect bad fb9a7d76da108d120efb2258ea83b18dbbb2ecdd # bad: [ccd00d1091fa7fff151127f26f6900be2ac8cc10] Merge branch 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc git bisect bad ccd00d1091fa7fff151127f26f6900be2ac8cc10 # good: [d72944457bb7d5c4be43aa1b741cb93c69484c20] powerpc/smp: Add a smp_ops->bringup_up() done callback git bisect good d72944457bb7d5c4be43aa1b741cb93c69484c20 # good: [afdef69c7ff7d0bf59e3cafc187aefb12878dbe3] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6 git bisect good afdef69c7ff7d0bf59e3cafc187aefb12878dbe3 # bad: [c56e58537d504706954a06570b4034c04e5b7500] powerpc/smp: Create idle threads on demand and properly reset them git bisect bad c56e58537d504706954a06570b4034c04e5b7500 # bad: [105765f451d3ff007bb4ae3761e825686d9615db] powerpc/smp: Don't expose per-cpu "cpu_state" array git bisect bad 105765f451d3ff007bb4ae3761e825686d9615db # bad: [734796f12351f9a0f38c47b981414f82d852f222] powerpc/pmac/smp: Fix CPU hotplug crashes on some machines git bisect bad 734796f12351f9a0f38c47b981414f82d852f222 I have errors on building bad kernels: arch/powerpc/platforms/powermac/smp.c: In function ‘smp_core99_cpu_notify’: arch/powerpc/platforms/powermac/smp.c:855:7: error: ‘pmac_tb_clock_chip_host’ undeclared (first use in this function) arch/powerpc/platforms/powermac/smp.c:855:7: note: each undeclared identifier is reported only once for each function it appears in Andrey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Mapping an executable page
On Fri, May 27, 2011 at 8:25 AM, Thomas De Schampheleire wrote: > Although I realize that what I need to achieve is unconventional, what > is the correct way of mapping a certain address range into memory, and > be able to execute from it? Have you tried looking at the actual TLB entry for this page to see if it's correct? Also, you might need to do some kind of instruction cache flushing before you jump to that page. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PROBLEM: 2.6.39 doesn't boot on POWER MAC
28.05.2011 22:09, Tabi Timur-B04825 пишет: On Sat, May 28, 2011 at 2:55 AM, Andrey Gusev wrote: Hi! A kernel 2.6.39 doesn't boot on my POWER MAC G4. A kernel 2.6.38.6 with almost the same config boots without any problems. Have you tried using git-bisect to isolate the commit that breaks? I didn't. It takes very long time. If nobody have ideas I will. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
