Re: [PATCH v2] powerpc: Improve message for vio bus entitlement panic
Robert Jennings writes: Add information regarding the available and required entitlement amounts to the message displayed for the panic when insufficient entitlement is provided at boot. I'll queue this up for 2.6.28, unless you tell me it's needed for 2.6.27. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix memory leaks in QE library
On Mon, Aug 18, 2008 at 04:12:08PM -0500, Timur Tabi wrote: Fix two memory leaks in the Freescale QE library: add a missing kfree() in ucc_fast_init() if the ioremap() fails, and update ucc_fast_free() to call iounmap() on uf_regs. It's been pointed out in http://bugzilla.kernel.org/show_bug.cgi?id=11371 that ucc_slow suffers from the same (welll clsoe enough) 2 problems. Care to fix them aswell? Yours Tony linux.conf.auhttp://www.marchsouth.org/ Jan 19 - 24 2009 The Australian Linux Technical Conference! ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/5] powerpc: Make the 64-bit kernel as a position-independent executable
Geert Uytterhoeven writes: This part broke ppc32: | arch/powerpc/kernel/prom.c: In function 'early_init_devtree': | arch/powerpc/kernel/prom.c:1166: error: '__end_interrupts' undeclared (first use in this function) | arch/powerpc/kernel/prom.c:1166: error: (Each undeclared identifier is reported only once | arch/powerpc/kernel/prom.c:1166: error: for each function it appears in.) I'm not totally surprised I broke ppc32 somewhere along the line there. :) I think we will end up with having to have a #ifdef CONFIG_RELOCATABLE in there or maybe a test on PHYSICAL_START. It will depend a bit on whether we want to make relocatable 32-bit kernels as PIEs as well. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
libfdt: Add function to explicitly expand aliases
Kumar has already added alias expansion to fdt_path_offset().
However, in some circumstances it may be convenient for the user of
libfdt to explicitly get the string expansion of an alias. This patch
adds a function to do this, fdt_get_alias(), and uses it to implement
fdt_path_offset().
Signed-off-by: David Gibson [EMAIL PROTECTED]
Index: dtc/libfdt/fdt_ro.c
===
--- dtc.orig/libfdt/fdt_ro.c2008-08-20 15:59:56.0 +1000
+++ dtc/libfdt/fdt_ro.c 2008-08-20 15:59:56.0 +1000
@@ -141,17 +141,12 @@ int fdt_path_offset(const void *fdt, con
/* see if we have an alias */
if (*path != '/') {
- const char *q;
- int aliasoffset = fdt_path_offset(fdt, /aliases);
-
- if (aliasoffset 0)
- return -FDT_ERR_BADPATH;
+ const char *q = strchr(path, '/');
- q = strchr(path, '/');
if (!q)
q = end;
- p = fdt_getprop_namelen(fdt, aliasoffset, path, q - p, NULL);
+ p = fdt_get_alias_namelen(fdt, p, q - p);
if (!p)
return -FDT_ERR_BADPATH;
offset = fdt_path_offset(fdt, p);
@@ -302,6 +297,23 @@ uint32_t fdt_get_phandle(const void *fdt
return fdt32_to_cpu(*php);
}
+const char *fdt_get_alias_namelen(const void *fdt,
+ const char *name, int namelen)
+{
+ int aliasoffset;
+
+ aliasoffset = fdt_path_offset(fdt, /aliases);
+ if (aliasoffset 0)
+ return NULL;
+
+ return fdt_getprop_namelen(fdt, aliasoffset, name, namelen, NULL);
+}
+
+const char *fdt_get_alias(const void *fdt, const char *name)
+{
+ return fdt_get_alias_namelen(fdt, name, strlen(name));
+}
+
int fdt_get_path(const void *fdt, int nodeoffset, char *buf, int buflen)
{
int pdepth = 0, p = 0;
Index: dtc/libfdt/libfdt.h
===
--- dtc.orig/libfdt/libfdt.h2008-08-20 15:59:56.0 +1000
+++ dtc/libfdt/libfdt.h 2008-08-20 15:59:56.0 +1000
@@ -459,6 +459,32 @@ static inline void *fdt_getprop_w(void *
uint32_t fdt_get_phandle(const void *fdt, int nodeoffset);
/**
+ * fdt_get_namelen - get alias based on substring
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ * @namelen: number of characters of name to consider
+ *
+ * Identical to fdt_get_alias(), but only examine the first namelen
+ * characters of name for matching the alias name.
+ */
+const char *fdt_get_alias_namelen(const void *fdt,
+ const char *name, int namelen);
+
+/**
+ * fdt_get_alias - retreive the path referenced by a given alias
+ * @fdt: pointer to the device tree blob
+ * @name: name of the alias th look up
+ *
+ * fdt_get_alias() retrieves the value of a given alias. That is, the
+ * value of the property named 'name' in the node /aliases.
+ *
+ * returns:
+ * a pointer to the expansion of the alias named 'name', of it exists
+ * NULL, if the given alias or the /aliases node does not exist
+ */
+const char *fdt_get_alias(const void *fdt, const char *name);
+
+/**
* fdt_get_path - determine the full path of a node
* @fdt: pointer to the device tree blob
* @nodeoffset: offset of the node whose path to find
Index: dtc/tests/get_alias.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ dtc/tests/get_alias.c 2008-08-20 15:59:56.0 +1000
@@ -0,0 +1,58 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Testcase for fdt_get_alias()
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include stdlib.h
+#include stdio.h
+#include string.h
+#include stdint.h
+
+#include fdt.h
+#include libfdt.h
+
+#include tests.h
+#include testdata.h
+
+void check_alias(void *fdt, const char *path, const char *alias)
+{
+ const char *aliaspath;
+
+ aliaspath = fdt_get_alias(fdt, alias);
+
+ if (path !aliaspath)
+ FAIL(fdt_get_alias(%s) failed\n, alias);
+
+ if (strcmp(aliaspath, path)
Re: [gmail] DMA Cache problem on PPC8248.
We are using PPC8248 provided by freescale and the kernel 2.6.10. I believe we have cache problem. We are allocating DMA buffers in our driver. If we increase the DMA buffer size the board hangs/halts(when try to load more applications). If we reduce the DMA buffer size, then we can run all our applications. Is there any way I can get around this problem. Have a look at the u-boot code for the 8245; I once submitted a patch for such a problem on an XPC8245 (experimental MPC8245). It's still in the code; but disabled right now. It might be the same silicon bug. -- greetz, marc Yeah, yeah, yeah nothing like a bomb to sober me up, I'm fine. Crichton - Suns and Lovers crichton 2.6.26 #1 PREEMPT Tue Jul 29 21:17:59 CDT 2008 armv5tel GNU/Linux signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Found the problem (or at least -a- problem), it's a gcc bug. Well, first I must say the code generated by -pg is just plain horrible :-) Appart from that, look at the exit of, for example, __d_lookup, as generated by gcc when ftrace is enabled: c00c0498: 38 60 00 00 li r3,0 c00c049c: 81 61 00 00 lwz r11,0(r1) c00c04a0: 80 0b 00 04 lwz r0,4(r11) c00c04a4: 7d 61 5b 78 mr r1,r11 c00c04a8: bb 0b ff e0 lmw r24,-32(r11) c00c04ac: 7c 08 03 a6 mtlrr0 c00c04b0: 4e 80 00 20 blr As you can see, it restores r1 -before- it pops r24..r31 off the stack ! I let you imagine what happens if an interrupt happens just in between those two instructions (mr and lmw). We don't do redzones on our ABI, so basically, the registers end up corrupted by the interrupt. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: CONFIG_BOOTX_TEXT breaks PowerBook 3400 with BootX
On Wed, 20 Aug 2008, Benjamin Herrenschmidt wrote: On Wed, 2008-08-20 at 03:23 +1000, Finn Thain wrote: ... The Debian Sarge 2.6.8-4 kernel does not seem to have this problem though kernel.org 2.6.16 and later versions do. Any ideas? How late have you tried ? I remember fixing something at one point... I've tried 2.6.26.2 (I think I also tried 2.6.22 and 2.6.25 a while ago). I did some more tests today. I found that 2.6.15 (ARCH=ppc) is fine, but 2.6.16 (ARCH=powerpc) has the bug. Finn Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [alsa-devel] [PATCH v2] duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE
At Tue, 19 Aug 2008 11:53:54 -0400,
roel kluin wrote:
Takashi Iwai wrote:
At Tue, 19 Aug 2008 08:15:05 +0200 (CEST),
Johannes Berg wrote:
roel kluin wrote:
untested, is it correct?
not a clue, do you know how long ago that was? :)
does the driver check endianness anywhere?
AFAIK snd-aoa supports only bit-endian formats (at least in
sound/aoa/soundbus/i2sbus-pcm.c), so this addition makes little
sense.
Better to drop the duplicated words there.
Thanks Johannes and Takashi,
FWIW this removes the duplicates.
---
Remove duplicate assignment of SNDRV_PCM_FMTBIT_S{16,24}_BE bits
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
Thanks, applied this one now.
Takashi
---
diff --git a/sound/aoa/codecs/snd-aoa-codec-tas.c
b/sound/aoa/codecs/snd-aoa-codec-tas.c
index 7a16a33..6c515b2 100644
--- a/sound/aoa/codecs/snd-aoa-codec-tas.c
+++ b/sound/aoa/codecs/snd-aoa-codec-tas.c
@@ -654,15 +654,13 @@ static struct snd_kcontrol_new bass_control = {
static struct transfer_info tas_transfers[] = {
{
/* input */
- .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
-SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
+ .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
SNDRV_PCM_RATE_48000,
.transfer_in = 1,
},
{
/* output */
- .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
-SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
+ .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S24_BE,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
SNDRV_PCM_RATE_48000,
.transfer_in = 0,
},
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: CONFIG_BOOTX_TEXT breaks PowerBook 3400 with BootX
On Wed, 2008-08-20 at 18:25 +1000, Finn Thain wrote: On Wed, 20 Aug 2008, Benjamin Herrenschmidt wrote: On Wed, 2008-08-20 at 03:23 +1000, Finn Thain wrote: ... The Debian Sarge 2.6.8-4 kernel does not seem to have this problem though kernel.org 2.6.16 and later versions do. Any ideas? How late have you tried ? I remember fixing something at one point... I've tried 2.6.26.2 (I think I also tried 2.6.22 and 2.6.25 a while ago). I did some more tests today. I found that 2.6.15 (ARCH=ppc) is fine, but 2.6.16 (ARCH=powerpc) has the bug. Thanks. I can get access to a 3400, I'll give it a try. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wednesday 20 August 2008 07:08, Steven Rostedt wrote: On Tue, 19 Aug 2008, Mathieu Desnoyers wrote: Ok, there are two cases where it's ok : 1 - in stop_machine, considering we are not touching code executed in NMI handlers. 2 - when using my replace_instruction_safe() which uses a temporary breakpoint when doing the instruction replacement. In those cases you could use text_poke_early(). See http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=b lob;f=arch/x86/kernel/immediate.c;h=7789e2c75bf03e645f15759d5dff0c1698493f 92;hb=HEAD For a use example. Basically it looks like : 360 pages[0] = virt_to_page((void *)bypass_eip); 361 vaddr = vmap(pages, 1, VM_MAP, PAGE_KERNEL); 362 BUG_ON(!vaddr); 363 text_poke_early(vaddr[bypass_eip ~PAGE_MASK], 364 (void *)addr, size); 365 /* 366 * Fill the rest with nops. 367 */ 368 len = NR_NOPS - size; 369 add_nops((void *) 370 vaddr[(bypass_eip ~PAGE_MASK) + size], 371 len); 372 print_dbg_bytes(inserted nops, 373 vaddr[(bypass_eip ~PAGE_MASK) + size], len); 374 vunmap(vaddr); vunmap can not be called with interrupts disabled, and this is exactly what my code does. It could be after the vmap rewrite (with a few other small tweaks). But a) it would be less robust when called from interrupt context and this code looks broken as it is WRT error handling; and b) it still costs several thousand cycles to vmap+touch+vunmap... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Steven Rostedt wrote: On Tue, 19 Aug 2008, Eran Liberty wrote: Steven Rostedt wrote: Testing tracer sched_switch: PASSED Testing tracer ftrace: PASSED Testing dynamic ftrace: PASSED Do you have PREEMPT_TRACER enabled, or any other tracer for that matter? -- Steve I can see stack trace context trace, but they are derived from other choices (I can not un select them) cat .config | grep TRACE CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_ARCH_TRACEHOOK=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_STACKTRACE=y # CONFIG_BACKTRACE_SELF_TEST is not set CONFIG_HAVE_FTRACE=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_FTRACE=y # CONFIG_SCHED_TRACER is not set CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_DYNAMIC_FTRACE=y CONFIG_FTRACE_SELFTEST=y CONFIG_FTRACE_STARTUP_TEST=y Oops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: NIP: c00bbb20 LR: c00bbb20 CTR: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix memory leaks in QE library
On Wed, Aug 20, 2008 at 1:38 AM, Tony Breeds [EMAIL PROTECTED] wrote: It's been pointed out in http://bugzilla.kernel.org/show_bug.cgi?id=11371 that ucc_slow suffers from the same (welll clsoe enough) 2 problems. Care to fix them aswell? Sure. I'll do a sweep o the QE code just to make sure there aren't even more. Of course, it would have been nice if someone had looked up the maintainer of the QE library in the MAINTAINERS file and notified me about these bugs. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/oprofile: fix mutex locking for spu-oprofile
I am fine with the changes with the exception of removing
add_event_entry() from include/linux/oprofile.h. Though there is no
usage of the function also in other architectures anymore, this change
in the API should be discussed on the oprofile mailing list. Please
separate the change in a different patch and submit it to the mailing
list. If there are no objections then, this change can go upstream as
well.
-Robert
On 11.08.08 09:25:07, Arnd Bergmann wrote:
From: Carl Love [EMAIL PROTECTED]
The issue is the SPU code is not holding the kernel mutex lock while
adding samples to the kernel buffer.
This patch creates per SPU buffers to hold the data. Data
is added to the buffers from in interrupt context. The data
is periodically pushed to the kernel buffer via a new Oprofile
function oprofile_put_buff(). The oprofile_put_buff() function
is called via a work queue enabling the funtion to acquire the
mutex lock.
The existing user controls for adjusting the per CPU buffer
size is used to control the size of the per SPU buffers.
Similarly, overflows of the SPU buffers are reported by
incrementing the per CPU buffer stats. This eliminates the
need to have architecture specific controls for the per SPU
buffers which is not acceptable to the OProfile user tool
maintainer.
The export of the oprofile add_event_entry() is removed as it
is no longer needed given this patch.
Note, this patch has not addressed the issue of indexing arrays
by the spu number. This still needs to be fixed as the spu
numbering is not guarenteed to be 0 to max_num_spus-1.
Signed-off-by: Carl Love [EMAIL PROTECTED]
Signed-off-by: Maynard Johnson [EMAIL PROTECTED]
Signed-off-by: Arnd Bergmann [EMAIL PROTECTED]
---
arch/powerpc/oprofile/cell/pr_util.h | 13 ++
arch/powerpc/oprofile/cell/spu_profiler.c |4 +-
arch/powerpc/oprofile/cell/spu_task_sync.c | 236
+---
drivers/oprofile/buffer_sync.c | 24 +++
drivers/oprofile/cpu_buffer.c | 15 ++-
drivers/oprofile/event_buffer.h|7 +
include/linux/oprofile.h | 16 +-
7 files changed, 279 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/oprofile/cell/pr_util.h
b/arch/powerpc/oprofile/cell/pr_util.h
index 22e4e8d..628009c 100644
--- a/arch/powerpc/oprofile/cell/pr_util.h
+++ b/arch/powerpc/oprofile/cell/pr_util.h
@@ -24,6 +24,11 @@
#define SKIP_GENERIC_SYNC 0
#define SYNC_START_ERROR -1
#define DO_GENERIC_SYNC 1
+#define SPUS_PER_NODE 8
+#define DEFAULT_TIMER_EXPIRE (HZ / 10)
+
+extern struct delayed_work spu_work;
+extern int spu_prof_running;
struct spu_overlay_info {/* map of sections within an SPU overlay */
unsigned int vma; /* SPU virtual memory address from elf */
@@ -62,6 +67,14 @@ struct vma_to_fileoffset_map { /* map of sections
within an SPU program */
};
+struct spu_buffer {
+ int last_guard_val;
+ int ctx_sw_seen;
+ unsigned long *buff;
+ unsigned int head, tail;
+};
+
+
/* The three functions below are for maintaining and accessing
* the vma-to-fileoffset map.
*/
diff --git a/arch/powerpc/oprofile/cell/spu_profiler.c
b/arch/powerpc/oprofile/cell/spu_profiler.c
index 380d7e2..6edaebd 100644
--- a/arch/powerpc/oprofile/cell/spu_profiler.c
+++ b/arch/powerpc/oprofile/cell/spu_profiler.c
@@ -23,12 +23,11 @@
static u32 *samples;
-static int spu_prof_running;
+int spu_prof_running;
static unsigned int profiling_interval;
#define NUM_SPU_BITS_TRBUF 16
#define SPUS_PER_TB_ENTRY 4
-#define SPUS_PER_NODE 8
#define SPU_PC_MASK 0x
@@ -208,6 +207,7 @@ int start_spu_profiling(unsigned int cycles_reset)
spu_prof_running = 1;
hrtimer_start(timer, kt, HRTIMER_MODE_REL);
+ schedule_delayed_work(spu_work, DEFAULT_TIMER_EXPIRE);
return 0;
}
diff --git a/arch/powerpc/oprofile/cell/spu_task_sync.c
b/arch/powerpc/oprofile/cell/spu_task_sync.c
index 2a9b4a0..2949126 100644
--- a/arch/powerpc/oprofile/cell/spu_task_sync.c
+++ b/arch/powerpc/oprofile/cell/spu_task_sync.c
@@ -35,7 +35,102 @@ static DEFINE_SPINLOCK(buffer_lock);
static DEFINE_SPINLOCK(cache_lock);
static int num_spu_nodes;
int spu_prof_num_nodes;
-int last_guard_val[MAX_NUMNODES * 8];
+
+struct spu_buffer spu_buff[MAX_NUMNODES * SPUS_PER_NODE];
+struct delayed_work spu_work;
+static unsigned max_spu_buff;
+
+static void spu_buff_add(unsigned long int value, int spu)
+{
+ /* spu buff is a circular buffer. Add entries to the
+ * head. Head is the index to store the next value.
+ * The buffer is full when there is one available entry
+ * in the queue, i.e. head and tail can't be equal.
+ * That way we can tell the difference between the
+ * buffer being full versus empty.
+ *
+ * ASSUPTION: the buffer_lock is held when this function
+
Re: powerpc/cell/oprofile: fix mutex locking for spu-oprofile
On Wednesday 20 August 2008, Robert Richter wrote: I am fine with the changes with the exception of removing add_event_entry() from include/linux/oprofile.h. Though there is no usage of the function also in other architectures anymore, this change in the API should be discussed on the oprofile mailing list. Please separate the change in a different patch and submit it to the mailing list. If there are no objections then, this change can go upstream as well. As an explanation, the removal of add_event_entry is the whole point of this patch. add_event_entry must only be called with buffer_mutex held, but buffer_mutex itself is not exported. I'm pretty sure that no other user of add_event_entry exists, as it was exported specifically for the SPU support and that never worked. Any other (theoretical) code using it would be broken in the same way and need a corresponding fix. We can easily leave the declaration in place, but I'd recommend removing it eventually. If you prefer to keep it, how about marking it as __deprecated? Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/oprofile: fix mutex locking for spu-oprofile
On 20.08.08 14:05:31, Arnd Bergmann wrote: On Wednesday 20 August 2008, Robert Richter wrote: I am fine with the changes with the exception of removing add_event_entry() from include/linux/oprofile.h. Though there is no usage of the function also in other architectures anymore, this change in the API should be discussed on the oprofile mailing list. Please separate the change in a different patch and submit it to the mailing list. If there are no objections then, this change can go upstream as well. As an explanation, the removal of add_event_entry is the whole point of this patch. add_event_entry must only be called with buffer_mutex held, but buffer_mutex itself is not exported. Thanks for pointing this out. I'm pretty sure that no other user of add_event_entry exists, as it was exported specifically for the SPU support and that never worked. Any other (theoretical) code using it would be broken in the same way and need a corresponding fix. We can easily leave the declaration in place, but I'd recommend removing it eventually. If you prefer to keep it, how about marking it as __deprecated? No, since this is broken by design we remove it. The patch can go upstream as it is. Thanks, -Robert -- Advanced Micro Devices, Inc. Operating System Research Center email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/oprofile: fix mutex locking for spu-oprofile
On 11.08.08 09:25:07, Arnd Bergmann wrote: From: Carl Love [EMAIL PROTECTED] The issue is the SPU code is not holding the kernel mutex lock while adding samples to the kernel buffer. This patch creates per SPU buffers to hold the data. Data is added to the buffers from in interrupt context. The data is periodically pushed to the kernel buffer via a new Oprofile function oprofile_put_buff(). The oprofile_put_buff() function is called via a work queue enabling the funtion to acquire the mutex lock. The existing user controls for adjusting the per CPU buffer size is used to control the size of the per SPU buffers. Similarly, overflows of the SPU buffers are reported by incrementing the per CPU buffer stats. This eliminates the need to have architecture specific controls for the per SPU buffers which is not acceptable to the OProfile user tool maintainer. The export of the oprofile add_event_entry() is removed as it is no longer needed given this patch. Note, this patch has not addressed the issue of indexing arrays by the spu number. This still needs to be fixed as the spu numbering is not guarenteed to be 0 to max_num_spus-1. Signed-off-by: Carl Love [EMAIL PROTECTED] Signed-off-by: Maynard Johnson [EMAIL PROTECTED] Signed-off-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Robert Richter [EMAIL PROTECTED] -Robert -- Advanced Micro Devices, Inc. Operating System Research Center email: [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/4] kvmppc: add hypercall infrastructure - guest part
Arnd Bergmann wrote:
On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote:
+static inline long kvm_hypercall1(unsigned int nr, unsigned long p1)
+{
+ register unsigned long hcall asm (r0) = nr;
+ register unsigned long arg1 asm (r3) = p1;
+ register long ret asm (r11);
+
+ asm volatile(.long %1
+ : =r(ret)
+ : i(KVM_HYPERCALL_BIN), r(hcall), r(arg1)
+ : r4, r5, r6, r7, r8,
+ r9, r10, r12, cc);
+ return ret;
+}
What is the reasoning for making the calling convention different from
all the existing hcall interfaces here?
pseries uses r3 for the hcall number, lv1 and beat use r11, so using
r0 just for the sake of being different seems counterintuitive.
Arnd
Some documentation is here
http://kvm.qumranet.com/kvmwiki/PowerPC_Hypercall_ABI
As far as I remember it was oriented on system calls, from my point we
can still change it atm.
When we discussed about that I was too new to the power architecture to
really get all the details, but I assume Hollis and Jimi can answer you
that.
--
Grüsse / regards,
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
Arnd Bergmann wrote: On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote: Dependent on the already existing CONFIG_KVM_GUEST config option this patch changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping instructions. Maybe we should split the kvm guest otpimizations in two parts one for the overhead free optimizations and on for the rest that might add some complexity for non virtualized execution (like this one). Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED] How significant is the performance impact of this change for non-virtualized systems? If it's very low, maybe you should not bother with the #ifdef, and if it's noticable, you might be better off using dynamic patching for this. Arnd To be honest I unfortunately don't know how big the impact for non-virtualized systems is. I would like to test it, but without hardware performance counters on the core I have I'm not sure (yet) how to measure that in a good way - any suggestion welcome. I'm really sure that any jumping around style dynamic patching in the guest like function pointers etc will be slower than just let the load be there. Unfortunately I can not rewrite it from the hypervisor because for wrteei I would need a stwi to rewrite it in one instruction. The patch as it is today let you choose between 10% benefit for virtualized guest and an unkown but surely very small overhead on native hardware. -- Grüsse / regards, Christian Ehrhardt IBM Linux Technology Center, Open Virtualization ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wed, 20 Aug 2008, Eran Liberty wrote: Steven Rostedt wrote: On Tue, 19 Aug 2008, Eran Liberty wrote: Steven Rostedt wrote: Testing tracer sched_switch: PASSED Testing tracer ftrace: PASSED Testing dynamic ftrace: PASSED Do you have PREEMPT_TRACER enabled, or any other tracer for that matter? -- Steve I can see stack trace context trace, but they are derived from other choices (I can not un select them) Yeah, those are not bad. cat .config | grep TRACE CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_ARCH_TRACEHOOK=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_STACKTRACE=y # CONFIG_BACKTRACE_SELF_TEST is not set CONFIG_HAVE_FTRACE=y CONFIG_HAVE_DYNAMIC_FTRACE=y CONFIG_FTRACE=y # CONFIG_SCHED_TRACER is not set CONFIG_CONTEXT_SWITCH_TRACER=y CONFIG_DYNAMIC_FTRACE=y CONFIG_FTRACE_SELFTEST=y CONFIG_FTRACE_STARTUP_TEST=y You must not have PREEMPT on, so the PREEMPT_TRACER will not show up. The reason I asked, is that my PowerBook runs fine without PREEMPT_TRACER but is very unstable when I have PREEMPT_TRACER enabled. -- Steve Oops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: NIP: c00bbb20 LR: c00bbb20 CTR: ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wed, 20 Aug 2008, Benjamin Herrenschmidt wrote: Found the problem (or at least -a- problem), it's a gcc bug. Well, first I must say the code generated by -pg is just plain horrible :-) Appart from that, look at the exit of, for example, __d_lookup, as generated by gcc when ftrace is enabled: c00c0498: 38 60 00 00 li r3,0 c00c049c: 81 61 00 00 lwz r11,0(r1) c00c04a0: 80 0b 00 04 lwz r0,4(r11) c00c04a4: 7d 61 5b 78 mr r1,r11 c00c04a8: bb 0b ff e0 lmw r24,-32(r11) c00c04ac: 7c 08 03 a6 mtlrr0 c00c04b0: 4e 80 00 20 blr As you can see, it restores r1 -before- it pops r24..r31 off the stack ! I let you imagine what happens if an interrupt happens just in between those two instructions (mr and lmw). We don't do redzones on our ABI, so basically, the registers end up corrupted by the interrupt. Ouch! You've disassembled this without -pg too, and it does not have this bug? What version of gcc do you have? -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wed, 20 Aug 2008, Steven Rostedt wrote: On Wed, 20 Aug 2008, Benjamin Herrenschmidt wrote: Found the problem (or at least -a- problem), it's a gcc bug. Well, first I must say the code generated by -pg is just plain horrible :-) Appart from that, look at the exit of, for example, __d_lookup, as generated by gcc when ftrace is enabled: c00c0498: 38 60 00 00 li r3,0 c00c049c: 81 61 00 00 lwz r11,0(r1) c00c04a0: 80 0b 00 04 lwz r0,4(r11) c00c04a4: 7d 61 5b 78 mr r1,r11 c00c04a8: bb 0b ff e0 lmw r24,-32(r11) c00c04ac: 7c 08 03 a6 mtlrr0 c00c04b0: 4e 80 00 20 blr As you can see, it restores r1 -before- it pops r24..r31 off the stack ! I let you imagine what happens if an interrupt happens just in between those two instructions (mr and lmw). We don't do redzones on our ABI, so basically, the registers end up corrupted by the interrupt. Ouch! You've disassembled this without -pg too, and it does not have this bug? What version of gcc do you have? I have: gcc (Debian 4.3.1-2) 4.3.1 c00c64c8: 81 61 00 00 lwz r11,0(r1) c00c64cc: 7f 83 e3 78 mr r3,r28 c00c64d0: 80 0b 00 04 lwz r0,4(r11) c00c64d4: ba eb ff dc lmw r23,-36(r11) c00c64d8: 7d 61 5b 78 mr r1,r11 c00c64dc: 7c 08 03 a6 mtlrr0 c00c64e0: 4e 80 00 20 blr My version looks fine. I'm thinking that this is a separate issue than what Eran is seeing. Eran, can you do an objdump -dr vmlinux and search for __d_lookup, and print out the end of the function dump. Thanks, -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/oprofile: fix mutex locking for spu-oprofile
On Wednesday 20 August 2008, Robert Richter wrote: Signed-off-by: Carl Love [EMAIL PROTECTED] Signed-off-by: Maynard Johnson [EMAIL PROTECTED] Signed-off-by: Arnd Bergmann [EMAIL PROTECTED] Acked-by: Robert Richter [EMAIL PROTECTED] Thanks Robert. Paul, any chance we can still get this into 2.6.27? I've added the Ack and uploaded it again for you to pull from master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git merge Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
On Tuesday 19 August 2008, Josh Boyer wrote:
This adds a common board file for almost all of the simple PowerPC 44x
boards that exist today. This is intended to be a single place to add
support for boards that do not differ in platform support from most of the
evaluation boards that are used as reference platforms. Boards that have
specific requirements or custom hardware setup should still have their own
board.c file.
The code looks correct, but since this is going to be example code
that may get copied into other platforms, I would take extra care
for coding style:
+#include linux/init.h
+#include linux/of_platform.h
+
+#include asm/machdep.h
+#include asm/prom.h
+#include asm/udbg.h
+#include asm/time.h
+#include asm/uic.h
+#include asm/pci-bridge.h
+#include asm/ppc4xx.h
#include lines should be ordered alphabetically in an ideal world.
+static char *board[] __initdata = {
+ amcc,bamboo,
+ amcc,cayonlands,
+ ibm,ebony,
+ amcc,katmai,
+ amcc,rainier,
+ amcc,sequoia,
+ amcc,taishan,
+ NULL
+};
You don't need the NULL termination here, since the array is only
used statically and you can use ARRAY_SIZE().
+static int __init ppc44x_probe(void)
+{
+ unsigned long root = of_get_flat_dt_root();
+ int i = 0;
+
+ while (board[i]) {
+ if (of_flat_dt_is_compatible(root, board[i]))
+ break;
+ i++;
+ }
This looks like a for() loop in disguise, so you can better write
it as
int i;
for (i = 0; i ARRAY_SIZE(board); i++) {
if (of_flat_dt_is_compatible(root, board[i])) {
ppc_pci_flags = PPC_PCI_REASSIGN_ALL_RSRC;
return 1;
}
}
return 0;
Arnd
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Steven Rostedt wrote: On Wed, 20 Aug 2008, Steven Rostedt wrote: On Wed, 20 Aug 2008, Benjamin Herrenschmidt wrote: Found the problem (or at least -a- problem), it's a gcc bug. Well, first I must say the code generated by -pg is just plain horrible :-) Appart from that, look at the exit of, for example, __d_lookup, as generated by gcc when ftrace is enabled: c00c0498: 38 60 00 00 li r3,0 c00c049c: 81 61 00 00 lwz r11,0(r1) c00c04a0: 80 0b 00 04 lwz r0,4(r11) c00c04a4: 7d 61 5b 78 mr r1,r11 c00c04a8: bb 0b ff e0 lmw r24,-32(r11) c00c04ac: 7c 08 03 a6 mtlrr0 c00c04b0: 4e 80 00 20 blr As you can see, it restores r1 -before- it pops r24..r31 off the stack ! I let you imagine what happens if an interrupt happens just in between those two instructions (mr and lmw). We don't do redzones on our ABI, so basically, the registers end up corrupted by the interrupt. Ouch! You've disassembled this without -pg too, and it does not have this bug? What version of gcc do you have? I have: gcc (Debian 4.3.1-2) 4.3.1 c00c64c8: 81 61 00 00 lwz r11,0(r1) c00c64cc: 7f 83 e3 78 mr r3,r28 c00c64d0: 80 0b 00 04 lwz r0,4(r11) c00c64d4: ba eb ff dc lmw r23,-36(r11) c00c64d8: 7d 61 5b 78 mr r1,r11 c00c64dc: 7c 08 03 a6 mtlrr0 c00c64e0: 4e 80 00 20 blr My version looks fine. I'm thinking that this is a separate issue than what Eran is seeing. Eran, can you do an objdump -dr vmlinux and search for __d_lookup, and print out the end of the function dump. Thanks, -- Steve powerpc-linux-gnu-objdump -dr --start-address=0xc00bb584 vmlinux | head -n 100 vmlinux: file format elf32-powerpc Disassembly of section .text: c00bb584 __d_lookup: c00bb584: 7c 08 02 a6 mflrr0 c00bb588: 90 01 00 04 stw r0,4(r1) c00bb58c: 4b f5 5c 51 bl c00111dc _mcount c00bb590: 94 21 ff d0 stwur1,-48(r1) c00bb594: 7c 08 02 a6 mflrr0 c00bb598: 3d 20 9e 37 lis r9,-25033 c00bb59c: bf 01 00 10 stmwr24,16(r1) c00bb5a0: 61 29 00 01 ori r9,r9,1 c00bb5a4: 3d 60 c0 38 lis r11,-16328 c00bb5a8: 90 01 00 34 stw r0,52(r1) c00bb5ac: 7c 60 4a 78 xor r0,r3,r9 c00bb5b0: 54 00 d9 7e rlwinm r0,r0,27,5,31 c00bb5b4: 83 84 00 00 lwz r28,0(r4) c00bb5b8: 7c 3f 0b 78 mr r31,r1 c00bb5bc: 81 0b 1a 2c lwz r8,6700(r11) c00bb5c0: 39 6b 1a 2c addir11,r11,6700 c00bb5c4: 7c 00 e2 14 add r0,r0,r28 c00bb5c8: 81 4b 00 04 lwz r10,4(r11) c00bb5cc: 7c 09 4a 78 xor r9,r0,r9 c00bb5d0: 83 24 00 04 lwz r25,4(r4) c00bb5d4: 7d 29 44 30 srw r9,r9,r8 c00bb5d8: 81 0b 00 08 lwz r8,8(r11) c00bb5dc: 7d 29 02 78 xor r9,r9,r0 c00bb5e0: 83 04 00 08 lwz r24,8(r4) c00bb5e4: 7d 29 50 38 and r9,r9,r10 c00bb5e8: 55 29 10 3a rlwinm r9,r9,2,0,29 c00bb5ec: 7c 09 40 2e lwzxr0,r9,r8 c00bb5f0: 7c 9a 23 78 mr r26,r4 c00bb5f4: 7c 7b 1b 78 mr r27,r3 c00bb5f8: 2f 80 00 00 cmpwi cr7,r0,0 c00bb5fc: 7c 1e 03 78 mr r30,r0 c00bb600: 40 be 00 14 bne+cr7,c00bb614 __d_lookup+0x90 c00bb604: 48 00 00 7c b c00bb680 __d_lookup+0xfc c00bb608: 83 de 00 00 lwz r30,0(r30) c00bb60c: 2f 9e 00 00 cmpwi cr7,r30,0 c00bb610: 41 9e 00 70 beq-cr7,c00bb680 __d_lookup+0xfc c00bb614: 80 1e 00 00 lwz r0,0(r30) c00bb618: 2f 80 00 00 cmpwi cr7,r0,0 c00bb61c: 41 9e 00 08 beq-cr7,c00bb624 __d_lookup+0xa0 c00bb620: 7c 00 02 2c dcbtr0,r0 c00bb624: 3b be ff f4 addir29,r30,-12 c00bb628: 80 1d 00 18 lwz r0,24(r29) c00bb62c: 7f 80 e0 00 cmpwcr7,r0,r28 c00bb630: 40 9e ff d8 bne+cr7,c00bb608 __d_lookup+0x84 c00bb634: 80 1d 00 14 lwz r0,20(r29) c00bb638: 7f 80 d8 00 cmpwcr7,r0,r27 c00bb63c: 40 9e ff cc bne+cr7,c00bb608 __d_lookup+0x84 c00bb640: 81 3b 00 48 lwz r9,72(r27) c00bb644: 38 9d 00 18 addir4,r29,24 c00bb648: 2f 89 00 00 cmpwi cr7,r9,0 c00bb64c: 41 9e 00 50 beq-cr7,c00bb69c __d_lookup+0x118 c00bb650: 80 09 00 08 lwz r0,8(r9) c00bb654: 2f 80 00 00 cmpwi cr7,r0,0 c00bb658: 41 9e 00 44 beq-cr7,c00bb69c __d_lookup+0x118 c00bb65c: 7f 63 db 78 mr r3,r27 c00bb660: 7c 09 03 a6 mtctr r0 c00bb664: 7f 45 d3 78 mr r5,r26 c00bb668: 4e 80 04 21 bctrl c00bb66c: 2f 83 00 00 cmpwi cr7,r3,0 c00bb670: 41 9e 00 50 beq-cr7,c00bb6c0
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wed, 20 Aug 2008, Eran Liberty wrote: Steven Rostedt wrote: On Wed, 20 Aug 2008, Steven Rostedt wrote: On Wed, 20 Aug 2008, Benjamin Herrenschmidt wrote: Found the problem (or at least -a- problem), it's a gcc bug. Well, first I must say the code generated by -pg is just plain horrible :-) Appart from that, look at the exit of, for example, __d_lookup, as generated by gcc when ftrace is enabled: c00c0498: 38 60 00 00 li r3,0 c00c049c: 81 61 00 00 lwz r11,0(r1) c00c04a0: 80 0b 00 04 lwz r0,4(r11) c00c04a4: 7d 61 5b 78 mr r1,r11 c00c04a8: bb 0b ff e0 lmw r24,-32(r11) c00c04ac: 7c 08 03 a6 mtlrr0 c00c04b0: 4e 80 00 20 blr As you can see, it restores r1 -before- it pops r24..r31 off the stack ! I let you imagine what happens if an interrupt happens just in between those two instructions (mr and lmw). We don't do redzones on our ABI, so basically, the registers end up corrupted by the interrupt. Ouch! You've disassembled this without -pg too, and it does not have this bug? What version of gcc do you have? I have: gcc (Debian 4.3.1-2) 4.3.1 c00c64c8: 81 61 00 00 lwz r11,0(r1) c00c64cc: 7f 83 e3 78 mr r3,r28 c00c64d0: 80 0b 00 04 lwz r0,4(r11) c00c64d4: ba eb ff dc lmw r23,-36(r11) c00c64d8: 7d 61 5b 78 mr r1,r11 c00c64dc: 7c 08 03 a6 mtlrr0 c00c64e0: 4e 80 00 20 blr My version looks fine. I'm thinking that this is a separate issue than what Eran is seeing. Eran, can you do an objdump -dr vmlinux and search for __d_lookup, and print out the end of the function dump. Thanks, -- Steve powerpc-linux-gnu-objdump -dr --start-address=0xc00bb584 vmlinux | head -n 100 vmlinux: file format elf32-powerpc Disassembly of section .text: c00bb584 __d_lookup: [...] c00bb670: 41 9e 00 50 beq-cr7,c00bb6c0 __d_lookup+0x13c c00bb674: 83 de 00 00 lwz r30,0(r30) c00bb678: 2f 9e 00 00 cmpwi cr7,r30,0 c00bb67c: 40 9e ff 98 bne+cr7,c00bb614 __d_lookup+0x90 c00bb680: 38 60 00 00 li r3,0 c00bb684: 81 61 00 00 lwz r11,0(r1) c00bb688: 80 0b 00 04 lwz r0,4(r11) c00bb68c: 7d 61 5b 78 mr r1,r11 [ BUG HERE IF INTERRUPT HAPPENS ] c00bb690: bb 0b ff e0 lmw r24,-32(r11) c00bb694: 7c 08 03 a6 mtlrr0 c00bb698: 4e 80 00 20 blr Yep, you have the same bug in your compiler. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
On Wed, 20 Aug 2008 15:33:21 +0200 Arnd Bergmann [EMAIL PROTECTED] wrote: On Tuesday 19 August 2008, Josh Boyer wrote: This adds a common board file for almost all of the simple PowerPC 44x boards that exist today. This is intended to be a single place to add support for boards that do not differ in platform support from most of the evaluation boards that are used as reference platforms. Boards that have specific requirements or custom hardware setup should still have their own board.c file. The code looks correct, but since this is going to be example code that may get copied into other platforms, I would take extra care for coding style: Fair enough. Your comments all make sense to me. I'll fixup things and resend this one. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Steven Rostedt wrote: On Wed, 20 Aug 2008, Eran Liberty wrote: Steven Rostedt wrote: On Wed, 20 Aug 2008, Steven Rostedt wrote: On Wed, 20 Aug 2008, Benjamin Herrenschmidt wrote: Found the problem (or at least -a- problem), it's a gcc bug. Well, first I must say the code generated by -pg is just plain horrible :-) Appart from that, look at the exit of, for example, __d_lookup, as generated by gcc when ftrace is enabled: c00c0498: 38 60 00 00 li r3,0 c00c049c: 81 61 00 00 lwz r11,0(r1) c00c04a0: 80 0b 00 04 lwz r0,4(r11) c00c04a4: 7d 61 5b 78 mr r1,r11 c00c04a8: bb 0b ff e0 lmw r24,-32(r11) c00c04ac: 7c 08 03 a6 mtlrr0 c00c04b0: 4e 80 00 20 blr As you can see, it restores r1 -before- it pops r24..r31 off the stack ! I let you imagine what happens if an interrupt happens just in between those two instructions (mr and lmw). We don't do redzones on our ABI, so basically, the registers end up corrupted by the interrupt. Ouch! You've disassembled this without -pg too, and it does not have this bug? What version of gcc do you have? I have: gcc (Debian 4.3.1-2) 4.3.1 c00c64c8: 81 61 00 00 lwz r11,0(r1) c00c64cc: 7f 83 e3 78 mr r3,r28 c00c64d0: 80 0b 00 04 lwz r0,4(r11) c00c64d4: ba eb ff dc lmw r23,-36(r11) c00c64d8: 7d 61 5b 78 mr r1,r11 c00c64dc: 7c 08 03 a6 mtlrr0 c00c64e0: 4e 80 00 20 blr My version looks fine. I'm thinking that this is a separate issue than what Eran is seeing. Eran, can you do an objdump -dr vmlinux and search for __d_lookup, and print out the end of the function dump. Thanks, -- Steve powerpc-linux-gnu-objdump -dr --start-address=0xc00bb584 vmlinux | head -n 100 vmlinux: file format elf32-powerpc Disassembly of section .text: c00bb584 __d_lookup: [...] c00bb670: 41 9e 00 50 beq-cr7,c00bb6c0 __d_lookup+0x13c c00bb674: 83 de 00 00 lwz r30,0(r30) c00bb678: 2f 9e 00 00 cmpwi cr7,r30,0 c00bb67c: 40 9e ff 98 bne+cr7,c00bb614 __d_lookup+0x90 c00bb680: 38 60 00 00 li r3,0 c00bb684: 81 61 00 00 lwz r11,0(r1) c00bb688: 80 0b 00 04 lwz r0,4(r11) c00bb68c: 7d 61 5b 78 mr r1,r11 [ BUG HERE IF INTERRUPT HAPPENS ] c00bb690: bb 0b ff e0 lmw r24,-32(r11) c00bb694: 7c 08 03 a6 mtlrr0 c00bb698: 4e 80 00 20 blr Yep, you have the same bug in your compiler. -- Steve Hmm... so whats now? Is there a way to prove this scenario is indeed the one that caused the opps? -- Liberty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
On Wed, Aug 20, 2008 at 7:33 AM, Arnd Bergmann [EMAIL PROTECTED] wrote: On Tuesday 19 August 2008, Josh Boyer wrote: This adds a common board file for almost all of the simple PowerPC 44x boards that exist today. This is intended to be a single place to add support for boards that do not differ in platform support from most of the evaluation boards that are used as reference platforms. Boards that have specific requirements or custom hardware setup should still have their own board.c file. The code looks correct, but since this is going to be example code that may get copied into other platforms, I would take extra care for coding style: I second Arnd's comments. Otherwise, this looks pretty good to me. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wed, 2008-08-20 at 09:14 -0400, Steven Rostedt wrote: On Wed, 20 Aug 2008, Benjamin Herrenschmidt wrote: Found the problem (or at least -a- problem), it's a gcc bug. Well, first I must say the code generated by -pg is just plain horrible :-) Appart from that, look at the exit of, for example, __d_lookup, as generated by gcc when ftrace is enabled: c00c0498: 38 60 00 00 li r3,0 c00c049c: 81 61 00 00 lwz r11,0(r1) c00c04a0: 80 0b 00 04 lwz r0,4(r11) c00c04a4: 7d 61 5b 78 mr r1,r11 c00c04a8: bb 0b ff e0 lmw r24,-32(r11) c00c04ac: 7c 08 03 a6 mtlrr0 c00c04b0: 4e 80 00 20 blr As you can see, it restores r1 -before- it pops r24..r31 off the stack ! I let you imagine what happens if an interrupt happens just in between those two instructions (mr and lmw). We don't do redzones on our ABI, so basically, the registers end up corrupted by the interrupt. Ouch! You've disassembled this without -pg too, and it does not have this bug? What version of gcc do you have? Segher was looking at this a bit this morning. He thinks it's really -fno-omit-frame-pointer that is causing this. That really shouldn't even be set on PowerPC, but FTRACE uses select which overrides the depends on stuff in Kconfig. Segher can probably tell you more once his email is back up. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wed, 20 Aug 2008, Josh Boyer wrote: Segher was looking at this a bit this morning. He thinks it's really -fno-omit-frame-pointer that is causing this. That really shouldn't even be set on PowerPC, but FTRACE uses select which overrides the depends on stuff in Kconfig. I can easily make a patch that makes that select an x86 only. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
On Wed, 2008-08-20 at 08:15 -0600, Grant Likely wrote: On Wed, Aug 20, 2008 at 7:33 AM, Arnd Bergmann [EMAIL PROTECTED] wrote: On Tuesday 19 August 2008, Josh Boyer wrote: This adds a common board file for almost all of the simple PowerPC 44x boards that exist today. This is intended to be a single place to add support for boards that do not differ in platform support from most of the evaluation boards that are used as reference platforms. Boards that have specific requirements or custom hardware setup should still have their own board.c file. The code looks correct, but since this is going to be example code that may get copied into other platforms, I would take extra care for coding style: I second Arnd's comments. Otherwise, this looks pretty good to me. You should fix 52xx with the same for loop change then, since I blatantly most of this file from you ;) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wed, 20 Aug 2008 10:22:49 -0400 (EDT) Steven Rostedt [EMAIL PROTECTED] wrote: On Wed, 20 Aug 2008, Josh Boyer wrote: Segher was looking at this a bit this morning. He thinks it's really -fno-omit-frame-pointer that is causing this. That really shouldn't even be set on PowerPC, but FTRACE uses select which overrides the depends on stuff in Kconfig. I can easily make a patch that makes that select an x86 only. That's probably a first step, but you might want to wait until Segher can fill in more details. I'm sort of just relaying what he and I were talking about on IRC. IIRC, he was testing builds with and without both -pg and -fno-omit-frame-pointer and found the bug only when -fno-omit-frame-pointer was present. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On 8/20/08, Eran Liberty [EMAIL PROTECTED] wrote: Steven Rostedt wrote: On Wed, 20 Aug 2008, Eran Liberty wrote: Steven Rostedt wrote: On Wed, 20 Aug 2008, Steven Rostedt wrote: On Wed, 20 Aug 2008, Benjamin Herrenschmidt wrote: Found the problem (or at least -a- problem), it's a gcc bug. Well, first I must say the code generated by -pg is just plain horrible :-) Appart from that, look at the exit of, for example, __d_lookup, as generated by gcc when ftrace is enabled: c00c0498: 38 60 00 00 li r3,0 c00c049c: 81 61 00 00 lwz r11,0(r1) c00c04a0: 80 0b 00 04 lwz r0,4(r11) c00c04a4: 7d 61 5b 78 mr r1,r11 c00c04a8: bb 0b ff e0 lmw r24,-32(r11) c00c04ac: 7c 08 03 a6 mtlrr0 c00c04b0: 4e 80 00 20 blr As you can see, it restores r1 -before- it pops r24..r31 off the stack ! I let you imagine what happens if an interrupt happens just in between those two instructions (mr and lmw). We don't do redzones on our ABI, so basically, the registers end up corrupted by the interrupt. Ouch! You've disassembled this without -pg too, and it does not have this bug? What version of gcc do you have? I have: gcc (Debian 4.3.1-2) 4.3.1 c00c64c8: 81 61 00 00 lwz r11,0(r1) c00c64cc: 7f 83 e3 78 mr r3,r28 c00c64d0: 80 0b 00 04 lwz r0,4(r11) c00c64d4: ba eb ff dc lmw r23,-36(r11) c00c64d8: 7d 61 5b 78 mr r1,r11 c00c64dc: 7c 08 03 a6 mtlrr0 c00c64e0: 4e 80 00 20 blr My version looks fine. I'm thinking that this is a separate issue than what Eran is seeing. Eran, can you do an objdump -dr vmlinux and search for __d_lookup, and print out the end of the function dump. Thanks, -- Steve powerpc-linux-gnu-objdump -dr --start-address=0xc00bb584 vmlinux | head -n 100 vmlinux: file format elf32-powerpc Disassembly of section .text: c00bb584 __d_lookup: [...] c00bb670: 41 9e 00 50 beq-cr7,c00bb6c0 __d_lookup+0x13c c00bb674: 83 de 00 00 lwz r30,0(r30) c00bb678: 2f 9e 00 00 cmpwi cr7,r30,0 c00bb67c: 40 9e ff 98 bne+cr7,c00bb614 __d_lookup+0x90 c00bb680: 38 60 00 00 li r3,0 c00bb684: 81 61 00 00 lwz r11,0(r1) c00bb688: 80 0b 00 04 lwz r0,4(r11) c00bb68c: 7d 61 5b 78 mr r1,r11 [ BUG HERE IF INTERRUPT HAPPENS ] c00bb690: bb 0b ff e0 lmw r24,-32(r11) c00bb694: 7c 08 03 a6 mtlrr0 c00bb698: 4e 80 00 20 blr Yep, you have the same bug in your compiler. -- Steve Hmm... so whats now? Is there a way to prove this scenario is indeed the one that caused the opps? Manually edit the broken binary to change the order of the restore and see if the problem disappears. That will keep everything else constant. -- Liberty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- Jon Smirl [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/oprofile: fix mutex locking for spu-oprofile
On Wed, 2008-08-20 at 14:39 +0200, Robert Richter wrote: On 20.08.08 14:05:31, Arnd Bergmann wrote: On Wednesday 20 August 2008, Robert Richter wrote: I am fine with the changes with the exception of removing add_event_entry() from include/linux/oprofile.h. Though there is no usage of the function also in other architectures anymore, this change in the API should be discussed on the oprofile mailing list. Please separate the change in a different patch and submit it to the mailing list. If there are no objections then, this change can go upstream as well. As an explanation, the removal of add_event_entry is the whole point of this patch. add_event_entry must only be called with buffer_mutex held, but buffer_mutex itself is not exported. Thanks for pointing this out. We originally added add_event_entry() to include/linux/oprofile.h specifically because it was needed for the CELL SPU support. As it turns out it the approach was not completely thought through. We were using the function call without holding the mutex lock. As we discovered later, this can result in corrupting the data put into the event buffer. So exposing the function without a way to hold the mutex lock is actually a really bad idea as it would encourage others to fall into the same mistake that we made. So, as Arnd said, the whole point of this patch is to come up with a correct approach to adding the data. I'm pretty sure that no other user of add_event_entry exists, as it was exported specifically for the SPU support and that never worked. Any other (theoretical) code using it would be broken in the same way and need a corresponding fix. We can easily leave the declaration in place, but I'd recommend removing it eventually. If you prefer to keep it, how about marking it as __deprecated? No, since this is broken by design we remove it. The patch can go upstream as it is. Thanks, -Robert It really is best to remove it. Thank you for taking the time to review and comment on the patch. Carl Love ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
On Wed, 20 Aug 2008 10:45:47 -0400 Josh Boyer [EMAIL PROTECTED] wrote: On Wed, 2008-08-20 at 08:15 -0600, Grant Likely wrote: On Wed, Aug 20, 2008 at 7:33 AM, Arnd Bergmann [EMAIL PROTECTED] wrote: On Tuesday 19 August 2008, Josh Boyer wrote: This adds a common board file for almost all of the simple PowerPC 44x boards that exist today. This is intended to be a single place to add support for boards that do not differ in platform support from most of the evaluation boards that are used as reference platforms. Boards that have specific requirements or custom hardware setup should still have their own board.c file. The code looks correct, but since this is going to be example code that may get copied into other platforms, I would take extra care for coding style: I second Arnd's comments. Otherwise, this looks pretty good to me. You should fix 52xx with the same for loop change then, since I blatantly most of this file from you ;) ^ stole /me sighs. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wed, 20 Aug 2008, Jon Smirl wrote: c00bb690: bb 0b ff e0 lmw r24,-32(r11) c00bb694: 7c 08 03 a6 mtlrr0 c00bb698: 4e 80 00 20 blr Yep, you have the same bug in your compiler. -- Steve Hmm... so whats now? Is there a way to prove this scenario is indeed the one that caused the opps? Manually edit the broken binary to change the order of the restore and see if the problem disappears. That will keep everything else constant. Does it only happen on this function? Or is it happening on others as well. So manually fixing it here won't help much unless we fix it everywhere. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wed, 20 Aug 2008, Eran Liberty wrote: c00bb670: 41 9e 00 50 beq-cr7,c00bb6c0 __d_lookup+0x13c c00bb674: 83 de 00 00 lwz r30,0(r30) c00bb678: 2f 9e 00 00 cmpwi cr7,r30,0 c00bb67c: 40 9e ff 98 bne+cr7,c00bb614 __d_lookup+0x90 c00bb680: 38 60 00 00 li r3,0 c00bb684: 81 61 00 00 lwz r11,0(r1) c00bb688: 80 0b 00 04 lwz r0,4(r11) c00bb68c: 7d 61 5b 78 mr r1,r11 [ BUG HERE IF INTERRUPT HAPPENS ] c00bb690: bb 0b ff e0 lmw r24,-32(r11) c00bb694: 7c 08 03 a6 mtlrr0 c00bb698: 4e 80 00 20 blr Yep, you have the same bug in your compiler. -- Steve Hmm... so whats now? Try anothe gcc version ;-) Is there a way to prove this scenario is indeed the one that caused the opps? I'm not convinced that this is the bug you were seeing. Do you still get the crash if you disable dynamic ftrace but leave ftrace on? -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2] powerpc: fix memory leaks in QE library
Fix two memory leaks in the Freescale QE library: add a missing kfree() in
ucc_fast_init() and ucc_slow_init() if the ioremap() fails, and update
ucc_fast_free() and ucc_slow_free() to call iounmap() if necessary.
Based on a patch from Tony Breeds [EMAIL PROTECTED].
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
arch/powerpc/sysdev/qe_lib/ucc_fast.c |4
arch/powerpc/sysdev/qe_lib/ucc_slow.c |8 +---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 1aecb07..25fbbfa 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -208,6 +208,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct
ucc_fast_private ** ucc
uccf-uf_regs = ioremap(uf_info-regs, sizeof(struct ucc_fast));
if (uccf-uf_regs == NULL) {
printk(KERN_ERR %s: Cannot map UCC registers\n, __func__);
+ kfree(uccf);
return -ENOMEM;
}
@@ -355,6 +356,9 @@ void ucc_fast_free(struct ucc_fast_private * uccf)
if (uccf-ucc_fast_rx_virtual_fifo_base_offset)
qe_muram_free(uccf-ucc_fast_rx_virtual_fifo_base_offset);
+ if (uccf-uf_regs)
+ iounmap(uccf-uf_regs);
+
kfree(uccf);
}
EXPORT_SYMBOL(ucc_fast_free);
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
index a578bc7..e1d6a13 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
@@ -171,6 +171,7 @@ int ucc_slow_init(struct ucc_slow_info * us_info, struct
ucc_slow_private ** ucc
uccs-us_regs = ioremap(us_info-regs, sizeof(struct ucc_slow));
if (uccs-us_regs == NULL) {
printk(KERN_ERR %s: Cannot map UCC registers\n, __func__);
+ kfree(uccs);
return -ENOMEM;
}
@@ -367,10 +368,11 @@ void ucc_slow_free(struct ucc_slow_private * uccs)
if (uccs-tx_base_offset)
qe_muram_free(uccs-tx_base_offset);
- if (uccs-us_pram) {
+ if (uccs-us_pram)
qe_muram_free(uccs-us_pram_offset);
- uccs-us_pram = NULL;
- }
+
+ if (uccs-us_regs)
+ iounmap(uccs-us_regs);
kfree(uccs);
}
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
cache model of ppc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear, I some questions about the PowerPC cache model. How many caches are there? How many caches are in multi-core systems? do you have a L1 cache per cpu and one shared L2? or is there a victim L3 cache? can you tell me something about the path through the cache? for example I look up for data in L1, but this was a miss. Then i look up in L2 this was also a miss. but the date will be in another L1 cache of another cpu. Is there a 1.5 or 2.5 hit? can you help me please? this is for my bachelorthesis thanks a lot felix -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkisOIwACgkQmH8OAwYoDBk0ugCgu6zzJEQWA9NldC4ekjOcWgIu cYIAoMquvbvAf/qA1WmjtROpq+R1X6Yb =JepB -END PGP SIGNATURE- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
You should fix 52xx with the same for loop change then, since I blatantly most of this file from you ;) Heh, then factor out mpc5200_simple_probe() into a helper and use it instead of copying it as ppc44x_probe? ;) If you stick to the NULL-terminated array version, then it becomes easy to convert some other platform probing code to use your new code too, eg tqm85xx_probe() could use an array too. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/9] Rework PowerPC 44x board support
Josh Boyer wrote: The following patch series reworks the board support code for PowerPC 44x platforms. It eliminates a number of redundant board.c files and add a ppc44x_simple.c file that has an explicit list of boards that are supported by it. This is the same mechanism that Grant Likely has used for MPC 5200 boards. It also adds some more explicit support for Glacier and Yosemite boards, as those boards were using a board level compatible property in their DTS files that was a bit confusing. Review would be appreciated. Tested on Sequoia, and I plan on testing on as many boards as I can before committing to my tree. josh Sorry if I miss anything, but what happens if I build an uImage just for Rainier (not enabling other platforms in the kernel config) and then start it on Canyonlands for example? They both use PowerPC_44x_simple stuff and looks like now we claim that all these simple boards are compatible. So, board check always passes, although Canyonlands support is actually disabled (CONFIG_460EX = n; CONFIG_PPC4xx_PCI_EXPRESS = n). It's not critical, but I just thought we might also remove the platform-specific options from arch/powerpc/platforms/44x/Kconfig for these boards at all. Just enable all board-specific stuff under config PPC44x_SIMPLE. Otherwise we probably should have a configurable char *board[] array. Thanks, Valentine. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/9] Rework PowerPC 44x board support
Hi Josh, Review would be appreciated. Tested on Sequoia, and I plan on testing on as many boards as I can before committing to my tree. The changes looks great. That would be much appreciated. I have a number of the effected boards, but I don't have them all so any testing you can do would be awesome. I tried pulling up the latest code from your git tree. Seems it is not yet put in there. Do I have to manually apply all the patches to my git tree. I was planning to test the changes on Canyonlands, glacier and Kilauea boards here. Thanks, Prodyut Hazarika === Staff S/W Engineer AMCC === ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/9] Rework PowerPC 44x board support
On Wed, 20 Aug 2008 20:51:18 +0400 Valentine Barshak [EMAIL PROTECTED] wrote: Josh Boyer wrote: The following patch series reworks the board support code for PowerPC 44x platforms. It eliminates a number of redundant board.c files and add a ppc44x_simple.c file that has an explicit list of boards that are supported by it. This is the same mechanism that Grant Likely has used for MPC 5200 boards. It also adds some more explicit support for Glacier and Yosemite boards, as those boards were using a board level compatible property in their DTS files that was a bit confusing. Review would be appreciated. Tested on Sequoia, and I plan on testing on as many boards as I can before committing to my tree. josh Sorry if I miss anything, but what happens if I build an uImage just for Rainier (not enabling other platforms in the kernel config) and then start it on Canyonlands for example? Why would you do that? If you want that, use ppc44x_defconfig as it has all the boards enabled. Also, if you're talking about the default make targets in the kernel, that would build a cuImage for Rainier, and I'd expect that to blow up spectacularly on a Canoynlands because the device tree would be in no way correct. They both use PowerPC_44x_simple stuff and looks like now we claim that all these simple boards are compatible. So, board check always passes, No, we don't claim they are compatible at all. We simply claim that they can all be supported by the ppc44x_simple.c platform file. The compatible stuff is done through the device tree, and if you look at the patch series you'll see that I actually removed all the cross-board compatible statements from the boards that had more than one in the DTS file. although Canyonlands support is actually disabled (CONFIG_460EX = n; CONFIG_PPC4xx_PCI_EXPRESS = n). It's not critical, but I just thought we might also remove the platform-specific options from arch/powerpc/platforms/44x/Kconfig for these boards at all. Just enable I left them in there on purpose. People want to be able to say I have a Rainier board. I only want a kernel for that. They're also used for the wrapper stuff to build the right images. all board-specific stuff under config PPC44x_SIMPLE. Otherwise we probably should have a configurable char *board[] array. We could do that if it's _really_ necessary, but I'm not sure it is. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/9] Rework PowerPC 44x board support
On Wed, 20 Aug 2008 09:54:40 -0700 prodyut hazarika [EMAIL PROTECTED] wrote: Hi Josh, Review would be appreciated. Tested on Sequoia, and I plan on testing on as many boards as I can before committing to my tree. The changes looks great. That would be much appreciated. I have a number of the effected boards, but I don't have them all so any testing you can do would be awesome. I tried pulling up the latest code from your git tree. Seems it is not yet put in there. Right. I tend to not commit patches that even I send out until they've at least had some review. Do I have to manually apply all the patches to my git tree. I was planning to test the changes on Canyonlands, glacier and Kilauea boards here. For now, yes. In a day or so I'll probably fix the small comments I've gotten and then commit the series to my next branch. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
On Wed, 20 Aug 2008 09:33:06 -0700 Roland Dreier [EMAIL PROTECTED] wrote: You should fix 52xx with the same for loop change then, since I blatantly most of this file from you ;) Heh, then factor out mpc5200_simple_probe() into a helper and use it instead of copying it as ppc44x_probe? ;) If you stick to the NULL-terminated array version, then it becomes easy to convert some other platform probing code to use your new code too, eg tqm85xx_probe() could use an array too. Except that logically doesn't make much sense. Why would you have a list of mpc52xx and 44x boards together? They require completely different kernels because the MMU and drive set is entirely different. Or am I totally missing what you are saying? josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
Except that logically doesn't make much sense. Why would you have a list of mpc52xx and 44x boards together? They require completely different kernels because the MMU and drive set is entirely different. Or am I totally missing what you are saying? Yeah, I wasn't clear -- I meant to add a new helper like of_flat_dt_is_compatible_list() (not sure of the name) that takes a node and a NULL-terminated array of strings, and then mpc5200_simple_probe() can become a one-liner, along with mpc5121_generic_probe(), tqm85xx_probe(), ppc44x_probe(), etc. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
On Wed, 20 Aug 2008 10:19:02 -0700 Roland Dreier [EMAIL PROTECTED] wrote: Except that logically doesn't make much sense. Why would you have a list of mpc52xx and 44x boards together? They require completely different kernels because the MMU and drive set is entirely different. Or am I totally missing what you are saying? Yeah, I wasn't clear -- I meant to add a new helper like of_flat_dt_is_compatible_list() (not sure of the name) that takes a node and a NULL-terminated array of strings, and then mpc5200_simple_probe() can become a one-liner, along with mpc5121_generic_probe(), tqm85xx_probe(), ppc44x_probe(), etc. Ah, I see. I worry about doing that though. I don't want to give people the impression that these boards are of compatible. I want it to be more this file supports these explicit platforms and makes no claim on compatibility between them. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cache model of ppc
On Wed, 2008-08-20 at 17:30 +0200, Felix Schmidt wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear, I some questions about the PowerPC cache model. It depends greatly on the core, chip, and cache used. That varies widely across the PPC universe. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cache model of ppc
On Wed, Aug 20, 2008 at 05:30:21PM +0200, Felix Schmidt wrote: I some questions about the PowerPC cache model. How many caches are there? How many caches are in multi-core systems? do you have a L1 cache per cpu and one shared L2? or is there a victim L3 cache? can you tell me something about the path through the cache? for example I look up for data in L1, but this was a miss. Then i look up in L2 this was also a miss. but the date will be in another L1 cache of another cpu. Is there a 1.5 or 2.5 hit? This is all dependent on the particular CPU you're talking about, and should be described in its manual. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Jon Smirl wrote: Manually edit the broken binary to change the order of the restore and see if the problem disappears. That will keep everything else constant. checked with objdump where __d_lookup() powerpc-linux-gnu-objdump -dr --start-address=0xc0065790 vmlinux | grep __d_lookup: c00b91d8 __d_lookup: [EMAIL PROTECTED]:~/svn/exsw1600-2.6.27-rc2$ powerpc-linux-gnu-objdump -dr --start-address=0xc00b91d8 vmlinux| head -n 100 vmlinux: file format elf32-powerpc Disassembly of section .text: c00b91d8 __d_lookup: c00b91d8: 7c 08 02 a6 mflrr0 c00b91dc: 90 01 00 04 stw r0,4(r1) c00b92bc: 4e 80 04 21 bctrl c00b92c0: 2f 83 00 00 cmpwi cr7,r3,0 c00b92c4: 41 9e 00 50 beq-cr7,c00b9314 __d_lookup+0x13c c00b92c8: 83 de 00 00 lwz r30,0(r30) c00b92cc: 2f 9e 00 00 cmpwi cr7,r30,0 c00b92d0: 40 9e ff 98 bne+cr7,c00b9268 __d_lookup+0x90 c00b92d4: 38 60 00 00 li r3,0 c00b92d8: 81 61 00 00 lwz r11,0(r1) c00b92dc: 80 0b 00 04 lwz r0,4(r11) c00b92e0: 7d 61 5b 78 mr r1,r11 === As explained by Steve, these two should be replaced === c00b92e4: bb 0b ff e0 lmw r24,-32(r11) c00b92e8: 7c 08 03 a6 mtlrr0 c00b92ec: 4e 80 00 20 blr c00b92f0: 80 04 00 04 lwz r0,4(r4) c00b9330: 7f a3 eb 78 mr r3,r29 c00b9334: 4b ff ff a4 b c00b92d8 __d_lookup+0x100 c00b9338 d_lookup: c00b9338: 7c 08 02 a6 mflrr0 on the target I fired up xmon and replaced them. ~ # echo x /proc/sysrq-trigger SysRq : Entering xmon Vector: 0 at [df51fdb8] pc: c0025960: sysrq_handle_xmon+0x60/0x64 lr: c0025960: sysrq_handle_xmon+0x60/0x64 sp: df51fe80 msr: 21000 current = 0xdc22a9a0 pid = 1698, comm = echo WARNING: exception is not recoverable, can't continue enter ? for help [df51fe90] c0193c38 __handle_sysrq+0xa8/0x178 [df51fec0] c00ee818 write_sysrq_trigger+0x78/0x7c [df51fed0] c00e65e4 proc_reg_write+0x5c/0x84 [df51fef0] c00a299c vfs_write+0xc8/0x180 [df51ff10] c00a2f40 sys_write+0x5c/0xa4 [df51ff40] c0010554 ret_from_syscall+0x0/0x3c SP (bffe87e0) is in userspace mon di c00b92d0 c00b92d0 409eff98 bne cr7,c00b9268# __d_lookup+0x90/0x160 c00b92d4 3860 li r3,0 c00b92d8 8161 lwz r11,0(r1) c00b92dc 800b0004 lwz r0,4(r11) c00b92e0 7d615b78 mr r1,r11 === wrong order === c00b92e4 bb0bffe0 lmw r24,-32(r11) c00b92e8 7c0803a6 mtlrr0 c00b92ec 4e800020 blr c00b92f0 80040004 lwz r0,4(r4) c00b92f4 7f80c800 cmpwcr7,r0,r25 c00b92f8 409eff64 bne cr7,c00b925c# __d_lookup+0x84/0x160 c00b92fc 80640008 lwz r3,8(r4) c00b9300 7f25cb78 mr r5,r25 c00b9304 7f04c378 mr r4,r24 c00b9308 4bf5ccf1 bl c0015ff8# memcmp+0x0/0x30 c00b930c 2f83 cmpwi cr7,r3,0 mon m c00b92e0 c00b92e0 7d l c00b92e0 7d615b78 bb0bffe0 c00b92e4 bb0bffe0 7d615b78 c00b92e8 7c0803a6 x mon di c00b92d0 c00b92d0 409eff98 bne cr7,c00b9268# __d_lookup+0x90/0x160 c00b92d4 3860 li r3,0 c00b92d8 8161 lwz r11,0(r1) c00b92dc 800b0004 lwz r0,4(r11) c00b92e0 bb0bffe0 lmw r24,-32(r11) === right order === c00b92e4 7d615b78 mr r1,r11 c00b92e8 7c0803a6 mtlrr0 c00b92ec 4e800020 blr c00b92f0 80040004 lwz r0,4(r4) c00b92f4 7f80c800 cmpwcr7,r0,r25 c00b92f8 409eff64 bne cr7,c00b925c# __d_lookup+0x84/0x160 c00b92fc 80640008 lwz r3,8(r4) c00b9300 7f25cb78 mr r5,r25 c00b9304 7f04c378 mr r4,r24 c00b9308 4bf5ccf1 bl c0015ff8# memcmp+0x0/0x30 c00b930c 2f83 cmpwi cr7,r3,0 mon X ~ # And took it for a test drive ~# while [ 1 ] ; do find / /dev/null ; echo . ; done . . . [ 10 min later ] . . . Stable! Yeepee. So how do we get this to be right in the first place and everywhere? -- Liberty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Wed, 2008-08-20 at 14:53 +0200, Christian Ehrhardt wrote: Arnd Bergmann wrote: On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote: Dependent on the already existing CONFIG_KVM_GUEST config option this patch changes wrteei to wrtee allowing the hypervisor to rewrite those to nontrapping instructions. Maybe we should split the kvm guest otpimizations in two parts one for the overhead free optimizations and on for the rest that might add some complexity for non virtualized execution (like this one). Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED] How significant is the performance impact of this change for non-virtualized systems? If it's very low, maybe you should not bother with the #ifdef, and if it's noticable, you might be better off using dynamic patching for this. Arnd To be honest I unfortunately don't know how big the impact for non-virtualized systems is. I would like to test it, but without hardware performance counters on the core I have I'm not sure (yet) how to measure that in a good way - any suggestion welcome. I don't see why we need performance counters. Can't we just compare any bare metal benchmark results with the patch both applied and not? -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Wed, 20 Aug 2008, Eran Liberty wrote: mon X ~ # And took it for a test drive ~# while [ 1 ] ; do find / /dev/null ; echo . ; done . . . [ 10 min later ] . . . Stable! Yeepee. Eran, thanks a lot for testing this! So how do we get this to be right in the first place and everywhere? This is a bug in gcc, and should be mentioned to the gcc maintainers. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Wed, 2008-08-20 at 13:30 -0500, Hollis Blanchard wrote:
On Wed, 2008-08-20 at 14:53 +0200, Christian Ehrhardt wrote:
Arnd Bergmann wrote:
On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote:
Dependent on the already existing CONFIG_KVM_GUEST config option
this patch
changes wrteei to wrtee allowing the hypervisor to rewrite those to
nontrapping
instructions. Maybe we should split the kvm guest otpimizations in
two parts
one for the overhead free optimizations and on for the rest that
might add
some complexity for non virtualized execution (like this one).
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
How significant is the performance impact of this change for
non-virtualized
systems? If it's very low, maybe you should not bother with the
#ifdef, and
if it's noticable, you might be better off using dynamic patching
for this.
Arnd
To be honest I unfortunately don't know how big the impact for
non-virtualized systems is. I would like to test it, but without
hardware performance counters on the core I have I'm not sure (yet)
how
to measure that in a good way - any suggestion welcome.
I don't see why we need performance counters. Can't we just compare any
bare metal benchmark results with the patch both applied and not?
Do you know of one that causes a large amount of
local_irq_{disable,enable}s to be called?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Wed, 2008-08-20 at 14:52 -0400, Josh Boyer wrote:
On Wed, 2008-08-20 at 13:30 -0500, Hollis Blanchard wrote:
On Wed, 2008-08-20 at 14:53 +0200, Christian Ehrhardt wrote:
Arnd Bergmann wrote:
On Tuesday 19 August 2008, [EMAIL PROTECTED] wrote:
Dependent on the already existing CONFIG_KVM_GUEST config option
this patch
changes wrteei to wrtee allowing the hypervisor to rewrite those to
nontrapping
instructions. Maybe we should split the kvm guest otpimizations in
two parts
one for the overhead free optimizations and on for the rest that
might add
some complexity for non virtualized execution (like this one).
Signed-off-by: Christian Ehrhardt [EMAIL PROTECTED]
How significant is the performance impact of this change for
non-virtualized
systems? If it's very low, maybe you should not bother with the
#ifdef, and
if it's noticable, you might be better off using dynamic patching
for this.
Arnd
To be honest I unfortunately don't know how big the impact for
non-virtualized systems is. I would like to test it, but without
hardware performance counters on the core I have I'm not sure (yet)
how
to measure that in a good way - any suggestion welcome.
I don't see why we need performance counters. Can't we just compare any
bare metal benchmark results with the patch both applied and not?
Do you know of one that causes a large amount of
local_irq_{disable,enable}s to be called?
I think *every* workload causes a large number of
local_irq_{disable,enable} calls... :)
--
Hollis Blanchard
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/4] kvmppc: convert wrteei to wrtee as kvm guest optimization
On Wed, 20 Aug 2008 14:06:51 -0500
Hollis Blanchard [EMAIL PROTECTED] wrote:
To be honest I unfortunately don't know how big the impact for
non-virtualized systems is. I would like to test it, but without
hardware performance counters on the core I have I'm not sure (yet)
how
to measure that in a good way - any suggestion welcome.
I don't see why we need performance counters. Can't we just compare any
bare metal benchmark results with the patch both applied and not?
Do you know of one that causes a large amount of
local_irq_{disable,enable}s to be called?
I think *every* workload causes a large number of
local_irq_{disable,enable} calls... :)
Well, sure. I was just going for test the change as specifically as
possible. One could write a module that did X number of
disable/enable pairs and reported the timebase at start and end to
compare. X could even be a module parameter. Just to try and
eliminate noise or whatever from the testing.
/me shrugs.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 0/4] PS3 patches for 2.6.27
Hi Paul, This is a set of PS3 fixup patches for 2.6.27. Patch 4/4, Fix ioremap of spu shadow regs, is a bit of a hack, but I can't think of a better way to get the needed protection bits. [patch 1/4] powerpc: Fix typo in pgtable-ppc64.h [patch 2/4] powerpc/ps3: Update ps3_defconfig [patch 3/4] powerpc/ps3: Rework htab to remove ioremap [patch 4/4] powerpc/ps3: Fix ioremap of spu shadow regs -Geoff -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 1/4] powerpc: Fix typo in pgtable-ppc64.h
Fix a minor comment typo in pgtable-ppc64.h. Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- arch/powerpc/include/asm/pgtable-ppc64.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/powerpc/include/asm/pgtable-ppc64.h +++ b/arch/powerpc/include/asm/pgtable-ppc64.h @@ -100,7 +100,7 @@ #define _PAGE_WRENABLE (_PAGE_RW | _PAGE_DIRTY) -/* __pgprot defined in arch/powerpc/incliude/asm/page.h */ +/* __pgprot defined in arch/powerpc/include/asm/page.h */ #define PAGE_NONE __pgprot(_PAGE_PRESENT | _PAGE_ACCESSED) #define PAGE_SHARED__pgprot(_PAGE_BASE | _PAGE_RW | _PAGE_USER) -- ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 2/4] powerpc/ps3: Update ps3_defconfig
Update ps3_defconfig. Signed-off-by: Geoff Levand [EMAIL PROTECTED] --- arch/powerpc/configs/ps3_defconfig | 153 - 1 file changed, 133 insertions(+), 20 deletions(-) --- a/arch/powerpc/configs/ps3_defconfig +++ b/arch/powerpc/configs/ps3_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.26 -# Wed Jul 16 13:59:24 2008 +# Linux kernel version: 2.6.27-rc3 +# Wed Aug 20 08:16:53 2008 # CONFIG_PPC64=y @@ -92,7 +92,6 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y -CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y @@ -118,11 +117,16 @@ CONFIG_PROFILING=y CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set +CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y +CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y +CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y +# CONFIG_HAVE_CLK is not set CONFIG_PROC_PAGE_MONITOR=y +# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set @@ -179,6 +183,7 @@ CONFIG_PS3_STORAGE=y CONFIG_PS3_DISK=y CONFIG_PS3_ROM=y CONFIG_PS3_FLASH=y +CONFIG_OPROFILE_PS3=y CONFIG_PS3_LPM=m CONFIG_PPC_CELL=y # CONFIG_PPC_CELL_NATIVE is not set @@ -218,7 +223,7 @@ CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 -# CONFIG_SCHED_HRTICK is not set +CONFIG_SCHED_HRTICK=y CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set @@ -252,8 +257,10 @@ CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y # CONFIG_SPARSEMEM_VMEMMAP is not set CONFIG_MEMORY_HOTPLUG=y CONFIG_MEMORY_HOTPLUG_SPARSE=y +# CONFIG_MEMORY_HOTREMOVE is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 +CONFIG_MIGRATION=y CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y @@ -276,19 +283,17 @@ CONFIG_ISA_DMA_API=y # CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y +CONFIG_PPC_PCI_CHOICE=y # CONFIG_PCI is not set # CONFIG_PCI_DOMAINS is not set # CONFIG_PCI_SYSCALL is not set # CONFIG_ARCH_SUPPORTS_MSI is not set # CONFIG_PCCARD is not set # CONFIG_HAS_RAPIDIO is not set +# CONFIG_RELOCATABLE is not set CONFIG_PAGE_OFFSET=0xc000 CONFIG_KERNEL_START=0xc000 CONFIG_PHYSICAL_START=0x - -# -# Networking -# CONFIG_NET=y # @@ -399,9 +404,22 @@ CONFIG_BT_HCIUSB_SCO=y # # Wireless # -# CONFIG_CFG80211 is not set +CONFIG_CFG80211=m +CONFIG_NL80211=y CONFIG_WIRELESS_EXT=y -# CONFIG_MAC80211 is not set +# CONFIG_WIRELESS_EXT_SYSFS is not set +CONFIG_MAC80211=m + +# +# Rate control algorithm selection +# +CONFIG_MAC80211_RC_PID=y +CONFIG_MAC80211_RC_DEFAULT_PID=y +CONFIG_MAC80211_RC_DEFAULT=pid +# CONFIG_MAC80211_MESH is not set +# CONFIG_MAC80211_LEDS is not set +# CONFIG_MAC80211_DEBUGFS is not set +# CONFIG_MAC80211_DEBUG_MENU is not set CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set CONFIG_IEEE80211_CRYPT_WEP=m @@ -420,14 +438,79 @@ CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y -CONFIG_FW_LOADER=m +CONFIG_FW_LOADER=y # CONFIG_FIRMWARE_IN_KERNEL is not set CONFIG_EXTRA_FIRMWARE= # CONFIG_DEBUG_DRIVER is not set # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set -# CONFIG_MTD is not set +CONFIG_MTD=y +CONFIG_MTD_DEBUG=y +CONFIG_MTD_DEBUG_VERBOSE=0 +# CONFIG_MTD_CONCAT is not set +# CONFIG_MTD_PARTITIONS is not set + +# +# User Modules And Translation Layers +# +# CONFIG_MTD_CHAR is not set +CONFIG_MTD_BLKDEVS=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set +# CONFIG_RFD_FTL is not set +# CONFIG_SSFDC is not set +# CONFIG_MTD_OOPS is not set + +# +# RAM/ROM/Flash chip drivers +# +# CONFIG_MTD_CFI is not set +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_RAM is not set +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +# CONFIG_MTD_PLATRAM is not set + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +CONFIG_MTD_PS3VRAM=y +# CONFIG_MTD_MTDRAM is not set +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set +# CONFIG_MTD_NAND is not set +# CONFIG_MTD_ONENAND is not set + +# +# UBI -
[patch 4/4] powerpc/ps3: Fix ioremap of spu shadow regs
From: Masakazu Mokuno [EMAIL PROTECTED]
Fix the ioremap of the spu shadow regs on the PS3.
The current PS3 hypervisor requires the spu shadow regs to be
mapped with the PTE page protection bits set as read-only (PP=3).
This implementation uses the low level __ioremap() to bypass the
page protection settings inforced by ioremap_flags() to get the
needed PTE bits set for the shadow regs.
This fixes a runtime failure on the PS3 introduced by the powerpc
ioremap_prot rework of commit a1f242ff460e4b50a045fa237c3c56cce9eabf83.
Signed-off-by: Masakazu Mokuno [EMAIL PROTECTED]
CC: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
arch/powerpc/platforms/ps3/spu.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -186,14 +186,24 @@ static void spu_unmap(struct spu *spu)
iounmap(spu_pdata(spu)-shadow);
}
+/**
+ * setup_areas - Map the spu regions into the address space.
+ *
+ * The current HV requires the spu shadow regs to be mapped with the
+ * PTE page protection bits set as read-only (PP=3). This implementation
+ * uses the low level __ioremap() to bypass the page protection settings
+ * inforced by ioremap_flags() to get the needed PTE bits set for the
+ * shadow regs.
+ */
+
static int __init setup_areas(struct spu *spu)
{
struct table {char* name; unsigned long addr; unsigned long size;};
+ static const unsigned long shadow_flags = _PAGE_NO_CACHE | 3;
- spu_pdata(spu)-shadow = ioremap_flags(spu_pdata(spu)-shadow_addr,
- sizeof(struct spe_shadow),
- pgprot_val(PAGE_READONLY) |
- _PAGE_NO_CACHE);
+ spu_pdata(spu)-shadow = __ioremap(spu_pdata(spu)-shadow_addr,
+ sizeof(struct spe_shadow),
+ shadow_flags);
if (!spu_pdata(spu)-shadow) {
pr_debug(%s:%d: ioremap shadow failed\n, __func__, __LINE__);
goto fail_ioremap;
--
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[patch 3/4] powerpc/ps3: Rework htab to remove ioremap
From: Masakazu Mokuno [EMAIL PROTECTED]
Rework the PS3 htab code to remove the need to ioremap the hash table
by using the HV calls lv1_insert_htab_entry() and
lv1_read_htab_entries().
This fixes a runtime failure on the PS3 introduced by the powerpc
ioremap_prot rework of commit a1f242ff460e4b50a045fa237c3c56cce9eabf83.
Signed-off-by: Masakazu Mokuno [EMAIL PROTECTED]
CC: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Geoff Levand [EMAIL PROTECTED]
---
arch/powerpc/platforms/ps3/htab.c | 269 -
arch/powerpc/platforms/ps3/setup.c |1
2 files changed, 91 insertions(+), 179 deletions(-)
--- a/arch/powerpc/platforms/ps3/htab.c
+++ b/arch/powerpc/platforms/ps3/htab.c
@@ -29,138 +29,75 @@
#include platform.h
-#if defined(DEBUG)
-#define DBG udbg_printf
-#else
-#define DBG pr_debug
-#endif
-
-static struct hash_pte *htab;
-static unsigned long htab_addr;
-static unsigned char *bolttab;
-static unsigned char *inusetab;
-
-static DEFINE_SPINLOCK(ps3_bolttab_lock);
-
-#define debug_dump_hpte(_a, _b, _c, _d, _e, _f, _g) \
- _debug_dump_hpte(_a, _b, _c, _d, _e, _f, _g, __func__, __LINE__)
-static void _debug_dump_hpte(unsigned long pa, unsigned long va,
- unsigned long group, unsigned long bitmap, struct hash_pte lhpte,
- int psize, unsigned long slot, const char* func, int line)
-{
- DBG(%s:%d: pa = %lxh\n, func, line, pa);
- DBG(%s:%d: lpar = %lxh\n, func, line,
- ps3_mm_phys_to_lpar(pa));
- DBG(%s:%d: va = %lxh\n, func, line, va);
- DBG(%s:%d: group = %lxh\n, func, line, group);
- DBG(%s:%d: bitmap = %lxh\n, func, line, bitmap);
- DBG(%s:%d: hpte.v = %lxh\n, func, line, lhpte.v);
- DBG(%s:%d: hpte.r = %lxh\n, func, line, lhpte.r);
- DBG(%s:%d: psize = %xh\n, func, line, psize);
- DBG(%s:%d: slot = %lxh\n, func, line, slot);
-}
+/**
+ * enum lpar_vas_id - id of LPAR virtual address space.
+ * @lpar_vas_id_current: Current selected virtual address space
+ *
+ * Identify the target LPAR address space.
+ */
+
+enum ps3_lpar_vas_id {
+ PS3_LPAR_VAS_ID_CURRENT = 0,
+};
+
+
+static DEFINE_SPINLOCK(ps3_htab_lock);
static long ps3_hpte_insert(unsigned long hpte_group, unsigned long va,
unsigned long pa, unsigned long rflags, unsigned long vflags,
int psize, int ssize)
{
- unsigned long slot;
- struct hash_pte lhpte;
- int secondary = 0;
- unsigned long result;
- unsigned long bitmap;
+ int result;
+ u64 hpte_v, hpte_r;
+ u64 inserted_index;
+ u64 evicted_v, evicted_r;
+ u64 hpte_v_array[4], hpte_rs;
unsigned long flags;
- unsigned long p_pteg, s_pteg, b_index, b_mask, cb, ci;
-
- vflags = ~HPTE_V_SECONDARY; /* this bit is ignored */
+ long ret = -1;
- lhpte.v = hpte_encode_v(va, psize, MMU_SEGSIZE_256M) |
- vflags | HPTE_V_VALID;
- lhpte.r = hpte_encode_r(ps3_mm_phys_to_lpar(pa), psize) | rflags;
-
- p_pteg = hpte_group / HPTES_PER_GROUP;
- s_pteg = ~p_pteg htab_hash_mask;
-
- spin_lock_irqsave(ps3_bolttab_lock, flags);
+ /*
+* lv1_insert_htab_entry() will search for victim
+* entry in both primary and secondary pte group
+*/
+ vflags = ~HPTE_V_SECONDARY;
- BUG_ON(bolttab[p_pteg] == 0xff bolttab[s_pteg] == 0xff);
+ hpte_v = hpte_encode_v(va, psize, ssize) | vflags | HPTE_V_VALID;
+ hpte_r = hpte_encode_r(ps3_mm_phys_to_lpar(pa), psize) | rflags;
- bitmap = (inusetab[p_pteg] 8) | inusetab[s_pteg];
+ spin_lock_irqsave(ps3_htab_lock, flags);
- if (bitmap == 0x) {
- /*
-* PTEG is full. Search for victim.
-*/
- bitmap = ~((bolttab[p_pteg] 8) | bolttab[s_pteg]);
- do {
- ci = mftb() 15;
- cb = 0x8000UL ci;
- } while ((cb bitmap) == 0);
- } else {
- /*
-* search free slot in hardware order
-* [primary] 0, 2, 4, 6, 1, 3, 5, 7
-* [secondary] 0, 2, 4, 6, 1, 3, 5, 7
-*/
- for (ci = 0; ci HPTES_PER_GROUP; ci += 2) {
- cb = 0x8000UL ci;
- if ((cb bitmap) == 0)
- goto found;
- }
- for (ci = 1; ci HPTES_PER_GROUP; ci += 2) {
- cb = 0x8000UL ci;
- if ((cb bitmap) == 0)
- goto found;
- }
- for (ci = HPTES_PER_GROUP; ci HPTES_PER_GROUP*2; ci += 2) {
- cb = 0x8000UL ci;
- if ((cb bitmap) == 0)
- goto found;
- }
- for (ci = HPTES_PER_GROUP+1; ci HPTES_PER_GROUP*2; ci += 2) {
-
Strange behavior with I2C on Sequoia board
I have just tried enabling I2C on a Sequoia board (kernel is DENX 2.6.26) and doing that appears to corrupt the u-boot / kernel communications. Prior to turning on I2C, I see the ethernet mac and kernel command line correctly passed, but once I turn on I2C, the ethernet mac becomes 0 and the kernel command line is missing many parameters. I'll paste in a good log, then a bad one. The only configuration difference is that the bad one has CONFIG_I2C_CHARDEV=y and CONFIG_I2C_IBM_IIC=y in the configuration. I'll start digging into it, but if anyone has any experience or ideas regarding I2C on PPC440, I'd appreciate your thoughts on this. Steve Good log: = ## Booting kernel from Legacy Image at fd40 ... Image Name: Linux-2.6.26.1-00033-g088efe4-di Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1801234 Bytes = 1.7 MB Load Address: 0040 Entry Point: 00400454 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading init Ramdisk from Legacy Image at fd90 ... Image Name: initramfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:2442283 Bytes = 2.3 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fcb8000, end 0ff0c42b ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) Memory - 0x0 0x0 0x000 (255MB) ENET0: local-mac-address - 00:10:ec:01:04:d0 ENET1: local-mac-address - 00:10:ec:01:04:d1 zImage starting: loaded at 0x0040 (sp: 0x0ff0d220) Allocating 0x3dbc2c bytes for kernel ... gunzipping (0x - 0x0040e000:0x007ed9c8)...done 0x39c1c4 bytes Using loader supplied ramdisk at 0xfcb8000-0xff0c42b initrd head: 0x1f8b0808 Linux/PowerPC load: root=/dev/sda3 rw ip=137.237.178.105:137.237.179.31:137.237.178.1:255.255.255.0:hydra_temp:eth0:off panic=1 console=ttyS0,115200 Bad log: ## Booting kernel from Legacy Image at fd40 ... Image Name: Linux-2.6.26.1-00034-gf084326-di Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1811651 Bytes = 1.7 MB Load Address: 0040 Entry Point: 00400454 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading init Ramdisk from Legacy Image at fd90 ... Image Name: initramfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:2442283 Bytes = 2.3 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fcb8000, end 0ff0c42b ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) Memory - 0x0 0x0 0x000 (255MB) ENET0: local-mac-address - 00:00:00:00:00:00 ENET1: local-mac-address - 00:00:00:00:00:00 zImage starting: loaded at 0x0040 (sp: 0x0ff0d220) Allocating 0x3e1c48 bytes for kernel ... gunzipping (0x - 0x0040e000:0x007f3a24)...done 0x3a21c4 bytes Using loader supplied ramdisk at 0xfcb8000-0xff0c42b initrd head: 0x1f8b0808 Linux/PowerPC load: console=ttyS0,115200 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errrata
В Tue, 19 Aug 2008 12:03:42 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED] пишет: .../... There is a software workaround that uses a trick to detect if full-speed interface is enabled from the hi-speed driver(and vice versa), and use suspend control for ohci to enable/disable it appropriately. Initial version of the software workaround was posted to linux-usb-devel: http://www.mail-archive.com/[EMAIL PROTECTED]/msg54019.html and later were made available from amcc.com: http://www.amcc.com/Embedded/Downloads/download.html?cat=1family=15ins=2 The patch below is generally based on the latter, but reworked to powerpc/of_device USB drivers, and uses a few devicetree inquiries to get rid of (some) hardcoded defines. Well, it seems to still call things based on #ifdef CONFIG_* instead of testing for whatever errata bit or flag you can initialize. A proper approach is to have the OF probe code detect via some device-tree compatible testing or such, that it's indeed hitting the broken chip, use that to set a quirk in the controller, and then have the core ehci-hub.c code do whatever it has to do based on the presence of that quirk. Makes sense, thanks. I'll look into rearranging stuff appropriately over this weekend. Thanks, -Vitaly ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC] mtd: add OF2PDEV convertor for the NDFC driver
I didn't convert the NDFC driver to support OF because there are
non-OF-aware platforms with the ndfc chip.
All settings are mandatory except the oob layout.
Signed-off-by: Sebastian Siewior [EMAIL PROTECTED]
---
drivers/mtd/nand/Kconfig |7 ++
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/ndfc_of.c | 253
3 files changed, 261 insertions(+), 0 deletions(-)
create mode 100644 drivers/mtd/nand/ndfc_of.c
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index ab0d77e..5bf0a25 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -170,6 +170,13 @@ config MTD_NAND_NDFC
help
NDFC Nand Flash Controllers are integrated in IBM/AMCC's 4xx SoCs
+config MTD_NAND_NDFC_OF
+ tristate OF support for NDFC
+ depends on MTD_NAND_NDFC PPC_OF
+ help
+ This setting allows to read the NanD configuration from OF instead
+ of a Platform device.
+
config MTD_NAND_S3C2410_CLKSTOP
bool S3C2410 NAND IDLE clock stop
depends on MTD_NAND_S3C2410
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index b786c5d..5a9da0f 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_MTD_NAND_TS7250) += ts7250.o
obj-$(CONFIG_MTD_NAND_NANDSIM) += nandsim.o
obj-$(CONFIG_MTD_NAND_CS553X) += cs553x_nand.o
obj-$(CONFIG_MTD_NAND_NDFC)+= ndfc.o
+obj-$(CONFIG_MTD_NAND_NDFC_OF) += ndfc_of.o
obj-$(CONFIG_MTD_NAND_ATMEL) += atmel_nand.o
obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o
obj-$(CONFIG_MTD_NAND_BASLER_EXCITE) += excite_nandflash.o
diff --git a/drivers/mtd/nand/ndfc_of.c b/drivers/mtd/nand/ndfc_of.c
new file mode 100644
index 000..852dca3
--- /dev/null
+++ b/drivers/mtd/nand/ndfc_of.c
@@ -0,0 +1,253 @@
+/*
+ * OF - Platform device wrapper for NDFC
+ * (c) Sebastian Siewior, Linutronix
+ */
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/mtd/partitions.h
+#include linux/mtd/nand.h
+#include linux/mtd/ndfc.h
+
+struct resource ndfc_resource;
+
+struct ndfc_controller_settings ndfc_settings;
+
+struct platform_nand_ctrl ndfc_nand_ctrl = {
+ .priv = ndfc_settings,
+};
+
+static struct platform_device ndfc_nand_device = {
+ .name = ndfc-nand,
+ .id = 0,
+ .dev = {
+ .platform_data = ndfc_nand_ctrl,
+ },
+ .num_resources = 1,
+ .resource = ndfc_resource,
+};
+
+static int ndfc_num_devices;
+
+struct of_ndfc_devices {
+ struct platform_device device;
+ struct platform_nand_chip chip;
+ struct ndfc_chip_settings chip_settings;
+ struct nand_ecclayout ecclayout;
+};
+
+static struct of_ndfc_devices *ndfc_chips;
+
+static int __devinit of_nand_probe(struct of_device *dev,
+ const struct of_device_id *match)
+{
+ struct device_node *dp = dev-node;
+ struct device_node *child_node;
+ const u32 *u32_val;
+ int ret;
+ int i;
+ u32 len;
+ u32 ccr_bank;
+ u32 read_cycles;
+ u32 num_chips = 0;
+
+ ret = of_address_to_resource(dp, 0, ndfc_resource);
+ if (ret) {
+ dev_err(dev-dev, Failed to read address from DT.\n);
+ return ret;
+ }
+
+ u32_val = of_get_property(dp, id, len);
+ if (!u32_val || len != 4) {
+ dev_err(dev-dev, Failed to read property: id\n);
+ return -EINVAL;
+ }
+ ndfc_nand_device.id = *u32_val;
+
+ u32_val = of_get_property(dp, ccr_bank, len);
+ if (!u32_val || len != 4) {
+ dev_err(dev-dev, Failed to read property: ccr_bank\n);
+ return -EINVAL;
+ }
+ ccr_bank = *u32_val;
+
+ u32_val = of_get_property(dp, read_cycles, len);
+ if (!u32_val || len != 4) {
+ dev_err(dev-dev, Failed to read property: read_cycles\n);
+ return -EINVAL;
+ }
+ read_cycles = *u32_val;
+
+ ndfc_settings.ccr_settings = NDFC_CCR_BS(ccr_bank) | read_cycles;
+
+ u32_val = of_get_property(dp, erpn, len);
+ if (!u32_val || len != 4) {
+ dev_err(dev-dev, Failed to read property: erpn\n);
+ return -EINVAL;
+ }
+ ndfc_settings.ndfc_erpn = *u32_val;
+
+ for_each_child_of_node(dp, child_node)
+ num_chips++;
+
+ if (!num_chips) {
+ dev_err(dev-dev, Failed to find chip nodes\n);
+ return -EINVAL;
+ }
+
+ ndfc_num_devices = num_chips;
+ ndfc_chips = kzalloc(ndfc_num_devices * sizeof(struct of_ndfc_devices),
+ GFP_KERNEL);
+ if (!ndfc_chips) {
+ dev_err(dev-dev, OOM while allocating memory for %d
+ ndfc_chips\n, num_chips);
+ return -ENOMEM;
+
Re: [PATCH 1/9] powerpc/44x: Add PowerPC 44x simple platform support
Yeah, I wasn't clear -- I meant to add a new helper like of_flat_dt_is_compatible_list() (not sure of the name) that takes a node and a NULL-terminated array of strings, and then mpc5200_simple_probe() can become a one-liner, along with mpc5121_generic_probe(), tqm85xx_probe(), ppc44x_probe(), etc. I worry about doing that though. I don't want to give people the impression that these boards are of compatible. I want it to be more this file supports these explicit platforms and makes no claim on compatibility between them. It's no big deal really -- just my knee-jerk reaction to seeing a comment like this should also be fixed in some other place because I copied the code from there. My reaction to that is always, why not use one common copy of the code then? You could call it something like of_flat_dt_match_list() if that makes more sense to you. Or just copy the for loop around, it's not much code. - R. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Hmm... so whats now? Is there a way to prove this scenario is indeed the one that caused the opps? I've verified in sim that the crash in do_lookup() I was seeing (similar backtrace) was indeed caused by an interrupt coming between those two instructions and clobbering the saved GPRs. So I think it's very likely our problem. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Thu, 21 Aug 2008, Benjamin Herrenschmidt wrote: As you can see, it restores r1 -before- it pops r24..r31 off the stack ! I let you imagine what happens if an interrupt happens just in between those two instructions (mr and lmw). We don't do redzones on our ABI, so basically, the registers end up corrupted by the interrupt. Ouch! You've disassembled this without -pg too, and it does not have this bug? What version of gcc do you have? Oops, should have mentioned it ;-) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) I'm running a 4.3.1 (Debian 4.3.1-2) on my powerbook. Perhaps the issue is already taken care of. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
As you can see, it restores r1 -before- it pops r24..r31 off the stack ! I let you imagine what happens if an interrupt happens just in between those two instructions (mr and lmw). We don't do redzones on our ABI, so basically, the registers end up corrupted by the interrupt. Ouch! You've disassembled this without -pg too, and it does not have this bug? What version of gcc do you have? Oops, should have mentioned it ;-) 4.2.3 (Ubuntu 4.2.3-2ubuntu7) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] mtd: add OF2PDEV convertor for the NDFC driver
On Wednesday 20 August 2008, Sebastian Siewior wrote: I didn't convert the NDFC driver to support OF because there are non-OF-aware platforms with the ndfc chip. All settings are mandatory except the oob layout. Are you aware of Sean's patch from http://patchwork.ozlabs.org/linuxppc/patch?id=20183 ? What are the other platforms using it? Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] mtd: add OF2PDEV convertor for the NDFC driver
On Thu, 21 Aug 2008 00:40:58 +0200 Arnd Bergmann [EMAIL PROTECTED] wrote: On Wednesday 20 August 2008, Sebastian Siewior wrote: I didn't convert the NDFC driver to support OF because there are non-OF-aware platforms with the ndfc chip. All settings are mandatory except the oob layout. Are you aware of Sean's patch from http://patchwork.ozlabs.org/linuxppc/patch?id=20183 ? I need to look at that hard for .28 still. What are the other platforms using it? There should be none. It was an arch/ppc driver originally, and arch/ppc is dead. Since it's only found on 4xx SoCs, there's no reason that I'm aware of to keep it as a platform driver. Other than the fact that the whole of_platform thing might be replaced with shims to convert them to platform devices. There was talk of that at one time and it made sense to me. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Patches pushed to powerpc.git master powerpc-next branches
I have committed the following patches to the master and powerpc-next branches of the powerpc.git repository. These will be going upstream in the 2.6.28 merge window. Paul. Adrian Bunk (1): powerpc: Use bcd2bin/bin2bcd Benjamin Herrenschmidt (2): powerpc: Turn get/set_hard_smp_proccessor_id into inlines powerpc: Expose PMCs cache topology in sysfs on 32-bit David Gibson (1): powerpc: Update in-kernel dtc and libfdt to version 1.2.0 Harvey Harrison (2): powerpc: Use the common ascii hex helpers powerpc: Replace __FUNCTION__ with __func__ Michael Ellerman (5): powerpc: Streamline ret_from_except_lite for non-iSeries platforms powerpc: fsl_msi doesn't need it's own of_node powerpc: Split-out common MSI bitmap logic into msi_bitmap.c powerpc: Convert the FSL MSI code to use msi_bitmap powerpc: Convert the MPIC MSI code to use msi_bitmap Nathan Lynch (1): powerpc: Remove redundant sysfs_remove_file calls for cache info Stephen Rothwell (4): powerpc: Remove include of linux/of_platform.h from asm/of_platform.h hotplug/rpaphp: Remove unused error path code powerpc/drivers: Use linux/of_device.h instead of asm/of_device.h powerpc: Remove include of linux/of_device.h from asm/of_device.h Tony Breeds (3): powerpc: Guard htab_dt_scan_hugepage_blocks appropriately powerpc: Guard from_rtc_time() in platforms/powermac/time.c powerpc: Guard print_device_node_tree() with #if 0 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
On Wed, 2008-08-20 at 16:55 -0400, Steven A. Falco wrote: I have just tried enabling I2C on a Sequoia board (kernel is DENX 2.6.26) and doing that appears to corrupt the u-boot / kernel communications. Prior to turning on I2C, I see the ethernet mac and kernel command line correctly passed, but once I turn on I2C, the ethernet mac becomes 0 and the kernel command line is missing many parameters. I'll paste in a good log, then a bad one. The only configuration difference is that the bad one has CONFIG_I2C_CHARDEV=y and CONFIG_I2C_IBM_IIC=y in the configuration. I'll start digging into it, but if anyone has any experience or ideas regarding I2C on PPC440, I'd appreciate your thoughts on this. Steve Good log: = ## Booting kernel from Legacy Image at fd40 ... Image Name: Linux-2.6.26.1-00033-g088efe4-di Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1801234 Bytes = 1.7 MB Load Address: 0040 Entry Point: 00400454 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading init Ramdisk from Legacy Image at fd90 ... Image Name: initramfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:2442283 Bytes = 2.3 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fcb8000, end 0ff0c42b ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) Memory - 0x0 0x0 0x000 (255MB) ENET0: local-mac-address - 00:10:ec:01:04:d0 ENET1: local-mac-address - 00:10:ec:01:04:d1 zImage starting: loaded at 0x0040 (sp: 0x0ff0d220) Allocating 0x3dbc2c bytes for kernel ... gunzipping (0x - 0x0040e000:0x007ed9c8)...done 0x39c1c4 bytes Using loader supplied ramdisk at 0xfcb8000-0xff0c42b initrd head: 0x1f8b0808 Linux/PowerPC load: root=/dev/sda3 rw ip=137.237.178.105:137.237.179.31:137.237.178.1:255.255.255.0:hydra_temp:eth0:off panic=1 console=ttyS0,115200 Bad log: ## Booting kernel from Legacy Image at fd40 ... Image Name: Linux-2.6.26.1-00034-gf084326-di Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1811651 Bytes = 1.7 MB Load Address: 0040 Entry Point: 00400454 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Loading init Ramdisk from Legacy Image at fd90 ... Image Name: initramfs Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:2442283 Bytes = 2.3 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 0fcb8000, end 0ff0c42b ... OK CPU clock-frequency - 0x27bc86a4 (667MHz) CPU timebase-frequency - 0x27bc86a4 (667MHz) /plb: clock-frequency - 9ef21a9 (167MHz) /plb/opb: clock-frequency - 4f790d4 (83MHz) /plb/opb/ebc: clock-frequency - 34fb5e3 (56MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) /plb/opb/[EMAIL PROTECTED]: clock-frequency - a8c000 (11MHz) Memory - 0x0 0x0 0x000 (255MB) ENET0: local-mac-address - 00:00:00:00:00:00 ENET1: local-mac-address - 00:00:00:00:00:00 zImage starting: loaded at 0x0040 (sp: 0x0ff0d220) Allocating 0x3e1c48 bytes for kernel ... gunzipping (0x - 0x0040e000:0x007f3a24)...done 0x3a21c4 bytes Using loader supplied ramdisk at 0xfcb8000-0xff0c42b initrd head: 0x1f8b0808 Linux/PowerPC load: console=ttyS0,115200 That's all output from the wrapper, not the kernel. And the kernel config doesn't make a difference at all to the wrapper. I wonder if there is some weird size issue going on there or if whatever U-Boot version you are using is doing odd things... josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] mtd: add OF2PDEV convertor for the NDFC driver
On Wed, 20 Aug 2008 20:37:19 -0400 Josh Boyer [EMAIL PROTECTED] wrote: On Thu, 21 Aug 2008 00:40:58 +0200 Arnd Bergmann [EMAIL PROTECTED] wrote: On Wednesday 20 August 2008, Sebastian Siewior wrote: I didn't convert the NDFC driver to support OF because there are non-OF-aware platforms with the ndfc chip. All settings are mandatory except the oob layout. Are you aware of Sean's patch from http://patchwork.ozlabs.org/linuxppc/patch?id=20183 ? I need to look at that hard for .28 still. Please do, I know it works, but I am not sure it is correct. I haven't had a chance to really look at the new driver from Sebastian, but it is more complete than mine. It has to be decided if that is a good thing. I modeled my driver after the existing nand of drivers. They also limit, even more than mine, what can be configured. My gut feel is that it is better to let the upper level nand drivers default correctly based on the chip. For example, on the warp we need to let the ecc layout default since then it can handle the differences between 64M and 256M nand chips without a fixup at boot time. (I believe Sebastian's driver *does* allow this) I also believe that some fields are now obsolete when going to an of platform driver. For example, chip select is part of the reg entry. So my goal was to configure as little as possible and then add as needed. Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Strange behavior with I2C on Sequoia board
On Wed, 20 Aug 2008 20:44:23 -0400 Josh Boyer [EMAIL PROTECTED] wrote: That's all output from the wrapper, not the kernel. And the kernel config doesn't make a difference at all to the wrapper. I wonder if there is some weird size issue going on there or if whatever U-Boot version you are using is doing odd things... Any chance something in the DTS could affect it? Maybe try commenting out the second IIC controller? Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
boot cuImage on an old u-boot
I have here a mpc8540ads board and a u-boot 1.0.0. I've build the defconfig for the board and I tried to boot the genarated cuImage.mpc8540ads image. After the bootm command I see just |8540 bootm 100 |## Booting image at 0100 ... | Image Name: Linux-2.6.26 | Image Type: PowerPC Linux Kernel Image (gzip compressed) | Data Size:1232711 Bytes = 1.2 MB | Load Address: 0040 | Entry Point: 004005ac | Verifying Checksum ... OK | Uncompressing Kernel Image ... OK | I don't see the device tree fixups printfs, so crash happend quite early. Anyone an idea what I could have done wrong? Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc/cell/oprofile: fix mutex locking for spu-oprofile
Arnd Bergmann writes: Paul, any chance we can still get this into 2.6.27? Possibly. We'll need a really good explanation for Linus as to why this is needed (what regression or serious bug this fixes) and why it is late. Can you send me something explaining that? I've added the Ack and uploaded it again for you to pull from master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git merge Are you sure you actually managed to update that? $ git ls-remote master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git merge f90a87b5f5fa46dc6c556e9267a6f25a95fbef14refs/heads/merge and f90a87b5f5fa46dc6c556e9267a6f25a95fbef14 is the same commit from 2008-08-09 that you asked me to pull previously. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix memory leaks in QE library
On Aug 18, 2008, at 4:12 PM, Timur Tabi wrote: Fix two memory leaks in the Freescale QE library: add a missing kfree() in ucc_fast_init() if the ioremap() fails, and update ucc_fast_free() to call iounmap() on uf_regs. Based on a patch from Tony Breeds [EMAIL PROTECTED]. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- arch/powerpc/sysdev/qe_lib/ucc_fast.c |4 1 files changed, 4 insertions(+), 0 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull from 'for-2.6.27' branch
Please pull from 'for-2.6.27' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.27 to receive the following updates: arch/powerpc/boot/dts/mpc8641_hpcn.dts |2 - arch/powerpc/boot/dts/tqm8548-bigflash.dts |8 +- arch/powerpc/boot/dts/tqm8548.dts |3 +- arch/powerpc/sysdev/qe_lib/ucc_fast.c |4 +++ drivers/serial/Kconfig | 36 - 5 files changed, 14 insertions(+), 39 deletions(-) Kumar Gala (2): powerpc: Fix whitespace merge in mpc8641 hpcn device tree serial/cpm_uart: Remove dead Kconfig options Timur Tabi (1): powerpc: fix memory leaks in QE library Wolfgang Grandegger (1): powerpc/85xx: TQM8548: DTS file fixes and cleanup ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: fix memory leaks in QE library
On Aug 20, 2008, at 10:29 AM, Timur Tabi wrote: Fix two memory leaks in the Freescale QE library: add a missing kfree() in ucc_fast_init() and ucc_slow_init() if the ioremap() fails, and update ucc_fast_free() and ucc_slow_free() to call iounmap() if necessary. Based on a patch from Tony Breeds [EMAIL PROTECTED]. Signed-off-by: Timur Tabi [EMAIL PROTECTED] --- arch/powerpc/sysdev/qe_lib/ucc_fast.c |4 arch/powerpc/sysdev/qe_lib/ucc_slow.c |8 +--- 2 files changed, 9 insertions(+), 3 deletions(-) applied. (this just became ucc_slow since I had already applied v1). - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: powerpc allmodconfig in current -mm
Andrew Morton writes: /opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-ld: .tmp_vmlinux1: section .data.gcov lma 0xc2c2bb78 overlaps previous sections I suspect your binutils are too old, and the stress that the gcov stuff puts on the toolchain is showing up a bug in ld. powerpc allmodconfig: ERROR: CMO_PageSize [arch/powerpc/platforms/pseries/cmm.ko] undefined! (needed for 2.6.27) OK. I think we need to export CMO_PrPSP and CMO_SecPSP as well. (Lovely names. :() Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [patch 1/4] powerpc: Fix typo in pgtable-ppc64.h
Geoff Levand writes: Fix a minor comment typo in pgtable-ppc64.h. I don't see why this needs to go in 2.6.27. See Linus' recent comments on what should go in outside the merge window: http://lkml.org/lkml/2008/8/20/251 I'll queue it for 2.6.28. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: cpm2: Fix race condition in CPM2 GPIO library.
On Aug 19, 2008, at 7:20 AM, Laurent Pinchart wrote: The CPM2 GPIO library code uses the non thread-safe clrbits32/ setbits32 macros. This patch protects them with a spinlock. Signed-off-by: Laurent Pinchart [EMAIL PROTECTED] --- arch/powerpc/sysdev/cpm_common.c | 37 + +--- 1 files changed, 26 insertions(+), 11 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6 patch] Add cuImage.mpc866ads to the bootwrapper as a cuboot-8xx target
Hi all, Anyone going to add this patch to some tree (I have had it in linux-next for a while). http://patchwork.ozlabs.org/linuxppc/patch?id=19962 On Thu, 31 Jul 2008 19:10:22 +0300 Adrian Bunk [EMAIL PROTECTED] wrote: From: Scott Wood [EMAIL PROTECTED] This patch fixes the following build error with mpc866_ads_defconfig: -- snip -- ... WRAParch/powerpc/boot/cuImage.mpc866ads powerpc64-linux-ld: arch/powerpc/boot/cuboot-mpc866ads.o: No such file: No such file or directory make[2]: *** [arch/powerpc/boot/cuImage.mpc866ads] Error 1 -- snip -- Reported-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Scott Wood [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- This patch was sent by Scott Wood on: - 21 May 2008 arch/powerpc/boot/wrapper |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper index d6c96d9..3b59e33 100755 --- a/arch/powerpc/boot/wrapper +++ b/arch/powerpc/boot/wrapper @@ -159,7 +159,7 @@ cuboot*) binary=y gzip= case $platform in -*-mpc885ads|*-adder875*|*-ep88xc) +*-mpc866ads|*-mpc885ads|*-adder875*|*-ep88xc) platformo=$object/cuboot-8xx.o ;; *5200*|*-motionpro) -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ pgpEw9nUTDQtj.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc/83xx: mpc836x_mds: add support for the nor flash
On Aug 14, 2008, at 12:13 PM, Anton Vorontsov wrote: This patch adds the localbus node, moves the bcsr node into the localbus node, and adds the flash node. Also enable MTD support in the defconfig. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] --- arch/powerpc/boot/dts/mpc836x_mds.dts | 23 ++- arch/powerpc/configs/83xx/mpc836x_mds_defconfig | 79 ++ - 2 files changed, 98 insertions(+), 4 deletions(-) applied to powerpc-next. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6 patch] Add cuImage.mpc866ads to the bootwrapper as a cuboot-8xx target
On Jul 31, 2008, at 11:10 AM, Adrian Bunk wrote: From: Scott Wood [EMAIL PROTECTED] This patch fixes the following build error with mpc866_ads_defconfig: -- snip -- ... WRAParch/powerpc/boot/cuImage.mpc866ads powerpc64-linux-ld: arch/powerpc/boot/cuboot-mpc866ads.o: No such file: No such file or directory make[2]: *** [arch/powerpc/boot/cuImage.mpc866ads] Error 1 -- snip -- Reported-by: Adrian Bunk [EMAIL PROTECTED] Signed-off-by: Scott Wood [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
