[PATCH 1/2] powerpc: Add hcall to read 4 ptes at a time in real mode
This adds plpar_pte_read_4_raw() which can be used read 4 PTEs from
PHYP at a time, while in real mode.
It also creates a new hcall9 which can be used in real mode. It's the
same as plpar_hcall9 but minus the tracing hcall statistics which may
require variables outside the RMO.
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/include/asm/hvcall.h |1
arch/powerpc/platforms/pseries/hvCall.S | 38
arch/powerpc/platforms/pseries/plpar_wrappers.h | 18 +++
3 files changed, 57 insertions(+)
Index: linux-2.6-ozlabs/arch/powerpc/include/asm/hvcall.h
===
--- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/hvcall.h
+++ linux-2.6-ozlabs/arch/powerpc/include/asm/hvcall.h
@@ -281,6 +281,7 @@ long plpar_hcall_raw(unsigned long opcod
*/
#define PLPAR_HCALL9_BUFSIZE 9
long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...);
+long plpar_hcall9_raw(unsigned long opcode, unsigned long *retbuf, ...);
/* For hcall instrumentation. One structure per-hcall, per-CPU */
struct hcall_stats {
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hvCall.S
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/hvCall.S
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/hvCall.S
@@ -228,3 +228,41 @@ _GLOBAL(plpar_hcall9)
mtcrf 0xff,r0
blr /* return r3 = status */
+
+/* See plpar_hcall_raw to see why this is needed */
+_GLOBAL(plpar_hcall9_raw)
+ HMT_MEDIUM
+
+ mfcrr0
+ stw r0,8(r1)
+
+ std r4,STK_PARM(r4)(r1) /* Save ret buffer */
+
+ mr r4,r5
+ mr r5,r6
+ mr r6,r7
+ mr r7,r8
+ mr r8,r9
+ mr r9,r10
+ ld r10,STK_PARM(r11)(r1)/* put arg7 in R10 */
+ ld r11,STK_PARM(r12)(r1)/* put arg8 in R11 */
+ ld r12,STK_PARM(r13)(r1)/* put arg9 in R12 */
+
+ HVSC/* invoke the hypervisor */
+
+ mr r0,r12
+ ld r12,STK_PARM(r4)(r1)
+ std r4, 0(r12)
+ std r5, 8(r12)
+ std r6, 16(r12)
+ std r7, 24(r12)
+ std r8, 32(r12)
+ std r9, 40(r12)
+ std r10,48(r12)
+ std r11,56(r12)
+ std r0, 64(r12)
+
+ lwz r0,8(r1)
+ mtcrf 0xff,r0
+
+ blr /* return r3 = status */
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/plpar_wrappers.h
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -191,6 +191,24 @@ static inline long plpar_pte_read_raw(un
return rc;
}
+/*
+ * plpar_pte_read_4_raw can be called in real mode.
+ * ptes must be 8*sizeof(unsigned long)
+ */
+static inline long plpar_pte_read_4_raw(unsigned long flags, unsigned long
ptex,
+ unsigned long *ptes)
+
+{
+ long rc;
+ unsigned long retbuf[PLPAR_HCALL9_BUFSIZE];
+
+ rc = plpar_hcall9_raw(H_READ, retbuf, flags | H_READ_4, ptex);
+
+ memcpy(ptes, retbuf, 8*sizeof(unsigned long));
+
+ return rc;
+}
+
static inline long plpar_pte_protect(unsigned long flags, unsigned long ptex,
unsigned long avpn)
{
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] powerpc,kexec: Speedup kexec hpte tear down
Currently for kexec the PTE tear down on 1TB segment systems normally
requires 3 hcalls for each PTE removal. On a machine with 32GB of
memory it can take around a minute to remove all the PTEs.
This optimises the path so that we only remove PTEs that are valid.
It also uses the read 4 PTEs at once HCALL. For the common case where
a PTEs is invalid in a 1TB segment, this turns the 3 HCALLs per PTE
down to 1 HCALL per 4 PTEs.
This gives an 10x speedup in kexec times on PHYP, taking a 32GB
machine from around 1 minute down to a few seconds.
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/platforms/pseries/lpar.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
@@ -367,21 +367,28 @@ static void pSeries_lpar_hptab_clear(voi
{
unsigned long size_bytes = 1UL ppc64_pft_size;
unsigned long hpte_count = size_bytes 4;
- unsigned long dummy1, dummy2, dword0;
+ struct {
+ unsigned long pteh;
+ unsigned long ptel;
+ } ptes[4];
long lpar_rc;
- int i;
+ int i, j;
- /* TODO: Use bulk call */
- for (i = 0; i hpte_count; i++) {
- /* dont remove HPTEs with VRMA mappings */
- lpar_rc = plpar_pte_remove_raw(H_ANDCOND, i, HPTE_V_1TB_SEG,
- dummy1, dummy2);
- if (lpar_rc == H_NOT_FOUND) {
- lpar_rc = plpar_pte_read_raw(0, i, dword0, dummy1);
- if (!lpar_rc ((dword0 HPTE_V_VRMA_MASK)
- != HPTE_V_VRMA_MASK))
- /* Can be hpte for 1TB Seg. So remove it */
- plpar_pte_remove_raw(0, i, 0, dummy1, dummy2);
+ /* Read in batches of 4,
+* invalidate only valid entries not in the VRMA
+* hpte_count will be a multiple of 4
+ */
+ for (i = 0; i hpte_count; i += 4) {
+ lpar_rc = plpar_pte_read_4_raw(0, i, (void *)ptes);
+ if (lpar_rc != H_SUCCESS)
+ continue;
+ for (j = 0; j 4; j++){
+ if ((ptes[j].pteh HPTE_V_VRMA_MASK) ==
+ HPTE_V_VRMA_MASK)
+ continue;
+ if (ptes[j].pteh HPTE_V_VALID)
+ plpar_pte_remove_raw(0, i + j, 0,
+ (ptes[j].pteh), (ptes[j].ptel));
}
}
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc, kexec: Fix race in kexec shutdown
In kexec_prepare_cpus cpu, the primary CPU IPIs the secondary CPUs to
kexec_smp_down(). kexec_smp_down() calls kexec_smp_wait() which sets
the hw_cpu_id() to -1. The primary does this while leaving IRQs on
which means the primary can take a timer interrupt which can lead to
the primary IPIing one of the secondary CPUs (say, for a scheduler
re-balance) but since the secondary CPU now has a hw_cpu_id = -1, we
IPI CPU -1... Kaboom!
We are hitting this case regularly on POWER7 machines.
Also, the secondaries are clearing out any pending IPIs before
guaranteeing that no more will be received.
This changes kexec_prepare_cpus() so that we turn off IRQs in the
primary CPU much earlier. It adds a paca flag to say that the
secondaries have entered the kexec_smp_down() IPI and turned off IRQs,
rather than overloading hw_cpu_id with -1.
It also ensures that all CPUs have their IRQs off before we clear out
any pending IPI requests (in kexec_cpu_down()) to ensure there are no
trailing IPIs left unacknowledged.
Signed-off-by: Michael Neuling mi...@neuling.org
---
arch/powerpc/include/asm/paca.h|1 +
arch/powerpc/kernel/machine_kexec_64.c | 28
arch/powerpc/kernel/misc_64.S |3 ---
3 files changed, 21 insertions(+), 11 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/include/asm/paca.h
===
--- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/paca.h
+++ linux-2.6-ozlabs/arch/powerpc/include/asm/paca.h
@@ -82,6 +82,7 @@ struct paca_struct {
s16 hw_cpu_id; /* Physical processor number */
u8 cpu_start; /* At startup, processor spins until */
/* this becomes non-zero. */
+ u8 kexec_irqs_off; /* set when kexec down has irqs off */
#ifdef CONFIG_PPC_STD_MMU_64
struct slb_shadow *slb_shadow_ptr;
Index: linux-2.6-ozlabs/arch/powerpc/kernel/machine_kexec_64.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/machine_kexec_64.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/machine_kexec_64.c
@@ -155,16 +155,23 @@ void kexec_copy_flush(struct kimage *ima
#ifdef CONFIG_SMP
-/* FIXME: we should schedule this function to be called on all cpus based
- * on calling the interrupts, but we would like to call it off irq level
- * so that the interrupt controller is clean.
- */
+static int kexec_all_irq_disabled = 0;
+
static void kexec_smp_down(void *arg)
{
+ local_irq_disable();
+ mb(); /* make sure our irqs are disabled before we say they are */
+ get_paca()-kexec_irqs_off = 1;
+ while(kexec_all_irq_disabled == 0)
+ cpu_relax();
+ mb(); /* make sure all irqs are disabled before this */
+ /*
+* Now every CPU has IRQs off, we can clear out any pending
+* IPIs and be sure that no more will come in after this.
+*/
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 1);
- local_irq_disable();
kexec_smp_wait();
/* NOTREACHED */
}
@@ -174,14 +181,17 @@ static void kexec_prepare_cpus(void)
int my_cpu, i, notified=-1;
smp_call_function(kexec_smp_down, NULL, /* wait */0);
+ local_irq_disable();
+ mb(); /* make sure IRQs are disabled before we say they are */
+ get_paca()-kexec_irqs_off = 1;
my_cpu = get_cpu();
- /* check the others cpus are now down (via paca hw cpu id == -1) */
+ /* check the others cpus are now down (via paca kexec_irqs_off == 1) */
for (i=0; i NR_CPUS; i++) {
if (i == my_cpu)
continue;
- while (paca[i].hw_cpu_id != -1) {
+ while (paca[i].kexec_irqs_off != 1) {
barrier();
if (!cpu_possible(i)) {
printk(kexec: cpu %d hw_cpu_id %d is not
@@ -207,6 +217,9 @@ static void kexec_prepare_cpus(void)
}
}
}
+ mb();
+ /* we are sure every CPU has IRQs off at this point */
+ kexec_all_irq_disabled = 1;
/* after we tell the others to go down */
if (ppc_md.kexec_cpu_down)
@@ -214,7 +227,6 @@ static void kexec_prepare_cpus(void)
put_cpu();
- local_irq_disable();
}
#else /* ! SMP */
Index: linux-2.6-ozlabs/arch/powerpc/kernel/misc_64.S
===
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/misc_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/misc_64.S
@@ -494,14 +494,11 @@ kexec_flag:
* note: this is a terminal routine, it does not save lr
*
* get phys id from paca
- * set paca id to -1 to say we got here
* switch to real mode
* join other cpus in kexec_wait(phys_id)
*/
_GLOBAL(kexec_smp_wait)
lhz
Re: [PATCH 2/2] powerpc,kexec: Speedup kexec hpte tear down
On Tue, 2010-05-11 at 16:28 +1000, Michael Neuling wrote:
Currently for kexec the PTE tear down on 1TB segment systems normally
requires 3 hcalls for each PTE removal. On a machine with 32GB of
memory it can take around a minute to remove all the PTEs.
..
- /* TODO: Use bulk call */
...
+ /* Read in batches of 4,
+ * invalidate only valid entries not in the VRMA
+ * hpte_count will be a multiple of 4
+ */
+ for (i = 0; i hpte_count; i += 4) {
+ lpar_rc = plpar_pte_read_4_raw(0, i, (void *)ptes);
+ if (lpar_rc != H_SUCCESS)
+ continue;
+ for (j = 0; j 4; j++){
+ if ((ptes[j].pteh HPTE_V_VRMA_MASK) ==
+ HPTE_V_VRMA_MASK)
+ continue;
+ if (ptes[j].pteh HPTE_V_VALID)
+ plpar_pte_remove_raw(0, i + j, 0,
+ (ptes[j].pteh), (ptes[j].ptel));
}
Have you tried using the bulk remove call, if none of the HPTEs are for
the VRMA? Rumour was it was slower/the-same, but that may have been
apocryphal.
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Curious serial slowdown
Hello all, I'm looking for hints on a curious problem. I have a working kernel on a custom embedded device and it works fine. We came up with a variation of the device with a few hardware changes, one of them being the number of serial ports that goes from 4 to 2. In order to save time I tried my current kernel. When I boot the custom bootlader behaves the same, then the kernel boot behaves the same, but then once usermode is reached (the message init started: BusyBox...), the new card console display crawls to a halt (about one character per second instead of 115000 bauds !!!). But the card goes at normal speed as an ssh connection shows. So my question is: is it caused by the fact that there are 2 missing serial ports ? Will making a new kernel with the correct hardware definition solve it ? -- Guillaume Dargaud http://www.gdargaud.net/ smime.p7s Description: S/MIME cryptographic signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] kexec-tools, ppc64: Fix segfault parsing DR memory property
add_dyn_reconf_usable_mem_property() iterates over memory spans
in /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory and intersects
these with usablemem_rgns ranges. Not only did it seem to write
null properties for every range that didn't match, but it used an unchecked
fixed-size array which will overrun on machines with lots of LMBs.
This patch stops add_dyn_reconf_usable_mem_property() from adding null ranges
to the linux,drconf-usable-memory property and removes its fixed-size array,
as well as the array in add_usable_mem_property, in lieu of malloc/realloc/free.
Signed-off-by: Matt Evans m...@ozlabs.org
---
kexec/arch/ppc64/fs2dt.c | 66 +
1 files changed, 54 insertions(+), 12 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 762bf04..7470132 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -37,7 +37,7 @@
#define NAMESPACE 16384/* max bytes for property names */
#define INIT_TREE_WORDS 65536 /* Initial num words for prop values */
#define MEMRESERVE 256 /* max number of reserved memory blocks */
-#define MAX_MEMORY_RANGES 1024
+#define MEM_RANGE_CHUNK_SZ 2048 /* Initial num dwords for mem ranges */
static char pathname[MAXPATH], *pathstart;
static char propnames[NAMESPACE] = { 0 };
@@ -148,7 +148,8 @@ static void add_dyn_reconf_usable_mem_property(int fd)
{
char fname[MAXPATH], *bname;
uint64_t buf[32];
- uint64_t ranges[2*MAX_MEMORY_RANGES];
+ uint64_t *ranges;
+ int ranges_size = MEM_RANGE_CHUNK_SZ;
uint64_t base, end, loc_base, loc_end;
size_t i, rngs_cnt, range;
int rlen = 0;
@@ -165,6 +166,11 @@ static void add_dyn_reconf_usable_mem_property(int fd)
die(unrecoverable error: error seeking in \%s\: %s\n,
pathname, strerror(errno));
+ ranges = malloc(ranges_size*8);
+ if (!ranges)
+ die(unrecoverable error: can't alloc %d bytes for ranges.\n,
+ ranges_size*8);
+
rlen = 0;
for (i = 0; i num_of_lmbs; i++) {
if (read(fd, buf, 24) 0)
@@ -180,24 +186,41 @@ static void add_dyn_reconf_usable_mem_property(int fd)
rngs_cnt = 0;
for (range = 0; range usablemem_rgns.size; range++) {
+ int add = 0;
loc_base = usablemem_rgns.ranges[range].start;
loc_end = usablemem_rgns.ranges[range].end;
if (loc_base = base loc_end = end) {
- ranges[rlen++] = loc_base;
- ranges[rlen++] = loc_end - loc_base;
- rngs_cnt++;
+ add = 1;
} else if (base loc_end end loc_base) {
if (loc_base base)
loc_base = base;
if (loc_end end)
loc_end = end;
+ add = 1;
+ }
+
+ if (add) {
+ if (rlen = (ranges_size-2)) {
+ ranges_size += MEM_RANGE_CHUNK_SZ;
+ ranges = realloc(ranges, ranges_size*8);
+ if (!ranges)
+ die(unrecoverable error: can't
+realloc %d bytes for
+ranges.\n,
+ ranges_size*8);
+ }
ranges[rlen++] = loc_base;
ranges[rlen++] = loc_end - loc_base;
rngs_cnt++;
}
}
- /* Store the count of (base, size) duple */
- ranges[tmp_indx] = rngs_cnt;
+ if (rngs_cnt == 0) {
+ /* Don't store anything for unwritten iterations! */
+ rlen = tmp_indx;
+ } else {
+ /* Store the count of (base, size) duple */
+ ranges[tmp_indx] = rngs_cnt;
+ }
}
rlen = rlen * sizeof(uint64_t);
@@ -210,7 +233,8 @@ static void add_dyn_reconf_usable_mem_property(int fd)
*dt++ = propnum(linux,drconf-usable-memory);
if ((rlen = 8) ((unsigned long)dt 0x4))
dt++;
- memcpy(dt, ranges, rlen);
+ memcpy(dt, ranges, rlen);
+ free(ranges);
dt += (rlen + 3)/4;
}
@@ -218,7 +242,8 @@ static void add_usable_mem_property(int fd, size_t len)
{
char fname[MAXPATH], *bname;
uint64_t buf[2];
- uint64_t
Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space
In usual workload, the number of dirty pages varies a lot for each iteration and we should gain really a lot for relatively clean cases. Can you post such a test, for an idle large guest? OK, I'll do! Result of low workload test (running top during migration) first, 4GB guest picked up slots[1](len=3757047808) only * get.org get.optswitch.opt 1060875 310292 190335 1076754 301295 188600 655504 318284 196029 529769 301471325 694796 70216 221172 651868 353073 196184 543339 312865 213236 1061938 72785 203090 689527 323901 249519 621364 323881473 1063671 70703 192958 915903 336318 174008 1046462 332384782 1037942 72783 190655 680122 318305 243544 688156 314935 193526 558658 265934 190550 652454 372135 196270 660140 68613352 1101947 378642 186575 ......... * As expected we've got the difference more clearly. In this case, switch.opt reduced 1/3 (.1 msec) compared to get.opt for each iteration. And when the slot is cleaner, the ratio is bigger. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] 85xx: Fix PCI-E interrupt mapping for slot 0 of P2020DS
On May 10, 2010, at 2:15 PM, Felix Radensky wrote:
Fix legacy PCI-E interrupt mapping for PCI-E slot 0 of
P2020DS evaluation board. The patch is based on P2020DS
device tree from Freescale BSP for this board.
Signed-off-by: Felix Radensky fe...@embedded-sol.com
---
arch/powerpc/boot/dts/p2020ds.dts |8
1 files changed, 4 insertions(+), 4 deletions(-)
I don't understand why this is needed?
-k
diff --git a/arch/powerpc/boot/dts/p2020ds.dts
b/arch/powerpc/boot/dts/p2020ds.dts
index 1101914..7c5fc07 100644
--- a/arch/powerpc/boot/dts/p2020ds.dts
+++ b/arch/powerpc/boot/dts/p2020ds.dts
@@ -507,10 +507,10 @@
interrupt-map-mask = 0xf800 0x0 0x0 0x7;
interrupt-map =
/* IDSEL 0x0 */
- 0x0 0x0 0x1 mpic 0x8 0x1
- 0x0 0x0 0x2 mpic 0x9 0x1
- 0x0 0x0 0x3 mpic 0xa 0x1
- 0x0 0x0 0x4 mpic 0xb 0x1
+ 0x0 0x0 0x1 mpic 0x8 0x2
+ 0x0 0x0 0x2 mpic 0x9 0x2
+ 0x0 0x0 0x3 mpic 0xa 0x2
+ 0x0 0x0 0x4 mpic 0xb 0x2
;
p...@0 {
reg = 0x0 0x0 0x0 0x0 0x0;
--
1.5.4.3
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] 85xx: Fix PCI-E interrupt mapping for slot 0 of P2020DS
On May 10, 2010, at 2:15 PM, Felix Radensky wrote:Fix legacy PCI-E interrupt mapping for PCI-E slot 0 ofP2020DS evaluation board. The patch is based on P2020DSdevice tree from Freescale BSP for this board.Signed-off-by: Felix Radensky fe...@embedded-sol.com---arch/powerpc/boot/dts/p2020ds.dts | 8 1 files changed, 4 insertions(+), 4 deletions(-)I don't understand why this is needed?-kdiff --git a/arch/powerpc/boot/dts/p2020ds.dts b/arch/powerpc/boot/dts/p2020ds.dtsindex 1101914..7c5fc07 100644--- a/arch/powerpc/boot/dts/p2020ds.dts+++ b/arch/powerpc/boot/dts/p2020ds.dts@@ -507,10 +507,10 @@ interrupt-map-mask = 0xf800 0x0 0x0 0x7; interrupt-map = /* IDSEL 0x0 */- 0x0 0x0 0x1 mpic 0x8 0x1- 0x0 0x0 0x2 mpic 0x9 0x1- 0x0 0x0 0x3 mpic 0xa 0x1- 0x0 0x0 0x4 mpic 0xb 0x1+ 0x0 0x0 0x1 mpic 0x8 0x2+ 0x0 0x0 0x2 mpic 0x9 0x2+ 0x0 0x0 0x3 mpic 0xa 0x2+ 0x0 0x0 0x4 mpic 0xb 0x2 ; p...@0 { reg = 0x0 0x0 0x0 0x0 0x0;--1.5.4.3___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Use more accurate limit for first segment memory allocations
On Tue, 2010-05-11 at 14:59 +1000, Anton Blanchard wrote:
Author: Milton Miller milt...@bga.com
On large machines we are running out of room below 256MB. In some cases we
only need to ensure the allocation is in the first segment, which may be
256MB or 1TB.
Add slb0_limit and use it to specify the upper limit for the irqstack and
emergency stacks.
On a large ppc64 box, this fixes a panic at boot when the crashkernel=
option is specified (previously we would run out of memory below 256MB).
Signed-off-by: Milton Miller milt...@bga.com
Signed-off-by: Anton Blanchard an...@samba.org
---
Some things we should add:
- Specify a more intelligent limit for BookE
- The allocation of the PACAs should use this limit too
We access the PACA from real mode?
Index: linux-2.6/arch/powerpc/kernel/setup_64.c
===
--- linux-2.6.orig/arch/powerpc/kernel/setup_64.c 2010-04-22
17:23:42.0 +1000
+++ linux-2.6/arch/powerpc/kernel/setup_64.c 2010-04-30 09:46:15.0
+1000
@@ -424,9 +424,18 @@ void __init setup_system(void)
DBG( - setup_system()\n);
}
+static u64 slb0_limit(void)
+{
+ if (cpu_has_feature(CPU_FTR_1T_SEGMENT)) {
+ return 1UL SID_SHIFT_1T;
+ }
+ return 1UL SID_SHIFT;
+}
I take it there's no chance the CPU feature is there but we're using 256
for whatever reason?
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/44x: Add basic ICON PPC440SPe board support
ICON is based on the AppliedMicro 440SPe. It is equipped with
64MByte NOR FLASH, SODIMM, Gigabit ethernet, SM502 on PCI(X),
LSI SAS1068E on PCIe0 and custom FPGA on PCIe1.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Josh Boyer jwbo...@linux.vnet.ibm.com
---
arch/powerpc/boot/dts/icon.dts | 447 ++
arch/powerpc/configs/44x/icon_defconfig| 1316
arch/powerpc/platforms/44x/Kconfig | 11 +
arch/powerpc/platforms/44x/ppc44x_simple.c |3 +-
4 files changed, 1776 insertions(+), 1 deletions(-)
create mode 100644 arch/powerpc/boot/dts/icon.dts
create mode 100644 arch/powerpc/configs/44x/icon_defconfig
diff --git a/arch/powerpc/boot/dts/icon.dts b/arch/powerpc/boot/dts/icon.dts
new file mode 100644
index 000..abcd0ca
--- /dev/null
+++ b/arch/powerpc/boot/dts/icon.dts
@@ -0,0 +1,447 @@
+/*
+ * Device Tree Source for Mosaix Technologies, Inc. ICON board
+ *
+ * Copyright 2010 DENX Software Engineering, Stefan Roese s...@denx.de
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = 2;
+ #size-cells = 2;
+ model = mosaixtech,icon;
+ compatible = mosaixtech,icon;
+ dcr-parent = {/cpus/c...@0};
+
+ aliases {
+ ethernet0 = EMAC0;
+ serial0 = UART0;
+ serial1 = UART1;
+ serial2 = UART2;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ c...@0 {
+ device_type = cpu;
+ model = PowerPC,440SPe;
+ reg = 0x;
+ clock-frequency = 0; /* Filled in by U-Boot */
+ timebase-frequency = 0; /* Filled in by U-Boot */
+ i-cache-line-size = 32;
+ d-cache-line-size = 32;
+ i-cache-size = 32768;
+ d-cache-size = 32768;
+ dcr-controller;
+ dcr-access-method = native;
+ reset-type = 2; /* Use chip-reset */
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x0 0x 0x0 0x; /* Filled in by U-Boot */
+ };
+
+ UIC0: interrupt-controller0 {
+ compatible = ibm,uic-440spe,ibm,uic;
+ interrupt-controller;
+ cell-index = 0;
+ dcr-reg = 0x0c0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ };
+
+ UIC1: interrupt-controller1 {
+ compatible = ibm,uic-440spe,ibm,uic;
+ interrupt-controller;
+ cell-index = 1;
+ dcr-reg = 0x0d0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0x1e 0x4 0x1f 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC2: interrupt-controller2 {
+ compatible = ibm,uic-440spe,ibm,uic;
+ interrupt-controller;
+ cell-index = 2;
+ dcr-reg = 0x0e0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0xa 0x4 0xb 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ UIC3: interrupt-controller3 {
+ compatible = ibm,uic-440spe,ibm,uic;
+ interrupt-controller;
+ cell-index = 3;
+ dcr-reg = 0x0f0 0x009;
+ #address-cells = 0;
+ #size-cells = 0;
+ #interrupt-cells = 2;
+ interrupts = 0x10 0x4 0x11 0x4; /* cascade */
+ interrupt-parent = UIC0;
+ };
+
+ SDR0: sdr {
+ compatible = ibm,sdr-440spe;
+ dcr-reg = 0x00e 0x002;
+ };
+
+ CPR0: cpr {
+ compatible = ibm,cpr-440spe;
+ dcr-reg = 0x00c 0x002;
+ };
+
+ MQ0: mq {
+ compatible = ibm,mq-440spe;
+ dcr-reg = 0x040 0x020;
+ };
+
+ plb {
+ compatible = ibm,plb-440spe, ibm,plb-440gp, ibm,plb4;
+ #address-cells = 2;
+ #size-cells = 1;
+ /*addr-child addr-parentsize */
+ ranges = 0x4 0x0010 0x4 0x0010 0x1000
+ 0x4 0x0020 0x4 0x0020 0x0400
+ 0x4 0xe000 0x4 0xe000 0x2000
+ 0xc 0x 0xc 0x 0x2000
+ 0xd 0x 0xd 0x 0x8000
+ 0xd 0x8000
Re: [RFC][PATCH 11/12] KVM: introduce new API for getting/switching dirty bitmaps
On Tue, May 11, 2010 at 02:53:54PM +0900, Takuya Yoshikawa wrote:
(2010/05/11 12:43), Marcelo Tosatti wrote:
On Tue, May 04, 2010 at 10:08:21PM +0900, Takuya Yoshikawa wrote:
+How to Get
+
+Before calling this, you have to set the slot member of kvm_user_dirty_log
+to indicate the target memory slot.
+
+struct kvm_user_dirty_log {
+ __u32 slot;
+ __u32 flags;
+ __u64 dirty_bitmap;
+ __u64 dirty_bitmap_old;
+};
+
+The addresses will be set in the paired members: dirty_bitmap and _old.
Why not pass the bitmap address to the kernel, instead of having the
kernel allocate it. Because apparently you plan to do that in a new
generation anyway?
Yes, we want to make qemu allocate and free bitmaps in the future.
But currently, those are strictly tied with memory slot registration and
changing it in one patch set is really difficult.
Anyway, we need kernel side allocation mechanism to keep the current
GET_DIRTY_LOG api. I don't mind not exporting kernel allocated bitmaps
in this patch set and later introducing a bitmap registration mechanism
in another patch set.
As this RFC is suggesting, kernel side double buffering infrastructure is
designed as general as possible and adding a new API like SWITCH can be done
naturally.
Also, why does the kernel need to know about different bitmaps?
Because we need to support current GET API. We don't have any way to get
a new bitmap in the case of GET and we don't want to do_mmap() every time
for GET.
One alternative would be:
KVM_SWITCH_DIRTY_LOG passing the address of a bitmap. If the active
bitmap was clean, it returns 0, no switch performed. If the active
bitmap was dirty, the kernel switches to the new bitmap and returns 1.
And the responsability of cleaning the new bitmap could also be left
for userspace.
That is a beautiful approach but we can do that only when we give up using
GET api.
I follow you and Avi's advice about that kind of maintenance policy!
What do you think?
If you introduce a switch ioctl that frees the bitmap vmalloc'ed by the
current set_memory_region (if its not freed already), after pointing the
memslot to the user supplied one, it should be fine?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Fix kexec on powerpc32
Hello everybody,
Please find here patch for user land kexec-tools application. Following
patch makes kexec-tools work for both kexec and kdump. I tested it with
git kernel (linus-tree) and Freescale/Logic MPC8360ERDK board with
mpc83xx_defconfig kernel config.
kexec:
kexec -l vmlinux --command-line=console= ... etc
kexec -e
kdump:
kexec -p vmlinux_dump --command-line=console=... etc
echo c /proc/sysrq-trigger
I also think that is is reasonable:
- put GAME_CUBE specific code to separate files;
- combine ppc and ppc64 to powerpc directory (I'm planning to do it.
And that why in some places my patch have ifdefs for PPC64);
Best regards,
Maxim Uvarov.
From: Maxim Uvarov muva...@gmail.com
Signed-off-by: Maxim Uvarov muva...@gmail.com
Signed-off-by: Maxim Uvarov muva...@gmail.com
---
kexec/arch/ppc/Makefile|2
kexec/arch/ppc/crashdump-powerpc.c | 439 ++
kexec/arch/ppc/crashdump-powerpc.h | 38 +++
kexec/arch/ppc/fs2dt.c | 460
kexec/arch/ppc/kexec-elf-ppc.c | 186 +--
kexec/arch/ppc/kexec-ppc.c | 276 --
kexec/arch/ppc/kexec-ppc.h | 32 +++
purgatory/arch/ppc/Makefile|2
purgatory/arch/ppc/purgatory-ppc.c | 38 ++-
purgatory/arch/ppc/purgatory-ppc.h |4
purgatory/arch/ppc/v2wrap.S| 66 -
purgatory/arch/ppc/v2wrap_32.S | 91 +++
12 files changed, 1524 insertions(+), 110 deletions(-)
create mode 100644 kexec/arch/ppc/crashdump-powerpc.c
create mode 100644 kexec/arch/ppc/crashdump-powerpc.h
create mode 100644 kexec/arch/ppc/fs2dt.c
delete mode 100644 purgatory/arch/ppc/v2wrap.S
create mode 100644 purgatory/arch/ppc/v2wrap_32.S
diff --git a/kexec/arch/ppc/Makefile b/kexec/arch/ppc/Makefile
index 1c7441c..5988213 100644
--- a/kexec/arch/ppc/Makefile
+++ b/kexec/arch/ppc/Makefile
@@ -11,6 +11,8 @@ ppc_KEXEC_SRCS += kexec/arch/ppc/kexec-uImage-ppc.c
ppc_KEXEC_SRCS += kexec/arch/ppc/ppc-setup-simple.S
ppc_KEXEC_SRCS += kexec/arch/ppc/ppc-setup-dol.S
ppc_KEXEC_SRCS += kexec/arch/ppc/fixup_dtb.c
+ppc_KEXEC_SRCS += kexec/arch/ppc/fs2dt.c
+ppc_KEXEC_SRCS += kexec/arch/ppc/crashdump-powerpc.c
ppc_KEXEC_SRCS += kexec/kexec-uImage.c
libfdt_SRCS = kexec/arch/ppc/libfdt-wrapper.c
diff --git a/kexec/arch/ppc/crashdump-powerpc.c
b/kexec/arch/ppc/crashdump-powerpc.c
new file mode 100644
index 000..7bfad20
--- /dev/null
+++ b/kexec/arch/ppc/crashdump-powerpc.c
@@ -0,0 +1,439 @@
+#include stdio.h
+#include string.h
+#include stdlib.h
+#include unistd.h
+#include errno.h
+#include limits.h
+#include elf.h
+#include dirent.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include ../../kexec.h
+#include ../../kexec-elf.h
+#include ../../kexec-syscall.h
+#include ../../crashdump.h
+#include kexec-ppc.h
+#include crashdump-powerpc.h
+
+#ifdef CONFIG_PPC64
+static struct crash_elf_info elf_info64 = {
+class: ELFCLASS64,
+data: ELFDATA2MSB,
+machine: EM_PPC64,
+backup_src_start: BACKUP_SRC_START,
+backup_src_end: BACKUP_SRC_END,
+page_offset: PAGE_OFFSET,
+lowmem_limit: MAXMEM,
+};
+#endif
+static struct crash_elf_info elf_info32 = {
+class: ELFCLASS32,
+data: ELFDATA2MSB,
+#ifdef CONFIG_PPC64
+machine: EM_PPC64,
+#else
+machine: EM_PPC,
+#endif
+backup_src_start: BACKUP_SRC_START,
+backup_src_end: BACKUP_SRC_END,
+page_offset: PAGE_OFFSET,
+lowmem_limit: MAXMEM,
+};
+
+/* Stores a sorted list of RAM memory ranges for which to create elf headers.
+ * A separate program header is created for backup region
+ */
+static struct memory_range *crash_memory_range;
+
+/* Define a variable to replace the CRASH_MAX_MEMORY_RANGES macro */
+static int crash_max_memory_ranges;
+
+/*
+ * Used to save various memory ranges/regions needed for the captured
+ * kernel to boot. (lime memmap= option in other archs)
+ */
+mem_rgns_t usablemem_rgns = {0, NULL};
+
+/*
+ * To store the memory size of the first kernel and this value will be
+ * passed to the second kernel as command line (savemaxmem=xM).
+ * The second kernel will be calculated saved_max_pfn based on this
+ * variable.
+ * Since we are creating/using usable-memory property, there is no way
+ * we can determine the RAM size unless parsing the device-tree/memoy@/reg
+ * property in the kernel.
+ */
+unsigned long long saved_max_mem;
+
+/* Reads the appropriate file and retrieves the SYSTEM RAM regions for whom to
+ * create Elf headers. Keeping it separate from get_memory_ranges() as
+ * requirements are different in the case of normal kexec and crashdumps.
+ *
+ * Normal kexec needs to look at all of available physical memory irrespective
+ * of the fact how much of it is being used by currently running kernel.
+ * Crashdumps need to have access to memory regions actually being used by
+ * running kernel. Expecting a different file/data structure than /proc/iomem
+ *
[PATCH] [POWEPC] crashdump: do not fail on null pointer dereferencing
Best regards,
Maxim Uvarov.
From: Maxim Uvarov muva...@gmail.com
Signed-off-by: Maxim Uvarov muva...@gmail.com
---
arch/powerpc/kernel/crash.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 6f4613d..341d8af 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -375,6 +375,9 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
for_each_irq(i) {
struct irq_desc *desc = irq_to_desc(i);
+ if (!desc || !desc-chip || !desc-chip-eoi)
+ continue;
+
if (desc-status IRQ_INPROGRESS)
desc-chip-eoi(i);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space
Takuya Yoshikawa wrote: Hi, sorry for sending from my personal account. The following series are all from me: From: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp The 3rd version of moving dirty bitmaps to user space. From this version, we add x86 and ppc and asm-generic people to CC lists. [To KVM people] Sorry for being late to reply your comments. Avi, - I've wrote an answer to your question in patch 5/12: drivers/vhost/vhost.c . - I've considered to change the set_bit_user_non_atomic to an inline function, but did not change because the other helpers in the uaccess.h are written as macros. Anyway, I hope that x86 people will give us appropriate suggestions about this. - I thought that documenting about making bitmaps 64-bit aligned will be written when we add an API to register user-allocated bitmaps. So probably in the next series. Avi, Alex, - Could you check the ia64 and ppc parts, please? I tried to keep the logical changes as small as possible. I personally tried to build these with cross compilers. For ia64, I could check build success with my patch series. But book3s, even without my patch series, it failed with the following errors: arch/powerpc/kvm/book3s_paired_singles.c: In function 'kvmppc_emulate_paired_single': arch/powerpc/kvm/book3s_paired_singles.c:1289: error: the frame size of 2288 bytes is larger than 2048 bytes make[1]: *** [arch/powerpc/kvm/book3s_paired_singles.o] Error 1 make: *** [arch/powerpc/kvm] Error 2 This is bad. I haven't encountered that one at all so far, but I guess my compiler version is different from yours. Sigh. About changelog: there are two main changes from the 2nd version: 1. I changed the treatment of clean slots (see patch 1/12). This was already applied today, thanks! 2. I changed the switch API. (see patch 11/12). To show this API's advantage, I also did a test (see the end of this mail). [To x86 people] Hi, Thomas, Ingo, Peter, Please review the patches 4,5/12. Because this is the first experience for me to send patches to x86, please tell me if this lacks anything. [To ppc people] Hi, Benjamin, Paul, Alex, Please see the patches 6,7/12. I first say sorry for that I've not tested these yet. In that sense, these may not be in the quality for precise reviews. But I will be happy if you would give me any comments. Alex, could you help me? Though I have a plan to get PPC box in the future, currently I cannot test these. Could you please point me to a git tree where everything's readily applied? That would make testing a lot easier. Alex ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC][PATCH 7/12 not tested yet] PPC: introduce __set_bit() like function for bitmaps in user space
Takuya Yoshikawa wrote:
During the work of KVM's dirty page logging optimization, we encountered
the need of manipulating bitmaps in user space efficiantly. To achive this,
we introduce a uaccess function for setting a bit in user space following
Avi's suggestion.
KVM is now using dirty bitmaps for live-migration and VGA. Although we need
to update them from kernel side, copying them every time for updating the
dirty log is a big bottleneck. Especially, we tested that zero-copy bitmap
manipulation improves responses of GUI manipulations a lot.
We also found one similar need in drivers/vhost/vhost.c in which the author
implemented set_bit_to_user() locally using inefficient functions: see TODO
at the top of that.
Probably, this kind of need would be common for virtualization area.
So we introduce a function set_bit_user_non_atomic().
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
Signed-off-by: Fernando Luis Vazquez Cao ferna...@oss.ntt.co.jp
CC: Alexander Graf ag...@suse.de
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
---
arch/powerpc/include/asm/uaccess.h | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/uaccess.h
b/arch/powerpc/include/asm/uaccess.h
index 3a01ce8..f878326 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -321,6 +321,25 @@ do {
\
__gu_err; \
})
+static inline int set_bit_user_non_atomic(int nr, void __user *addr)
+{
+ u8 __user *p;
+ u8 val;
+
+ p = (u8 __user *)((unsigned long)addr + nr / BITS_PER_BYTE);
Does C do the + or the / first? Either way, I'd like to see brackets here :)
Alex
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] [POWEPC] crashdump: do not fail on null pointer dereferencing
Hi,
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 6f4613d..341d8af 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -375,6 +375,9 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
for_each_irq(i) {
struct irq_desc *desc = irq_to_desc(i);
+ if (!desc || !desc-chip || !desc-chip-eoi)
+ continue;
+
Kinda unlikely that desc can be NULL here :)
~Vitaly
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] Fix kexec on powerpc32
This patch is required in case if you are using new toolchains.
Best regards,
Maxim Uvarov.
From: Maxim Uvarov muva...@gmail.com
Signed-off-by: Maxim Uvarov muva...@gmail.com
---
kexec/arch/ppc/Makefile|2
kexec/arch/ppc/crashdump-powerpc.c | 439 ++
kexec/arch/ppc/crashdump-powerpc.h | 38 +++
kexec/arch/ppc/fs2dt.c | 460
kexec/arch/ppc/kexec-elf-ppc.c | 186 +--
kexec/arch/ppc/kexec-ppc.c | 276 --
kexec/arch/ppc/kexec-ppc.h | 32 +++
purgatory/arch/ppc/Makefile|2
purgatory/arch/ppc/purgatory-ppc.c | 38 ++-
purgatory/arch/ppc/purgatory-ppc.h |4
purgatory/arch/ppc/v2wrap.S| 66 -
purgatory/arch/ppc/v2wrap_32.S | 91 +++
12 files changed, 1524 insertions(+), 110 deletions(-)
create mode 100644 kexec/arch/ppc/crashdump-powerpc.c
create mode 100644 kexec/arch/ppc/crashdump-powerpc.h
create mode 100644 kexec/arch/ppc/fs2dt.c
delete mode 100644 purgatory/arch/ppc/v2wrap.S
create mode 100644 purgatory/arch/ppc/v2wrap_32.S
diff --git a/kexec/arch/ppc/Makefile b/kexec/arch/ppc/Makefile
index 1c7441c..5988213 100644
--- a/kexec/arch/ppc/Makefile
+++ b/kexec/arch/ppc/Makefile
@@ -11,6 +11,8 @@ ppc_KEXEC_SRCS += kexec/arch/ppc/kexec-uImage-ppc.c
ppc_KEXEC_SRCS += kexec/arch/ppc/ppc-setup-simple.S
ppc_KEXEC_SRCS += kexec/arch/ppc/ppc-setup-dol.S
ppc_KEXEC_SRCS += kexec/arch/ppc/fixup_dtb.c
+ppc_KEXEC_SRCS += kexec/arch/ppc/fs2dt.c
+ppc_KEXEC_SRCS += kexec/arch/ppc/crashdump-powerpc.c
ppc_KEXEC_SRCS += kexec/kexec-uImage.c
libfdt_SRCS = kexec/arch/ppc/libfdt-wrapper.c
diff --git a/kexec/arch/ppc/crashdump-powerpc.c
b/kexec/arch/ppc/crashdump-powerpc.c
new file mode 100644
index 000..7bfad20
--- /dev/null
+++ b/kexec/arch/ppc/crashdump-powerpc.c
@@ -0,0 +1,439 @@
+#include stdio.h
+#include string.h
+#include stdlib.h
+#include unistd.h
+#include errno.h
+#include limits.h
+#include elf.h
+#include dirent.h
+#include sys/types.h
+#include sys/stat.h
+#include fcntl.h
+#include ../../kexec.h
+#include ../../kexec-elf.h
+#include ../../kexec-syscall.h
+#include ../../crashdump.h
+#include kexec-ppc.h
+#include crashdump-powerpc.h
+
+#ifdef CONFIG_PPC64
+static struct crash_elf_info elf_info64 = {
+class: ELFCLASS64,
+data: ELFDATA2MSB,
+machine: EM_PPC64,
+backup_src_start: BACKUP_SRC_START,
+backup_src_end: BACKUP_SRC_END,
+page_offset: PAGE_OFFSET,
+lowmem_limit: MAXMEM,
+};
+#endif
+static struct crash_elf_info elf_info32 = {
+class: ELFCLASS32,
+data: ELFDATA2MSB,
+#ifdef CONFIG_PPC64
+machine: EM_PPC64,
+#else
+machine: EM_PPC,
+#endif
+backup_src_start: BACKUP_SRC_START,
+backup_src_end: BACKUP_SRC_END,
+page_offset: PAGE_OFFSET,
+lowmem_limit: MAXMEM,
+};
+
+/* Stores a sorted list of RAM memory ranges for which to create elf headers.
+ * A separate program header is created for backup region
+ */
+static struct memory_range *crash_memory_range;
+
+/* Define a variable to replace the CRASH_MAX_MEMORY_RANGES macro */
+static int crash_max_memory_ranges;
+
+/*
+ * Used to save various memory ranges/regions needed for the captured
+ * kernel to boot. (lime memmap= option in other archs)
+ */
+mem_rgns_t usablemem_rgns = {0, NULL};
+
+/*
+ * To store the memory size of the first kernel and this value will be
+ * passed to the second kernel as command line (savemaxmem=xM).
+ * The second kernel will be calculated saved_max_pfn based on this
+ * variable.
+ * Since we are creating/using usable-memory property, there is no way
+ * we can determine the RAM size unless parsing the device-tree/memoy@/reg
+ * property in the kernel.
+ */
+unsigned long long saved_max_mem;
+
+/* Reads the appropriate file and retrieves the SYSTEM RAM regions for whom to
+ * create Elf headers. Keeping it separate from get_memory_ranges() as
+ * requirements are different in the case of normal kexec and crashdumps.
+ *
+ * Normal kexec needs to look at all of available physical memory irrespective
+ * of the fact how much of it is being used by currently running kernel.
+ * Crashdumps need to have access to memory regions actually being used by
+ * running kernel. Expecting a different file/data structure than /proc/iomem
+ * to look into down the line. May be something like /proc/kernelmem or may
+ * be zone data structures exported from kernel.
+ */
+static int get_crash_memory_ranges(struct memory_range **range, int *ranges)
+{
+
+ int memory_ranges = 0;
+ char device_tree[256] = /proc/device-tree/;
+ char fname[256];
+ char buf[MAXBYTES-1];
+ DIR *dir, *dmem;
+ FILE *file;
+ struct dirent *dentry, *mentry;
+ int i, n, crash_rng_len = 0;
+ unsigned long long start, end, cstart, cend;
+
+ crash_max_memory_ranges = max_memory_ranges + 6;
+ crash_rng_len = sizeof(struct memory_range) * crash_max_memory_ranges;
+
+ crash_memory_range = (struct
[PATCH 2/2] powerpc new toolchains fix (crt.S)
This patch is required in case if you are using new toolchains. Best regards, Maxim Uvarov. From: Maxim Uvarov muva...@gmail.com Linker does not provide some vital functions when building freestanding applications with a new toolchain, so we have to provide our own CRT. p.s. Without the CRT we won't see any build errors (since the purgatory is linked with --no-undefined), but the purgatory code won't work, 'kexec -e' will just hang the board. I added option to configure to keep code buildable for old toolchais. But there should be way to do this automatically. Author: Anton Vorontsov avoront...@ru.mvista.com Signed-off-by: Maxim Uvarov muva...@gmail.com --- configure.ac|9 + purgatory/arch/ppc/Makefile |3 +++ 2 files changed, 12 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index fcf50e4..63606bc 100644 --- a/configure.ac +++ b/configure.ac @@ -159,6 +159,15 @@ if test $with_xen = yes ; then AC_MSG_NOTICE([Xen support disabled]))) fi +dnl new toolchains +if test $ARCH = ppc; then +AC_ARG_WITH([oldtoolchain], + AC_HELP_STRING([--with-oldtoolchain],[compile without crt.S + required for new toolchains]), + AC_DEFINE(PPC_OLDTOOLCHAIN, 1, + [Define to compile with old toolchains])) +fi + dnl ---Sanity checks if test $CC = no; then AC_MSG_ERROR([cc not found]); fi if test $CPP = no; then AC_MSG_ERROR([cpp not found]); fi diff --git a/purgatory/arch/ppc/Makefile b/purgatory/arch/ppc/Makefile index 72289a0..d11ec3e 100644 --- a/purgatory/arch/ppc/Makefile +++ b/purgatory/arch/ppc/Makefile @@ -6,6 +6,9 @@ ppc_PURGATORY_SRCS += purgatory/arch/ppc/v2wrap_32.S ppc_PURGATORY_SRCS += purgatory/arch/ppc/misc.S ppc_PURGATORY_SRCS += purgatory/arch/ppc/purgatory-ppc.c ppc_PURGATORY_SRCS += purgatory/arch/ppc/console-ppc.c +ifndef PPC_OLDTOOLCHAIN + ppc_PURGATORY_SRCS += purgatory/arch/ppc/crt.S +endif dist += purgatory/arch/ppc/Makefile $(ppc_PURGATORY_SRCS) \ purgatory/arch/ppc/purgatory-ppc.h purgatory/arch/ppc/ppc_asm.h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc new toolchains fix (crt.S)
Forgot to add purgatory/arch/ppc/crt.S to the patch. Resending... -- This patch is required in case if you are using new toolchains. Best regards, Maxim Uvarov. From: Maxim Uvarov muva...@gmail.com Linker does not provide some vital functions when building freestanding applications with a new toolchain, so we have to provide our own CRT. p.s. Without the CRT we won't see any build errors (since the purgatory is linked with --no-undefined), but the purgatory code won't work, 'kexec -e' will just hang the board. I added option to configure to keep code buildable for old toolchais. But there should be way to do this automatically. Author: Anton Vorontsov avoront...@ru.mvista.com Signed-off-by: Maxim Uvarov muva...@gmail.com --- configure.ac|9 + purgatory/arch/ppc/Makefile |3 purgatory/arch/ppc/crt.S| 262 +++ 3 files changed, 274 insertions(+), 0 deletions(-) create mode 100644 purgatory/arch/ppc/crt.S diff --git a/configure.ac b/configure.ac index fcf50e4..63606bc 100644 --- a/configure.ac +++ b/configure.ac @@ -159,6 +159,15 @@ if test $with_xen = yes ; then AC_MSG_NOTICE([Xen support disabled]))) fi +dnl new toolchains +if test $ARCH = ppc; then +AC_ARG_WITH([oldtoolchain], + AC_HELP_STRING([--with-oldtoolchain],[compile without crt.S + required for new toolchains]), + AC_DEFINE(PPC_OLDTOOLCHAIN, 1, + [Define to compile with old toolchains])) +fi + dnl ---Sanity checks if test $CC = no; then AC_MSG_ERROR([cc not found]); fi if test $CPP = no; then AC_MSG_ERROR([cpp not found]); fi diff --git a/purgatory/arch/ppc/Makefile b/purgatory/arch/ppc/Makefile index 72289a0..d11ec3e 100644 --- a/purgatory/arch/ppc/Makefile +++ b/purgatory/arch/ppc/Makefile @@ -6,6 +6,9 @@ ppc_PURGATORY_SRCS += purgatory/arch/ppc/v2wrap_32.S ppc_PURGATORY_SRCS += purgatory/arch/ppc/misc.S ppc_PURGATORY_SRCS += purgatory/arch/ppc/purgatory-ppc.c ppc_PURGATORY_SRCS += purgatory/arch/ppc/console-ppc.c +ifndef PPC_OLDTOOLCHAIN + ppc_PURGATORY_SRCS += purgatory/arch/ppc/crt.S +endif dist += purgatory/arch/ppc/Makefile $(ppc_PURGATORY_SRCS) \ purgatory/arch/ppc/purgatory-ppc.h purgatory/arch/ppc/ppc_asm.h diff --git a/purgatory/arch/ppc/crt.S b/purgatory/arch/ppc/crt.S new file mode 100644 index 000..d7a44bd --- /dev/null +++ b/purgatory/arch/ppc/crt.S @@ -0,0 +1,262 @@ +/* This is from linux-2.6/arch/powerpc/lib/crtsavres.S: + * + * Special support for eabi and SVR4 + * + * Copyright (C) 1995, 1996, 1998, 2000, 2001 Free Software Foundation, Inc. + * Copyright 2008 Freescale Semiconductor, Inc. + * Written By Michael Meissner + * + * Based on gcc/config/rs6000/crtsavres.asm from gcc + * + * This file 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, or (at your option) any + * later version. + * + * In addition to the permissions in the GNU General Public License, the + * Free Software Foundation gives you unlimited permission to link the + * compiled version of this file with other programs, and to distribute + * those programs without any restriction coming from the use of this + * file. (The General Public License restrictions do apply in other + * respects; for example, they cover modification of the file, and + * distribution when not linked into another program.) + * + * This file is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; see the file COPYING. If not, write to + * the Free Software Foundation, 51 Franklin Street, Fifth Floor, + * Boston, MA 02110-1301, USA. + * + *As a special exception, if you link this library with files + *compiled with GCC to produce an executable, this does not cause + *the resulting executable to be covered by the GNU General Public License. + *This exception does not however invalidate any other reasons why + *the executable file might be covered by the GNU General Public License. + */ + +/* On PowerPC64 Linux, these functions are provided by the linker. */ +#ifndef __powerpc64__ + +#define _GLOBAL(name) \ + .type name,@function; \ + .globl name; \ +name: + +/* Routines for saving integer registers, called by the compiler. */ +/* Called with r11 pointing to the stack header word of the caller of the */ +/* function, just beyond the end of the integer save area. */ + +_GLOBAL(_savegpr_14) +_GLOBAL(_save32gpr_14) + stw 14,-72(11) /* save gp registers */ +_GLOBAL(_savegpr_15) +_GLOBAL(_save32gpr_15) + stw
Re: [PATCH 1/2] Fix kexec on powerpc32
On Tue, 11 May 2010 at 21:47, Maxim Uvarov wrote: This patch is required in case if you are using new toolchains. Ah, thanks I was missing (and looking for) crashdump-powerpc.h already :-) Christian -- make bzImage, not war ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] media/IR: Add missing include file to rc-map.c
Am Mittwoch 05 Mai 2010 17:20:21 schrieb Peter Hüwe: From: Peter Huewe peterhu...@gmx.de This patch adds a missing include linux/delay.h to prevent build failures[1-5] Signed-off-by: Peter Huewe peterhu...@gmx.de --- Any updates on this patch? Issue still exists with today's linux-next tree Thanks, Peter ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: eeh: Fix oops when probing in early boot
On 10 May 2010 20:38, Anton Blanchard an...@samba.org wrote: If we take an EEH early enough, we oops: Call Trace: [c00010483770] [c0013ee4] .show_stack+0xd8/0x218 (unreliable) [c00010483850] [c0658940] .dump_stack+0x28/0x3c [c000104838d0] [c0057a68] .eeh_dn_check_failure+0x2b8/0x304 [c00010483990] [c00259c8] .rtas_read_config+0x120/0x168 [c00010483a40] [c0025af4] .rtas_pci_read_config+0xe4/0x124 [c00010483af0] [c037af18] .pci_bus_read_config_word+0xac/0x104 [c00010483bc0] [c08fec98] .pcibios_allocate_resources+0x7c/0x220 [c00010483c90] [c08feed8] .pcibios_resource_survey+0x9c/0x418 [c00010483d80] [c08fea10] .pcibios_init+0xbc/0xf4 [c00010483e20] [c0009844] .do_one_initcall+0x98/0x1d8 [c00010483ed0] [c08f0560] .kernel_init+0x228/0x2e8 [c00010483f90] [c0031a08] .kernel_thread+0x54/0x70 EEH: Detected PCI bus error on device null EEH: This PCI device has failed 1 times in the last hour: EEH: location=U78A5.001.WIH8464-P1 driver= pci addr=0001:00:01.0 EEH: of node=/p...@8002209/u...@1 EEH: PCI device/vendor: 00351033 EEH: PCI cmd/status register: 12100146 Unable to handle kernel paging request for data at address 0x0468 Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0057610] .rtas_set_slot_reset+0x38/0x10c LR [c0058724] .eeh_reset_device+0x5c/0x124 Call Trace: [cbc6bd00] [c005a0e0] .pcibios_remove_pci_devices+0x7c/0xb0 (unreliable) [cbc6bd90] [c0058724] .eeh_reset_device+0x5c/0x124 [cbc6be40] [c00589c0] .handle_eeh_events+0x1d4/0x39c [cbc6bf00] [c0059124] .eeh_event_handler+0xf0/0x188 [cbc6bf90] [c0031a08] .kernel_thread+0x54/0x70 We called rtas_set_slot_reset while scanning the bus and before the pci_dn to pcidev mapping has been created. Since we only need the pcidev to work out the type of reset and that only gets set after the module for the device loads, lets just do a hot reset if the pcidev is NULL. Signed-off-by: Anton Blanchard an...@samba.org --- Acked-by: Linas Vepstas linasveps...@gmail.com I'm cc'ing Brian King, he's the one who figured out the proper fix for a hot-reset/fundamental-reset hardware feature that added this line of code. The question is -- when the system finishes booting, and the module finally loads, will the device be found in a usable state and/or will it automatically reset to a usable state? --linas Index: linux-2.6/arch/powerpc/platforms/pseries/eeh.c === --- linux-2.6.orig/arch/powerpc/platforms/pseries/eeh.c 2010-05-10 17:25:10.703453565 +1000 +++ linux-2.6/arch/powerpc/platforms/pseries/eeh.c 2010-05-10 17:25:24.034323030 +1000 @@ -749,7 +749,7 @@ static void __rtas_set_slot_reset(struct /* Determine type of EEH reset required by device, * default hot reset or fundamental reset */ - if (dev-needs_freset) + if (dev dev-needs_freset) rtas_pci_slot_reset(pdn, 3); else rtas_pci_slot_reset(pdn, 1); ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] 85xx: Fix PCI-E interrupt mapping for slot 0 of P2020DS
Hi Kumar, On 5/11/2010 3:36 PM, Kumar Gala wrote: On May 10, 2010, at 2:15 PM, Felix Radensky wrote: Fix legacy PCI-E interrupt mapping for PCI-E slot 0 of P2020DS evaluation board. The patch is based on P2020DS device tree from Freescale BSP for this board. Signed-off-by: Felix Radensky fe...@embedded-sol.com --- arch/powerpc/boot/dts/p2020ds.dts |8 1 files changed, 4 insertions(+), 4 deletions(-) I don't understand why this is needed? -k With 2.6.34-rc7 I get this nice dump when loading ath9k for PCI-E card in slot 0: irq 17: nobody cared (try booting with the irqpoll option) Call Trace: [ef0d59d0] [c00070b0] show_stack+0x3c/0x17c (unreliable) [ef0d5a10] [c00740f8] __report_bad_irq+0x38/0xcc [ef0d5a30] [c0074344] note_interrupt+0x1b8/0x228 [ef0d5a60] [c007539c] handle_fasteoi_irq+0xac/0x138 [ef0d5a80] [c0004a68] do_IRQ+0xd8/0x104 [ef0d5aa0] [c00102b0] ret_from_except+0x0/0x18 [ef0d5b60] [00029000] 0x29000 [ef0d5bb0] [c000498c] do_softirq+0x6c/0x70 [ef0d5bc0] [c0043bb4] irq_exit+0xb0/0xb4 [ef0d5bd0] [c0004a6c] do_IRQ+0xdc/0x104 [ef0d5bf0] [c00102b0] ret_from_except+0x0/0x18 [ef0d5cb0] [c00735c4] __setup_irq+0x374/0x3ac [ef0d5ce0] [c00736d4] request_threaded_irq+0xd8/0x150 [ef0d5d10] [f11e8c34] ath_pci_probe+0x28c/0x3f8 [ath9k] [ef0d5d90] [c0186334] local_pci_probe+0x24/0x34 [ef0d5da0] [c0186688] pci_device_probe+0x84/0xc4 [ef0d5dd0] [c01b7f84] driver_probe_device+0xa4/0x198 [ef0d5df0] [c01b8328] __driver_attach+0xa4/0xa8 [ef0d5e10] [c01b71b8] bus_for_each_dev+0x60/0x9c [ef0d5e40] [c01b7d98] driver_attach+0x24/0x34 [ef0d5e50] [c01b7b20] bus_add_driver+0x1bc/0x280 [ef0d5e80] [c01b85b4] driver_register+0x70/0x168 [ef0d5ea0] [c01869a0] __pci_register_driver+0x5c/0xe4 [ef0d5ed0] [f11e88cc] ath_pci_init+0x28/0x38 [ath9k] [ef0d5ee0] [f11f104c] ath9k_init+0x4c/0xb0 [ath9k] [ef0d5ef0] [c0001cfc] do_one_initcall+0x40/0x1dc [ef0d5f20] [c0070a7c] sys_init_module+0xf4/0x21c [ef0d5f40] [c000fc58] ret_from_syscall+0x0/0x3c handlers: [f11e16ac] (ath_isr+0x0/0x1b4 [ath9k]) Disabling IRQ #17 The ath9k driver does not support MSI interrupts, so it has to use legacy ones. If MSI interrupts are disabled in the kernel configuration I get similar dump with e1000e driver. The patch I've sent fixes the problem with legacy interrupts. Felix. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] hwmon: (tmp421) Add nfactor support.
On Tue, 11 May 2010 21:03:27 +0200, Andre Prendel wrote:
On Mon, May 10, 2010 at 10:43:07AM -0400, Jeff Angielski wrote:
Hi Jeff,
A few comments below.
Add support for reading and writing the n-factor correction
registers. This is needed to compensate for the characteristics
of a particular sensor hanging off of the remote channels.
Signed-off-by: Jeff Angielski j...@theptrgroup.com
---
drivers/hwmon/tmp421.c | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index 738c472..c9e9855 100644
--- a/drivers/hwmon/tmp421.c
+++ b/drivers/hwmon/tmp421.c
@@ -49,6 +49,7 @@ enum chips { tmp421, tmp422, tmp423 };
static const u8 TMP421_TEMP_MSB[4] = { 0x00, 0x01, 0x02, 0x03 };
static const u8 TMP421_TEMP_LSB[4] = { 0x10, 0x11, 0x12, 0x13 };
+static const u8 TMP421_NFACTOR[3] = { 0x21, 0x22, 0x23 };
/* Flags */
#define TMP421_CONFIG_SHUTDOWN 0x40
@@ -157,6 +158,38 @@ static ssize_t show_fault(struct device *dev,
return sprintf(buf, 0\n);
}
+static ssize_t show_nfactor(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tmp421_data *data = i2c_get_clientdata(client);
+ int index = to_sensor_dev_attr(devattr)-index;
+ s8 nfactor;
+
+ mutex_lock(data-update_lock);
+ nfactor = i2c_smbus_read_byte_data(client, TMP421_NFACTOR[index-1]);
There should be spaces within the array index, [index - 1].
+ mutex_unlock(data-update_lock);
+
+ return sprintf(buf, %d\n, nfactor);
+}
I'de prefer implementing the sysfs access methods in a consistent way (see
other functions). That means adding the nfactor register to the tmp421_data
structure and using tmp421_update_device() to update the structure.
+static ssize_t set_nfactor(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tmp421_data *data = i2c_get_clientdata(client);
+ int index = to_sensor_dev_attr(devattr)-index;
+ int nfactor = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(data-update_lock);
+ i2c_smbus_write_byte_data(client, TMP421_NFACTOR[index-1],
Missing spaces in array index again.
+ SENSORS_LIMIT(nfactor, -128, 127));
+ mutex_unlock(data-update_lock);
+
+ return count;
+}
+
static mode_t tmp421_is_visible(struct kobject *kobj, struct attribute *a,
int n)
{
@@ -177,19 +210,28 @@ static mode_t tmp421_is_visible(struct kobject
*kobj, struct attribute *a,
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp_value, NULL, 0);
static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_temp_value, NULL, 1);
static SENSOR_DEVICE_ATTR(temp2_fault, S_IRUGO, show_fault, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp2_nfactor, S_IRUGO | S_IWUSR,
+ show_nfactor, set_nfactor, 1);
static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, show_temp_value, NULL, 2);
static SENSOR_DEVICE_ATTR(temp3_fault, S_IRUGO, show_fault, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp3_nfactor, S_IRUGO | S_IWUSR,
+ show_nfactor, set_nfactor, 2);
static SENSOR_DEVICE_ATTR(temp4_input, S_IRUGO, show_temp_value, NULL, 3);
static SENSOR_DEVICE_ATTR(temp4_fault, S_IRUGO, show_fault, NULL, 3);
+static SENSOR_DEVICE_ATTR(temp4_nfactor, S_IRUGO | S_IWUSR,
+ show_nfactor, set_nfactor, 3);
static struct attribute *tmp421_attr[] = {
sensor_dev_attr_temp1_input.dev_attr.attr,
sensor_dev_attr_temp2_input.dev_attr.attr,
sensor_dev_attr_temp2_fault.dev_attr.attr,
+ sensor_dev_attr_temp2_nfactor.dev_attr.attr,
sensor_dev_attr_temp3_input.dev_attr.attr,
sensor_dev_attr_temp3_fault.dev_attr.attr,
+ sensor_dev_attr_temp3_nfactor.dev_attr.attr,
sensor_dev_attr_temp4_input.dev_attr.attr,
sensor_dev_attr_temp4_fault.dev_attr.attr,
+ sensor_dev_attr_temp4_nfactor.dev_attr.attr,
NULL
};
Any hope to standardize on the sysfs attribute files and units? So that
other drivers can implement the same interface.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] hwmon: (tmp421) Add nfactor support.
On 05/11/2010 03:03 PM, Andre Prendel wrote:
On Mon, May 10, 2010 at 10:43:07AM -0400, Jeff Angielski wrote:
Hi Jeff,
A few comments below.
Add support for reading and writing the n-factor correction
registers. This is needed to compensate for the characteristics
of a particular sensor hanging off of the remote channels.
Signed-off-by: Jeff Angielskij...@theptrgroup.com
---
drivers/hwmon/tmp421.c | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index 738c472..c9e9855 100644
--- a/drivers/hwmon/tmp421.c
+++ b/drivers/hwmon/tmp421.c
@@ -49,6 +49,7 @@ enum chips { tmp421, tmp422, tmp423 };
static const u8 TMP421_TEMP_MSB[4]= { 0x00, 0x01, 0x02, 0x03 };
static const u8 TMP421_TEMP_LSB[4]= { 0x10, 0x11, 0x12, 0x13 };
+static const u8 TMP421_NFACTOR[3] = { 0x21, 0x22, 0x23 };
/* Flags */
#define TMP421_CONFIG_SHUTDOWN0x40
@@ -157,6 +158,38 @@ static ssize_t show_fault(struct device *dev,
return sprintf(buf, 0\n);
}
+static ssize_t show_nfactor(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tmp421_data *data = i2c_get_clientdata(client);
+ int index = to_sensor_dev_attr(devattr)-index;
+ s8 nfactor;
+
+ mutex_lock(data-update_lock);
+ nfactor = i2c_smbus_read_byte_data(client, TMP421_NFACTOR[index-1]);
There should be spaces within the array index, [index - 1].
Ok.
+ mutex_unlock(data-update_lock);
+
+ return sprintf(buf, %d\n, nfactor);
+}
I'de prefer implementing the sysfs access methods in a consistent way (see
other functions). That means adding the nfactor register to the tmp421_data
structure and using tmp421_update_device() to update the structure.
I did this on purpose since the nfactor typically only changes once at
runtime when you program it for your sensor. It seemed like a waste of
processing power and i2c bandwidth to read a pseudo static register
over and over again.
It can easily be changed if that's what will help the community the best.
+static ssize_t set_nfactor(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tmp421_data *data = i2c_get_clientdata(client);
+ int index = to_sensor_dev_attr(devattr)-index;
+ int nfactor = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(data-update_lock);
+ i2c_smbus_write_byte_data(client, TMP421_NFACTOR[index-1],
Missing spaces in array index again.
Ok.
--
Jeff Angielski
The PTR Group
www.theptrgroup.com
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: eeh: Fix oops when probing in early boot
The needs_freset bit went in since the last time I touched all this code, so I don't think this will affect ipr at least. The way this works for the ipr adapters we needed a warm reset for was, we would get the hot reset in the generic EEH code, the the ipr driver would come along after that and issue a warm reset to get the adapter in a usable state. Now that the needs_freset feature is there, we could set that in ipr for the adapters we need a warm reset for and get rid of the useless hot reset. A quick grep through the code shows that qlogic is the one user of this feature. How early is this? I assume this is pre driver load time, in which case even if we could check the flag it wouldn't be set yet... Thanks, Brian On 05/11/2010 01:59 PM, Linas Vepstas wrote: On 10 May 2010 20:38, Anton Blanchard an...@samba.org wrote: If we take an EEH early enough, we oops: Call Trace: [c00010483770] [c0013ee4] .show_stack+0xd8/0x218 (unreliable) [c00010483850] [c0658940] .dump_stack+0x28/0x3c [c000104838d0] [c0057a68] .eeh_dn_check_failure+0x2b8/0x304 [c00010483990] [c00259c8] .rtas_read_config+0x120/0x168 [c00010483a40] [c0025af4] .rtas_pci_read_config+0xe4/0x124 [c00010483af0] [c037af18] .pci_bus_read_config_word+0xac/0x104 [c00010483bc0] [c08fec98] .pcibios_allocate_resources+0x7c/0x220 [c00010483c90] [c08feed8] .pcibios_resource_survey+0x9c/0x418 [c00010483d80] [c08fea10] .pcibios_init+0xbc/0xf4 [c00010483e20] [c0009844] .do_one_initcall+0x98/0x1d8 [c00010483ed0] [c08f0560] .kernel_init+0x228/0x2e8 [c00010483f90] [c0031a08] .kernel_thread+0x54/0x70 EEH: Detected PCI bus error on device null EEH: This PCI device has failed 1 times in the last hour: EEH: location=U78A5.001.WIH8464-P1 driver= pci addr=0001:00:01.0 EEH: of node=/p...@8002209/u...@1 EEH: PCI device/vendor: 00351033 EEH: PCI cmd/status register: 12100146 Unable to handle kernel paging request for data at address 0x0468 Oops: Kernel access of bad area, sig: 11 [#1] NIP [c0057610] .rtas_set_slot_reset+0x38/0x10c LR [c0058724] .eeh_reset_device+0x5c/0x124 Call Trace: [cbc6bd00] [c005a0e0] .pcibios_remove_pci_devices+0x7c/0xb0 (unreliable) [cbc6bd90] [c0058724] .eeh_reset_device+0x5c/0x124 [cbc6be40] [c00589c0] .handle_eeh_events+0x1d4/0x39c [cbc6bf00] [c0059124] .eeh_event_handler+0xf0/0x188 [cbc6bf90] [c0031a08] .kernel_thread+0x54/0x70 We called rtas_set_slot_reset while scanning the bus and before the pci_dn to pcidev mapping has been created. Since we only need the pcidev to work out the type of reset and that only gets set after the module for the device loads, lets just do a hot reset if the pcidev is NULL. Signed-off-by: Anton Blanchard an...@samba.org --- Acked-by: Linas Vepstas linasveps...@gmail.com I'm cc'ing Brian King, he's the one who figured out the proper fix for a hot-reset/fundamental-reset hardware feature that added this line of code. The question is -- when the system finishes booting, and the module finally loads, will the device be found in a usable state and/or will it automatically reset to a usable state? --linas Index: linux-2.6/arch/powerpc/platforms/pseries/eeh.c === --- linux-2.6.orig/arch/powerpc/platforms/pseries/eeh.c 2010-05-10 17:25:10.703453565 +1000 +++ linux-2.6/arch/powerpc/platforms/pseries/eeh.c 2010-05-10 17:25:24.034323030 +1000 @@ -749,7 +749,7 @@ static void __rtas_set_slot_reset(struct /* Determine type of EEH reset required by device, * default hot reset or fundamental reset */ - if (dev-needs_freset) + if (dev dev-needs_freset) rtas_pci_slot_reset(pdn, 3); else rtas_pci_slot_reset(pdn, 1); -- Brian King Linux on Power Virtualization IBM Linux Technology Center (507) 253-8636 | t/l 553-8636 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] hwmon: (tmp421) Add nfactor support.
On Mon, May 10, 2010 at 10:43:07AM -0400, Jeff Angielski wrote:
Hi Jeff,
A few comments below.
Add support for reading and writing the n-factor correction
registers. This is needed to compensate for the characteristics
of a particular sensor hanging off of the remote channels.
Signed-off-by: Jeff Angielski j...@theptrgroup.com
---
drivers/hwmon/tmp421.c | 42 ++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/hwmon/tmp421.c b/drivers/hwmon/tmp421.c
index 738c472..c9e9855 100644
--- a/drivers/hwmon/tmp421.c
+++ b/drivers/hwmon/tmp421.c
@@ -49,6 +49,7 @@ enum chips { tmp421, tmp422, tmp423 };
static const u8 TMP421_TEMP_MSB[4] = { 0x00, 0x01, 0x02, 0x03 };
static const u8 TMP421_TEMP_LSB[4] = { 0x10, 0x11, 0x12, 0x13 };
+static const u8 TMP421_NFACTOR[3]= { 0x21, 0x22, 0x23 };
/* Flags */
#define TMP421_CONFIG_SHUTDOWN 0x40
@@ -157,6 +158,38 @@ static ssize_t show_fault(struct device *dev,
return sprintf(buf, 0\n);
}
+static ssize_t show_nfactor(struct device *dev,
+ struct device_attribute *devattr, char *buf)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tmp421_data *data = i2c_get_clientdata(client);
+ int index = to_sensor_dev_attr(devattr)-index;
+ s8 nfactor;
+
+ mutex_lock(data-update_lock);
+ nfactor = i2c_smbus_read_byte_data(client, TMP421_NFACTOR[index-1]);
There should be spaces within the array index, [index - 1].
+ mutex_unlock(data-update_lock);
+
+ return sprintf(buf, %d\n, nfactor);
+}
I'de prefer implementing the sysfs access methods in a consistent way (see
other functions). That means adding the nfactor register to the tmp421_data
structure and using tmp421_update_device() to update the structure.
+static ssize_t set_nfactor(struct device *dev,
+ struct device_attribute *devattr,
+ const char *buf, size_t count)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct tmp421_data *data = i2c_get_clientdata(client);
+ int index = to_sensor_dev_attr(devattr)-index;
+ int nfactor = simple_strtol(buf, NULL, 10);
+
+ mutex_lock(data-update_lock);
+ i2c_smbus_write_byte_data(client, TMP421_NFACTOR[index-1],
Missing spaces in array index again.
+ SENSORS_LIMIT(nfactor, -128, 127));
+ mutex_unlock(data-update_lock);
+
+ return count;
+}
+
static mode_t tmp421_is_visible(struct kobject *kobj, struct attribute *a,
int n)
{
@@ -177,19 +210,28 @@ static mode_t tmp421_is_visible(struct kobject
*kobj, struct attribute *a,
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp_value, NULL, 0);
static SENSOR_DEVICE_ATTR(temp2_input, S_IRUGO, show_temp_value, NULL, 1);
static SENSOR_DEVICE_ATTR(temp2_fault, S_IRUGO, show_fault, NULL, 1);
+static SENSOR_DEVICE_ATTR(temp2_nfactor, S_IRUGO | S_IWUSR,
+ show_nfactor, set_nfactor, 1);
static SENSOR_DEVICE_ATTR(temp3_input, S_IRUGO, show_temp_value, NULL, 2);
static SENSOR_DEVICE_ATTR(temp3_fault, S_IRUGO, show_fault, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp3_nfactor, S_IRUGO | S_IWUSR,
+ show_nfactor, set_nfactor, 2);
static SENSOR_DEVICE_ATTR(temp4_input, S_IRUGO, show_temp_value, NULL, 3);
static SENSOR_DEVICE_ATTR(temp4_fault, S_IRUGO, show_fault, NULL, 3);
+static SENSOR_DEVICE_ATTR(temp4_nfactor, S_IRUGO | S_IWUSR,
+ show_nfactor, set_nfactor, 3);
static struct attribute *tmp421_attr[] = {
sensor_dev_attr_temp1_input.dev_attr.attr,
sensor_dev_attr_temp2_input.dev_attr.attr,
sensor_dev_attr_temp2_fault.dev_attr.attr,
+ sensor_dev_attr_temp2_nfactor.dev_attr.attr,
sensor_dev_attr_temp3_input.dev_attr.attr,
sensor_dev_attr_temp3_fault.dev_attr.attr,
+ sensor_dev_attr_temp3_nfactor.dev_attr.attr,
sensor_dev_attr_temp4_input.dev_attr.attr,
sensor_dev_attr_temp4_fault.dev_attr.attr,
+ sensor_dev_attr_temp4_nfactor.dev_attr.attr,
NULL
};
Regards,
Andre
PS: CC'ed lm-sensors list
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Problem setting link_address too high on PowerPC 40x
Hi, I am working with the PowerPC 405 in the Virtex-II Pro FPGA. I've come across a possible problem where the device tree is located in at an address that the kernel cannot access if link_address (the location where zImage executes from, set in the wrapper script) is set too high (somewhere in the ballpark of 16 MB). Here is a summary of the problem: In arch/powerpc/boot/main.c, ft_addr (a pointer to the flat? device tree) is computed and then passed on to kentry to the kernel startup code. At startup, the kernel only has access via the TLB to the first 16 MB of memory which is initialized by initial_imu in arch/powerpc/kernel/head_40x.S. The problem is that ft_addr is located relative to link_address / zImage, but this address might be outside of the bounds of the 16MB initially mapped by the TLB. A symptom of this problem is that the kernel ceases to print any messages to the console because it could not read information about the console from the flat device tree. The last thing the user will see is this: zImage starting: loaded at 0x0400 (sp: 0x0430beb0) Allocating 0x6f11b0 bytes for kernel ... gunzipping (0x - 0x0400c000:0x0430a31a)...done 0x657000 bytes Linux/PowerPC load: console=ttyUL0 root=/dev/ram Finalizing device tree... flat tree at 0x4318300 ...and then the screen goes completely blank... And it seems that the kernel also eventually crashes (but I couldn't tell exactly what happened because __log_buf repeatedly gets corrupted with zeros whenever I try this particular experiment). Maybe there is also more to this problem too than just the ft_addr. -David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc,kexec: Speedup kexec hpte tear down
In message 1273561463.9209.138.ca...@concordia you wrote:
--=-S056dRzmrEHDBzKyyTOs
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, 2010-05-11 at 16:28 +1000, Michael Neuling wrote:
Currently for kexec the PTE tear down on 1TB segment systems normally
requires 3 hcalls for each PTE removal. On a machine with 32GB of
memory it can take around a minute to remove all the PTEs.
=20
..
- /* TODO: Use bulk call */
...
+ /* Read in batches of 4,
+* invalidate only valid entries not in the VRMA
+* hpte_count will be a multiple of 4
+ */
+ for (i =3D 0; i hpte_count; i +=3D 4) {
+ lpar_rc =3D plpar_pte_read_4_raw(0, i, (void *)ptes);
+ if (lpar_rc !=3D H_SUCCESS)
+ continue;
+ for (j =3D 0; j 4; j++){
+ if ((ptes[j].pteh HPTE_V_VRMA_MASK) =3D=3D
+ HPTE_V_VRMA_MASK)
+ continue;
+ if (ptes[j].pteh HPTE_V_VALID)
+ plpar_pte_remove_raw(0, i + j, 0,
+ (ptes[j].pteh), (ptes[j].ptel));
}
Have you tried using the bulk remove call, if none of the HPTEs are for
the VRMA? Rumour was it was slower/the-same, but that may have been
apocryphal.
No, I didn't try it.
I think the real solution is to ask FW for a new call to do it all for
us.
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc,kexec: Speedup kexec hpte tear down
On Wed, 2010-05-12 at 09:29 +1000, Michael Neuling wrote:
In message 1273561463.9209.138.ca...@concordia you wrote:
--=-S056dRzmrEHDBzKyyTOs
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Tue, 2010-05-11 at 16:28 +1000, Michael Neuling wrote:
Currently for kexec the PTE tear down on 1TB segment systems normally
requires 3 hcalls for each PTE removal. On a machine with 32GB of
memory it can take around a minute to remove all the PTEs.
=20
..
- /* TODO: Use bulk call */
...
+ /* Read in batches of 4,
+ * invalidate only valid entries not in the VRMA
+ * hpte_count will be a multiple of 4
+ */
+ for (i =3D 0; i hpte_count; i +=3D 4) {
+ lpar_rc =3D plpar_pte_read_4_raw(0, i, (void *)ptes);
+ if (lpar_rc !=3D H_SUCCESS)
+ continue;
+ for (j =3D 0; j 4; j++){
+ if ((ptes[j].pteh HPTE_V_VRMA_MASK) =3D=3D
+ HPTE_V_VRMA_MASK)
+ continue;
+ if (ptes[j].pteh HPTE_V_VALID)
+ plpar_pte_remove_raw(0, i + j, 0,
+ (ptes[j].pteh), (ptes[j].ptel));
}
Have you tried using the bulk remove call, if none of the HPTEs are for
the VRMA? Rumour was it was slower/the-same, but that may have been
apocryphal.
No, I didn't try it.
I think the real solution is to ask FW for a new call to do it all for
us.
Sure, you could theoretically still get a 4x speedup though by using the
bulk remove.
cheers
signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc,kexec: Speedup kexec hpte tear down
In message 1273624565.5738.8.ca...@concordia you wrote:
--=-wnrJa93KBardFtse2eHB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, 2010-05-12 at 09:29 +1000, Michael Neuling wrote:
=20
In message 1273561463.9209.138.ca...@concordia you wrote:
=20
--=3D-S056dRzmrEHDBzKyyTOs
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: quoted-printable
=20
On Tue, 2010-05-11 at 16:28 +1000, Michael Neuling wrote:
Currently for kexec the PTE tear down on 1TB segment systems normally
requires 3 hcalls for each PTE removal. On a machine with 32GB of
memory it can take around a minute to remove all the PTEs.
=3D20
..
- /* TODO: Use bulk call */
=20
...
+ /* Read in batches of 4,
+* invalidate only valid entries not in the VRMA
+* hpte_count will be a multiple of 4
+ */
+ for (i =3D3D 0; i hpte_count; i +=3D3D 4) {
+ lpar_rc =3D3D plpar_pte_read_4_raw(0, i, (void *)ptes);
+ if (lpar_rc !=3D3D H_SUCCESS)
+ continue;
+ for (j =3D3D 0; j 4; j++){
+ if ((ptes[j].pteh HPTE_V_VRMA_MASK) =3D3D=3D3
D
+ HPTE_V_VRMA_MASK)
+ continue;
+ if (ptes[j].pteh HPTE_V_VALID)
+ plpar_pte_remove_raw(0, i + j, 0,
+ (ptes[j].pteh), (ptes[j].ptel
));
}
=20
Have you tried using the bulk remove call, if none of the HPTEs are for
the VRMA? Rumour was it was slower/the-same, but that may have been
apocryphal.
=20
No, I didn't try it.
=20
I think the real solution is to ask FW for a new call to do it all for
us.
Sure, you could theoretically still get a 4x speedup though by using the
bulk remove.
We probably only do the remove on 1% of the hptes now. So I doubt we
would get a speedup since most of the time we aren't do the remove
anymore.
Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc,kexec: Speedup kexec hpte tear down
On Wed, May 12, 2010 at 10:43:08AM +1000, Michael Neuling wrote: We probably only do the remove on 1% of the hptes now. So I doubt we would get a speedup since most of the time we aren't do the remove anymore. It would be nice to have some actual numbers. Could you add some counters and print the results at the end? (Or don't you have any way to print things at that stage?) Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc,kexec: Speedup kexec hpte tear down
We probably only do the remove on 1% of the hptes now. So I doubt we would get a speedup since most of the time we aren't do the remove anymore. It would be nice to have some actual numbers. Could you add some counters and print the results at the end? (Or don't you have any way to print things at that stage?) Printing is hard at that point but I think we can do it. I'll try to when I get some time. A heavily loaded system which kdumps will need a lot more hptes removes than kexec, so stats for both these cases might be useful also. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc,kexec: Speedup kexec hpte tear down
On Wed, 2010-05-12 at 11:06 +1000, Michael Neuling wrote: We probably only do the remove on 1% of the hptes now. So I doubt we would get a speedup since most of the time we aren't do the remove anymore. It would be nice to have some actual numbers. Could you add some counters and print the results at the end? (Or don't you have any way to print things at that stage?) Printing is hard at that point but I think we can do it. I'll try to when I get some time. A version of udbg_putcLP() that uses a raw hcall should work, or there was code added to purgatory recently to print to the HV console which you could nick. A heavily loaded system which kdumps will need a lot more hptes removes than kexec, so stats for both these cases might be useful also. Yeah, or even a system that is kexec'ed while lots of stuff is still running. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Fix UART clocks on 440SPe
The code to fixup the serial ports on 440SPe uses the incorrect addresses for these. This fixes it. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- I'm surprised nobody noticed, serial is pretty busted for me without that patch :-) diff --git a/arch/powerpc/boot/4xx.c b/arch/powerpc/boot/4xx.c index 27db893..627de25 100644 --- a/arch/powerpc/boot/4xx.c +++ b/arch/powerpc/boot/4xx.c @@ -544,9 +544,9 @@ void ibm440spe_fixup_clocks(unsigned int sys_clk, unsigned int plb_clk = __ibm440eplike_fixup_clocks(sys_clk, tmr_clk, 1); /* serial clocks beed fixup based on int/ext */ - eplike_fixup_uart_clk(0, /plb/opb/ser...@1200, ser_clk, plb_clk); - eplike_fixup_uart_clk(1, /plb/opb/ser...@1300, ser_clk, plb_clk); - eplike_fixup_uart_clk(2, /plb/opb/ser...@1600, ser_clk, plb_clk); + eplike_fixup_uart_clk(0, /plb/opb/ser...@f200, ser_clk, plb_clk); + eplike_fixup_uart_clk(1, /plb/opb/ser...@f300, ser_clk, plb_clk); + eplike_fixup_uart_clk(2, /plb/opb/ser...@f600, ser_clk, plb_clk); } void ibm405gp_fixup_clocks(unsigned int sys_clk, unsigned int ser_clk) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
440SPe/Katmai PCIe problems
Hi Stefan ! (Or somebody from AMCC) I noticed we still have this old problem on PCIe where some cards don't seem to work. The link trains but they don't respond on config space. This is the case for example of that Sunix quad USB card. It seems to be related to the kind of TI PCIe - PCI bridge on these though. Have anybody tracked down the root cause of the problem ? Some say that it could be that the bridge doesn't cope with the double reset (uboot then kernel). Would it be possible to tell uboot to avoid touching the PCIe interface completely so the kernel is the first one to get in ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] kexec-tools, ppc64: Fix segfault parsing DR memory property
In message 4be9102c.6040...@axio.ms you wrote:
add_dyn_reconf_usable_mem_property() iterates over memory spans
in /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory and intersects
these with usablemem_rgns ranges. Not only did it seem to write
null properties for every range that didn't match, but it used an unchecked
fixed-size array which will overrun on machines with lots of LMBs.
This patch stops add_dyn_reconf_usable_mem_property() from adding null ranges
to the linux,drconf-usable-memory property and removes its fixed-size array,
as well as the array in add_usable_mem_property, in lieu of malloc/realloc/fr
ee.
Thanks matt!
Acked-by: Michael Neuling mi...@neuling.org
Signed-off-by: Matt Evans m...@ozlabs.org
---
kexec/arch/ppc64/fs2dt.c | 66 +---
-
1 files changed, 54 insertions(+), 12 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 762bf04..7470132 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -37,7 +37,7 @@
#define NAMESPACE 16384 /* max bytes for property names */
#define INIT_TREE_WORDS 65536/* Initial num words for prop values */
#define MEMRESERVE 256 /* max number of reserved memory blocks
*/
-#define MAX_MEMORY_RANGES 1024
+#define MEM_RANGE_CHUNK_SZ 2048 /* Initial num dwords for mem ranges */
static char pathname[MAXPATH], *pathstart;
static char propnames[NAMESPACE] = { 0 };
@@ -148,7 +148,8 @@ static void add_dyn_reconf_usable_mem_property(int fd)
{
char fname[MAXPATH], *bname;
uint64_t buf[32];
- uint64_t ranges[2*MAX_MEMORY_RANGES];
+ uint64_t *ranges;
+ int ranges_size = MEM_RANGE_CHUNK_SZ;
uint64_t base, end, loc_base, loc_end;
size_t i, rngs_cnt, range;
int rlen = 0;
@@ -165,6 +166,11 @@ static void add_dyn_reconf_usable_mem_property(int fd)
die(unrecoverable error: error seeking in \%s\: %s\n,
pathname, strerror(errno));
+ ranges = malloc(ranges_size*8);
+ if (!ranges)
+ die(unrecoverable error: can't alloc %d bytes for ranges.\n,
+ ranges_size*8);
+
rlen = 0;
for (i = 0; i num_of_lmbs; i++) {
if (read(fd, buf, 24) 0)
@@ -180,24 +186,41 @@ static void add_dyn_reconf_usable_mem_property(int fd)
rngs_cnt = 0;
for (range = 0; range usablemem_rgns.size; range++) {
+ int add = 0;
loc_base = usablemem_rgns.ranges[range].start;
loc_end = usablemem_rgns.ranges[range].end;
if (loc_base = base loc_end = end) {
- ranges[rlen++] = loc_base;
- ranges[rlen++] = loc_end - loc_base;
- rngs_cnt++;
+ add = 1;
} else if (base loc_end end loc_base) {
if (loc_base base)
loc_base = base;
if (loc_end end)
loc_end = end;
+ add = 1;
+ }
+
+ if (add) {
+ if (rlen = (ranges_size-2)) {
+ ranges_size += MEM_RANGE_CHUNK_SZ;
+ ranges = realloc(ranges, ranges_size*8)
;
+ if (!ranges)
+ die(unrecoverable error: can't
+ realloc %d bytes for
+ ranges.\n,
+ ranges_size*8);
+ }
ranges[rlen++] = loc_base;
ranges[rlen++] = loc_end - loc_base;
rngs_cnt++;
}
}
- /* Store the count of (base, size) duple */
- ranges[tmp_indx] = rngs_cnt;
+ if (rngs_cnt == 0) {
+ /* Don't store anything for unwritten iterations! */
+ rlen = tmp_indx;
+ } else {
+ /* Store the count of (base, size) duple */
+ ranges[tmp_indx] = rngs_cnt;
+ }
}
rlen = rlen * sizeof(uint64_t);
@@ -210,7 +233,8 @@ static void add_dyn_reconf_usable_mem_property(int fd)
*dt++ = propnum(linux,drconf-usable-memory);
if ((rlen = 8) ((unsigned long)dt 0x4))
dt++;
- memcpy(dt, ranges, rlen);
+ memcpy(dt, ranges, rlen);
+ free(ranges);
dt += (rlen + 3)/4;
}
@@ -218,7 +242,8 @@ static void add_usable_mem_property(int fd,
Re: 440SPe/Katmai PCIe problems
On Wed, 2010-05-12 at 12:40 +1000, Benjamin Herrenschmidt wrote: Hi Stefan ! (Or somebody from AMCC) I noticed we still have this old problem on PCIe where some cards don't seem to work. The link trains but they don't respond on config space. This is the case for example of that Sunix quad USB card. It seems to be related to the kind of TI PCIe - PCI bridge on these though. Have anybody tracked down the root cause of the problem ? Some say that it could be that the bridge doesn't cope with the double reset (uboot then kernel). Would it be possible to tell uboot to avoid touching the PCIe interface completely so the kernel is the first one to get in ? Actually... the card works in the Canyonlands using the latest u-boot from ftp.denx.de (u-boot-nand.bin-2009.11.1), though interestingly enough, this u-boot fails to detect an XGI Z11 video card that I have, whichever slot I put it in. in fact, the kernel itself detects the card and times out trying to get a link. It works with whatever u-boot I used to have in there (and no longer do ... oops :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 0/3] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XVIII
Hi Ben/Paul, Please find a new version of the patchset that implements hw-breakpoint interfaces for PowerPC Book III S. The changes in this version over the previous version are as listed below, and are the result of addressing comments received for the previous version. Changelog - ver XVIII (Version XVII: linuxppc-dev ref: 20100414034340.ga6...@in.ibm.com) - hw-breakpoint restoration variables are cleaned-up before unregistration through a new function hook arch_unregister_hw_breakpoint(). - emulate_single_step() now notifies DIE_SSTEP to registered handlers; causes single_step_dabr_instruction() to be invoked after alignment_exception. - SIGTRAP is no longer generated for non-ptrace user-space breakpoints. - Slight code restructuring for brevity and style corrections. Kindly accept them to be a part of -next tree. Thanks, K.Prasad Changelog - ver XVII (Version XVI: linuxppc-dev ref: 20100330095809.ga14...@in.ibm.com) - CONFIG_HAVE_HW_BREAKPOINT is now used to define the scope of the new code (in lieu of CONFIG_PPC_BOOK3S_64). - CONFIG_HAVE_HW_BREAKPOINT is now dependant upon CONFIG_PERF_EVENTS and CONFIG_PPC_BOOK3S_64 (to overcome build failures under certain configs). - Included a target in arch/powerpc/lib/Makefile to build sstep.o when HAVE_HW_BREAKPOINT. - Added a dummy definition for hw_breakpoint_disable() when !HAVE_HW_BREAKPOINT. - Tested builds under defconfigs for ppc64, cell and g5 (found no patch induced failures). Changelog - ver XVI (Version XV: linuxppc-dev ref: 20100323140639.ga21...@in.ibm.com) - Used a new config option CONFIG_PPC_BOOK3S_64 (in lieu of CONFIG_PPC64/CPU_FTR_HAS_DABR) to limit the scope of the new code. - Disabled breakpoints before kexec of the machine using hw_breakpoint_disable(). - Minor optimisation in exception-64s.S to check for data breakpoint exceptions in DSISR finally (after check for other causes) + changes in code comments and representation of DSISR_DABRMATCH constant. - Rebased to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6. Changelog - ver XV (Version XIV: linuxppc-dev ref: 20100308181232.ga3...@in.ibm.com) - Additional patch to disable interrupts during data breakpoint exception handling. - Moved HBP_NUM definition to cputable.h under a new CPU_FTR definition (CPU_FTR_HAS_DABR). - Filtering of extraneous exceptions (due to accesses outside symbol length) is by-passed for ptrace requests. - Removed flush_ptrace_hw_breakpoint() from __switch_to() due to incorrect coding placement. - Changes to code comments as per community reviews for previous version. - Minor coding-style changes in hw_breakpoint.c as per review comments. - Re-based to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6 Changelog - ver XIV (Version XIII: linuxppc-dev ref: 20100215055605.gb3...@in.ibm.com) - Removed the 'name' field from 'struct arch_hw_breakpoint'. - All callback invocations through bp-overflow_handler() are replaced with perf_bp_event(). - Removed the check for pre-existing single-stepping mode in hw_breakpoint_handler() as this check is unreliable while in kernel-space. Side effect of this change is the non-triggering of hw-breakpoints while single-stepping kernel through KGDB or Xmon. - Minor code-cleanups and addition of comments in hw_breakpoint_handler() and single_step_dabr_instruction(). - Re-based to commit 25cf84cf377c0aae5dbcf937ea89bc7893db5176 of linux-2.6 Changelog - ver XIII (Version XII: linuxppc-dev ref: 20100121084640.ga3...@in.ibm.com) - Fixed a bug for user-space breakpoints (triggered following the failure of a breakpoint request). - Re-based on commit 724e6d3fe8003c3f60bf404bf22e4e331327c596 of linux-2.6 Changelog - ver XII (Version XI: linuxppc-dev ref: 20100119091234.ga9...@in.ibm.com) - Unset MSR_SE only if kernel was not previously in single-step mode. - Pre-emption is now enabled before returning from the hw-breakpoint exception handler. - Variables to track the source of single-step exception (breakpoint from kernel, user-space vs single-stepping due to other requests) are added. - Extraneous hw-breakpoint exceptions (due to memory accesses lying outside monitored symbol length) is now done for both kernel and user-space (previously only user-space). - single_step_dabr_instruction() now returns NOTIFY_DONE if kernel was in single-step mode even before the hw-breakpoint. This enables other users of single-step mode to be notified of the exception. - User-space instructions are not emulated from kernel-space, they are instead single-stepped. Changelog - ver XI -- (Version X: linuxppc-dev ref: 20091211160144.ga23...@in.ibm.com) - Conditionally unset MSR_SE in the single-step handler - Added comments to explain the duration and need for pre-emption disable following hw-breakpoint
[Patch 1/3] PPC64-HWBKPT: Disable interrupts for data breakpoint exceptions
Data address breakpoint exceptions are currently handled along with page-faults
which require interrupts to remain in enabled state. Since exception handling
for data breakpoints aren't pre-empt safe, we handle them separately.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
Acked-by: Paul Mackerras pau...@samba.org
---
arch/powerpc/kernel/exceptions-64s.S | 13 -
arch/powerpc/mm/fault.c |5 +++--
2 files changed, 15 insertions(+), 3 deletions(-)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/exceptions-64s.S
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/exceptions-64s.S
@@ -735,8 +735,11 @@ _STATIC(do_hash_page)
std r3,_DAR(r1)
std r4,_DSISR(r1)
- andis. r0,r4,0xa450/* weird error? */
+ andis. r0,r4,0xa410/* weird error? */
bne-handle_page_fault /* if not, try to insert a HPTE */
+ andis. r0,r4,dsisr_dabrma...@h
+ bne-handle_dabr_fault
+
BEGIN_FTR_SECTION
andis. r0,r4,0x0020/* Is it a segment table fault? */
bne-do_ste_alloc/* If so handle it */
@@ -823,6 +826,14 @@ END_FW_FTR_SECTION_IFCLR(FW_FEATURE_ISER
bl .raw_local_irq_restore
b 11f
+/* We have a data breakpoint exception - handle it */
+handle_dabr_fault:
+ ld r4,_DAR(r1)
+ ld r5,_DSISR(r1)
+ addir3,r1,STACK_FRAME_OVERHEAD
+ bl .do_dabr
+ b .ret_from_except_lite
+
/* Here we have a page fault that hash_page can't handle. */
handle_page_fault:
ENABLE_INTS
Index: linux-2.6.ppc64_test/arch/powerpc/mm/fault.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/mm/fault.c
+++ linux-2.6.ppc64_test/arch/powerpc/mm/fault.c
@@ -151,13 +151,14 @@ int __kprobes do_page_fault(struct pt_re
if (!user_mode(regs) (address = TASK_SIZE))
return SIGSEGV;
-#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
+#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE) || \
+defined(CONFIG_PPC_BOOK3S_64))
if (error_code DSISR_DABRMATCH) {
/* DABR match */
do_dabr(regs, address, error_code);
return 0;
}
-#endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
+#endif
if (in_atomic() || mm == NULL) {
if (!user_mode(regs))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 2/3] Allow arch-specific cleanup before breakpoint unregistration
Certain architectures (such as PowerPC Book III S) have a need to cleanup
data-structures before the breakpoint is unregistered. This patch introduces
an arch-specific hook in release_bp_slot() along with a weak definition in
the form of a stub funciton.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
kernel/hw_breakpoint.c | 12
1 file changed, 12 insertions(+)
Index: linux-2.6.ppc64_test/kernel/hw_breakpoint.c
===
--- linux-2.6.ppc64_test.orig/kernel/hw_breakpoint.c
+++ linux-2.6.ppc64_test/kernel/hw_breakpoint.c
@@ -203,6 +203,17 @@ static void toggle_bp_slot(struct perf_e
}
/*
+ * Function to perform processor-specific cleanup during unregistration
+ */
+__weak void arch_unregister_hw_breakpoint(struct perf_event *bp)
+{
+ /*
+* A weak stub function here for those archs that don't define
+* it inside arch/.../kernel/hw_breakpoint.c
+*/
+}
+
+/*
* Contraints to check before allowing this new breakpoint counter:
*
* == Non-pinned counter == (Considered as pinned for now)
@@ -280,6 +291,7 @@ void release_bp_slot(struct perf_event *
{
mutex_lock(nr_bp_mutex);
+ arch_unregister_hw_breakpoint(bp);
__release_bp_slot(bp);
mutex_unlock(nr_bp_mutex);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 3/3] PPC64-HWBKPT: Implement hw-breakpoints for PowerPC Book III S
Implement perf-events based hw-breakpoint interfaces for PowerPC Book III S
processors. These interfaces help arbitrate requests from various users and
schedules them as appropriate.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/Kconfig |1
arch/powerpc/include/asm/cputable.h |4
arch/powerpc/include/asm/hw_breakpoint.h | 45 +++
arch/powerpc/include/asm/processor.h |8
arch/powerpc/kernel/Makefile |1
arch/powerpc/kernel/hw_breakpoint.c | 354 +++
arch/powerpc/kernel/machine_kexec_64.c |3
arch/powerpc/kernel/process.c|6
arch/powerpc/kernel/ptrace.c | 64 +
arch/powerpc/kernel/traps.c |3
arch/powerpc/lib/Makefile|1
include/linux/hw_breakpoint.h|1
12 files changed, 491 insertions(+)
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,45 @@
+#ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
+#define _PPC_BOOK3S_64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+
+struct arch_hw_breakpoint {
+ u8 len; /* length of the target data symbol */
+ int type;
+ unsigned long address;
+};
+
+#include linux/kdebug.h
+#include asm/reg.h
+#include asm/system.h
+
+struct perf_event;
+struct pmu;
+struct perf_sample_data;
+
+#define HW_BREAKPOINT_ALIGN 0x7
+/* Maximum permissible length of any HW Breakpoint */
+#define HW_BREAKPOINT_LEN 0x8
+
+extern int arch_bp_generic_fields(int type, int *gen_bp_type);
+extern int arch_validate_hwbkpt_settings(struct perf_event *bp,
+ struct task_struct *tsk);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+int arch_install_hw_breakpoint(struct perf_event *bp);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+void hw_breakpoint_pmu_read(struct perf_event *bp);
+extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk);
+
+extern struct pmu perf_ops_bp;
+extern void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs);
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
+
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* __KERNEL__ */
+#endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -0,0 +1,354 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers. Derived from
+ * arch/x86/kernel/hw_breakpoint.c
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2009 IBM Corporation
+ * Author: K.Prasad pra...@linux.vnet.ibm.com
+ *
+ */
+
+#include linux/hw_breakpoint.h
+#include linux/notifier.h
+#include linux/kprobes.h
+#include linux/percpu.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/sched.h
+#include linux/init.h
+#include linux/smp.h
+
+#include asm/hw_breakpoint.h
+#include asm/processor.h
+#include asm/sstep.h
+
+/*
+ * Store the 'bp' that caused the hw-breakpoint exception just before we
+ * single-step. Use it to distinguish a single-step exception (due to a
+ * previous hw-breakpoint exception) from a normal one
+ */
+static DEFINE_PER_CPU(struct perf_event *, last_hit_bp);
+
+/*
+ * Stores the breakpoints currently in use on each breakpoint address
+ * register for every cpu
+ */
+static DEFINE_PER_CPU(struct perf_event *, bp_per_reg);
+
+/*
+ * Install a perf counter breakpoint.
+ *
+ * We seek a free debug address register and use it for this
+ * breakpoint.
+ *
+ * Atomic: we hold the counter-ctx-lock and we only handle variables
+ * and registers local to this cpu.
+ */
+int arch_install_hw_breakpoint(struct perf_event *bp)
+{
+ struct arch_hw_breakpoint *info = counter_arch_bp(bp);
+
Re: [Patch 2/2] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
On Wed, May 05, 2010 at 02:03:03AM +0530, K.Prasad wrote: On Mon, May 03, 2010 at 04:23:30PM +1000, Paul Mackerras wrote: On Wed, Apr 14, 2010 at 09:18:27AM +0530, K.Prasad wrote: [snipped] It has been pointed out to me before (Roland's mail Ref:linuxppc-dev message-id: 20100119100335.3eb62...@magilla.sf.frob.com) that there will be too many corner cases that will be difficult to foresee, however your above list appears to be exhaustive. While the alternatives to this being a fallback to one-shot breakpoints (thereby leading to confusing hw-breakpoint interface semantics), this is an attempt to generate continuous and 'trigger-after-execute' (for non-ptrace requests) breakpoint exceptions. I believe that, with the addressal of concerns cited above, the resultant patchset would be one that achieves the stated design goals with no loss to existing functionality. Hi Paul, I intend to send out another version of this patchset with fixes as described in my replies above (unless I hear objections to it :-)). Meanwhile, a little sickness had kept me away from working on this patchset. I have now posted a new version of the same here () which contains changes as described above. A few more changes to the patch is impending post merger of Frederic's patches (which are now in -tip) into mainline (ref: commit 73266fc1df2f94cf72b3beba3eee3b88ed0b0664 to 777d0411cd1e384115985dac5ccd42031e3eee2b); mainly due to the new ability for a per-task breakpoint to request kernel-space breakpoints (the notion of kernel- vs user-bp would also become obsolete, it is better to call them per-cpu vs per-task breakpoints). Also, I find that possibility of a kernel-thread specific breakpoint (which can migrate across CPUs) has not been thought and implemented well in this patch (will be much easier after merger of Frederic's patch). I would prefer to have atleast some version of the patch included in mainline before bringing in support for the same. Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: 440SPe/Katmai PCIe problems
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Tuesday, May 11, 2010 8:03 PM To: Stefan Roese Cc: linuxppc-dev; Pravin Bathija Subject: Re: 440SPe/Katmai PCIe problems On Wed, 2010-05-12 at 12:40 +1000, Benjamin Herrenschmidt wrote: Hi Stefan ! (Or somebody from AMCC) I noticed we still have this old problem on PCIe where some cards don't seem to work. The link trains but they don't respond on config space. This is the case for example of that Sunix quad USB card. It seems to be related to the kind of TI PCIe - PCI bridge on these though. Have anybody tracked down the root cause of the problem ? Some say that it could be that the bridge doesn't cope with the double reset (uboot then kernel). Would it be possible to tell uboot to avoid touching the PCIe interface completely so the kernel is the first one to get in ? Actually... the card works in the Canyonlands using the latest u-boot from ftp.denx.de (u-boot-nand.bin-2009.11.1), though interestingly enough, this u-boot fails to detect an XGI Z11 video card that I have, whichever slot I put it in. in fact, the kernel itself detects the card and times out trying to get a link. It works with whatever u-boot I used to have in there (and no longer do ... oops :-) Cheers, Ben. Ben, Thanks for bringing this to our attention. We'll research this issue. Regards, Pravin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] Fix kexec on powerpc32
Maxim Uvarov wrote on 2010-05-11 10:47 :
This patch is required in case if you are using new toolchains.
I'm on Debian/stable (binutils 2.18, gcc 4.3.2), so I applied your patches
to the latest -git checkout:
First, compilation fails with:
cc1: warnings being treated as errors
kexec/arch/ppc/kexec-ppc.c: In function ‘get_base_ranges’:
kexec/arch/ppc/kexec-ppc.c:258: error: value computed is not used
make: *** [kexec/arch/ppc/kexec-ppc.o] Error 1
Somehow a - hyphen made it into one of the functions:
--- a/kexec/arch/ppc/kexec-ppc.c
+++ b/kexec/arch/ppc/kexec-ppc.c
[...]
if (local_memory_ranges = max_memory_ranges) {
- fclose(file);
- break;
+ if (realloc_memory_ranges() 0){
+ - fclose(file);
Removing this, gets me further, until:
purgatory/arch/ppc/crt.o: In function `__lshrdi3':
(.text+0xf0): multiple definition of `__lshrdi3'
purgatory/arch/ppc/misc.o:(.text+0x50): first defined here
collect2: ld returned 1 exit status
make: *** [purgatory/purgatory.ro] Error 1
And has been defined in purgatory/arch/ppc/crt.S and
./purgatory/arch/ppc/misc.S. Removing it from e.g. crt.S
makes it compile, I have not tested it yet, though :-)
Thanks,
Christian.
PS: Where is -Werror defined? I could not find it anywhere in the kexec
source (execpt in arch/mips)...
--
make bzImage, not war
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
