* Re: [Kgdb-bugreport] KGDBOC testing on linux-2.6.30-rc4
From: srikanth krishnakar @ 2009-05-05 12:59 UTC (permalink / raw)
To: Jason Wessel; +Cc: kgdb-bugreport
In-Reply-To: <4A0029E0.3000008@windriver.com>
[-- Attachment #1: Type: text/plain, Size: 3297 bytes --]
On Tue, May 5, 2009 at 5:28 PM, Jason Wessel <jason.wessel@windriver.com>wrote:
> srikanth krishnakar wrote:
> > Hi all,
> >
> > Target : PowerPC, Virtex-440 Generic
> > Serial port : Xilinx 16550 Uart ( depends on OF_PLATFORM)
> >
> > Further investigation of KGDBOC on PowerPC shows that kgdboc hangs at :
> >
> > In file : arch/powerpc/include/asm/kgdb.h
> >
> > *static inline void* arch_kgdb_breakpoint(*void*)
> > {
> > *asm*(*".long 0x7d821008"*); /* *twge r2, r2 **/ * << ----
> > KGDBOC Hangs here* * << ---*
> >
> >
> > -----------------------------------------
> > Debug Log:
> >
> > root@10.1.2.55:~# echo g >
> > /proc/sysrq-trigger
> > SysRq :
> > GDB
> >
> > 1------------------------>sysrq_handle_gdb
> >
> > Entering KGDB
> > 1-1----------------------->kgdb_breakpoint
> > 1-2----------------------->kgdb_breakpoint
> > 1-3----------------------->kgdb_breakpoint
> > 1-1----------------------->arch_kgdb_breakpoint
> >
> > ---------------------------------------------
> >
> >
> > Any comments or suggestions ????
> >
>
> I had used the 2.6.30-rc3 kernel with the PowerPC 604 system I have and
> it was working fine, but the 4xx archs are a bit different.
>
> What happens next after you execute the inline assembly is that an
> exception occurs, and that is the point that the kgdb entry will
> actually execute. IE:
>
> arch/powerpc/kernel/traps.c
>
> program_check_exception()
>
> From there kgdb should be entered and the I/O driver gets activated.
> You could put another printk in kgdb_handle_exception() in kernel/kgdb.c
> to make sure it actually gets there.
>
> Generally when the system hangs hard on an initial entry to kgdb it
> means there is a problem with the I/O polling driver or there is
> something else eating the kgdb exception and the kgdb exception handler
> was never fired in the first place.
>
> Jason.
>
Hi Jason,
Re attempted with inserting a printk in kernel/kgdb.c
kgdb_handle_exception() function but seems the kgdb exception has never
occurred !!
------------------
Debug Log:
root@10.1.2.55:~# echo g > /proc/sysrq-trigger
SysRq : GDB
1------------------------>sysrq_handle_gdb
Entering KGDB
1-1----------------------->kgdb_breakpoint
1-2----------------------->kgdb_breakpoint
1-3----------------------->kgdb_breakpoint
1-1----------------------->arch_kgdb_breakpoint
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
-------------------
Inserted printk's in kernel kgdb.c :
int
kgdb_handle_exception(int evector, int signo, int ecode, struct pt_regs
*regs)
{
printk("1------------------------>%s\n",__FUNCTION__);
if (kgdb_reenter_check(ks)) {
-----------------------------
*Does the PowerPC uses PowerPC64 hooks ??*
as seen below from arch/powerpc/kernel/kgdb.c
/* KGDB functions to use existing PowerPC64 hooks. */
static int kgdb_debugger(struct pt_regs *regs)
{
printk("1------------------------>%s\n",__FUNCTION__);
return *kgdb_handle_exception*(0, computeSignal(TRAP(regs)), 0,
regs);
-------------------------------
Thanks For your co-operation, patience and help.
Regards
Srikanth
**********
[-- Attachment #2: Type: text/html, Size: 5129 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Steven Rostedt @ 2009-05-05 13:33 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Sam Ravnborg
In-Reply-To: <6A6BE346-925C-4F73-ABFA-C6110070F071@kernel.crashing.org>
On Tue, 2009-05-05 at 09:56 +0200, Segher Boessenkool wrote:
> > Yeah, I agree. This needs a better description. I only know what's
> > going
> > on because I was there for the start of the discussion.
> >
> > But just to be sure, this is what I think is happening.
> >
> > When we add "-pg" to gcc, it automatically causes frame pointers to be
> > used.
>
> Nope, it does no such thing.
Well, mcount is expected to be able to get to not just who called
mcount, but also the parent of that function. The way mcount is
implemented does not let you do that. If mcount was the first thing to
be called in a function, then it would have been perfect. We could get
to the caller, its parent, and even the parameters. But unfortunately,
mcount is called after the stack is set up. Thus, without frame pointers
(the way to find a previous frame) there's no way (on some archs) to
find the parent. Nor can we figure out the parameters, which really
sucks.
>
> > But with PPC, it always has frame pointers and there's no problem.
>
> Well, what do you call a "frame pointer"? In the general meaning
> of "some register that points to the incoming function arguments
> and the function local variables", PowerPC can _usually_ use GPR1,
> the stack pointer (and indeed it is called "stack frame pointer"
> in the ABI). In the more narrow meaning of "what GCC calls the
> frame pointer", "the thing that -fomit-frame-pointer optimises
> away" -- on PowerPC (and many other targets), -fomit-frame-pointer
> is the *default* when optimisation is enabled!
>
> There is a GCC bug here though: it won't allow both -pg and
> -fomit-frame-pointer be set at the command line at the same time,
> even on targets where that is not problematic.
>
> > But with Linux, when you add CONFIG_FRAME_POINTER, it automatically
> > adds: -fno-omit-frame-pointer. Thus the config will add
> > "-fomit-frame-pointer" when CONFIG_FRAME_POINTER is not set, or it
> > will
> > add "-fno-omit-frame-pointer" when it is set.
> >
> > The problem with PPC is that "-fno-omit-frame-pointer" is buggy and
> > causes gcc to produce bad code.
>
> It's a deeper problem that is only _exposed_ by -fno-o-f-p (and can be
> hidden by -mno-sched-epilog in the one spot where it hit us).
>
> > Perhaps a better name would be:
> >
> > HAVE_FRAME_POINTER_AS_DEFAULT
>
> NO_NO_OMIT_FRAME_POINTER ? Or better, just never use -fno-o-f-p,
> I don't see why you would ever need it.
Because on x86_64 it gives better back traces. x86_64 has no way to get
to the previous frames without it. There's code to use other debug
metadata to get back tracing, but for uses of things like the stack
tracer, we need to be able to use the actual stack frames.
As you said above, -fomit-frame-pointer is default when we optimize, and
that is how the kernel is built. If we optimize on x86_64 and do not use
-fno-omit-frame-pointer, the stack tracer is useless.
-- Steve
^ permalink raw reply
* Re: [PATCH 2.6.30-rc5] ehea: fix invalid pointer access
From: Hannes Hering @ 2009-05-05 13:45 UTC (permalink / raw)
To: David Howells
Cc: themann, netdev, linux-kernel, ossrosch, linuxppc-dev, raisch,
ossthema, osstklei, David Miller
In-Reply-To: <26110.1241525994@redhat.com>
On Tuesday 05 May 2009 14:19:54 David Howells wrote:
> In that case, you might want to move the prefetchw() calls in the following:
>
> pref = skb_array[x];
> - prefetchw(pref);
> - prefetchw(pref + EHEA_CACHE_LINE);
> + if (pref) {
> + prefetchw(pref);
> + prefetchw(pref + EHEA_CACHE_LINE);
>
> to before the if-statement. That way the CPU can be attempting the prefetch
> whilst it's chewing over the test and branch. prefetching shouldn't fault on
> a bad address.
>
> David
Hi David,
you are right so far, but actually the prefetch calls on POWER also contain
an if statement to check if the address is valid (i. e. non-zero). We never
have the case that the pref != NULL and pref->data == NULL. And the situation
of pref==NULL is very rare. This means there is no benefit moving our if
statement down from performance perspective if we assume that our if does not
take longer then the if in the prefetch command. We can add an
if(likely(pref) if you like. In fact doing the if statement as we do it now
we actually save the prefetch if statements in case we hit the situation of
pref==NULL.
Regards
Hannes
^ permalink raw reply
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Segher Boessenkool @ 2009-05-05 13:51 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Sam Ravnborg
In-Reply-To: <1241530382.11379.12.camel@localhost.localdomain>
>>> When we add "-pg" to gcc, it automatically causes frame pointers
>>> to be
>>> used.
>>
>> Nope, it does no such thing.
>
> Well, mcount is expected to be able to get to not just who called
> mcount, but also the parent of that function. The way mcount is
> implemented does not let you do that. If mcount was the first thing to
> be called in a function, then it would have been perfect. We could get
> to the caller, its parent, and even the parameters. But unfortunately,
> mcount is called after the stack is set up. Thus, without frame
> pointers
> (the way to find a previous frame) there's no way (on some archs) to
> find the parent. Nor can we figure out the parameters, which really
> sucks.
Yes, and this is (supposedly) why GCC does not like seeing -pg and
-fomit-frame-pointer at the same time -- because that cannot work
*on some architectures*. These are the same architectures that
do not enable -fomit-frame-pointer automatically at -O.
>> NO_NO_OMIT_FRAME_POINTER ? Or better, just never use -fno-o-f-p,
>> I don't see why you would ever need it.
>
> Because on x86_64 it gives better back traces. x86_64 has no way to
> get
> to the previous frames without it. There's code to use other debug
> metadata to get back tracing, but for uses of things like the stack
> tracer, we need to be able to use the actual stack frames.
>
> As you said above, -fomit-frame-pointer is default when we
> optimize, and
> that is how the kernel is built. If we optimize on x86_64 and do
> not use
> -fno-omit-frame-pointer, the stack tracer is useless.
No. -fomit-frame-pointer is only the default when optimising on
archs/ABIs where it doesn't hinder debugging and -pg and all that
goodness; specifically, you do not get it by default on x86, not
at any optimisation level.
Segher
^ permalink raw reply
* Re: help with MPC8272ADS board
From: Scott Wood @ 2009-05-05 15:52 UTC (permalink / raw)
To: Landau, Bracha; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <065A7D06F7D4E546A18E80E08D066E18118931C627@ILMA1.IL.NDS.COM>
Landau, Bracha wrote:
> I've upgraded to the latest kernel (2.6.29), and after updating the configuration the cuImage did boot.
> What's the difference between the address for the early debug console for cuImage and uImage + blob?
The address is wherever the previous driver (u-boot or bootwrapper) put
the transmit descriptor. The default address matches what Linux's
bootwrapper uses, but u-boot is a bit different (IIRC it's DPRAM+0x88).
-Scott
^ permalink raw reply
* [Patch] powerpc/cell: make ptcal more reliable (V2)
From: stenzel @ 2009-05-05 15:58 UTC (permalink / raw)
To: linuxppc-dev; +Cc: jk, arnd
===================================================================
This is for QS21. The following patch allocates pages only from
the specified node, moves the ptcal area into the middle of the
allocated page to avoid potential prefetch problems and prints
the address of the ptcal area to facilitate diagnostics.
Signed-off-by: Gerhard Stenzel <gerhard.stenzel@de.ibm.com>
Index: linux-2.6/arch/powerpc/platforms/cell/ras.c
===================================================================
--- linux-2.6.orig/arch/powerpc/platforms/cell/ras.c
+++ linux-2.6/arch/powerpc/platforms/cell/ras.c
@@ -122,12 +122,23 @@ static int __init cbe_ptcal_enable_on_no
area->nid = nid;
area->order = order;
- area->pages = alloc_pages_node(area->nid, GFP_KERNEL, area->order);
+ area->pages = alloc_pages_node(area->nid, GFP_KERNEL | GFP_THISNODE,
+ area->order);
- if (!area->pages)
+ if (!area->pages) {
+ printk(KERN_WARNING "%s: no page on node %d\n",
+ __func__, area->nid);
goto out_free_area;
+ }
- addr = __pa(page_address(area->pages));
+ /*
+ * We move the ptcal area to the middle of the allocated
+ * page, in order to avoid prefetches in memcpy and similar
+ * functions stepping on it.
+ */
+ addr = __pa(page_address(area->pages)) + (PAGE_SIZE >> 1);
+ printk(KERN_DEBUG "%s: enabling PTCAL on node %d address=0x%016lx\n",
+ __func__, area->nid, addr);
ret = -EIO;
if (rtas_call(ptcal_start_tok, 3, 1, NULL, area->nid,
===================================================================
Best regards,
Gerhard Stenzel, Linux on Cell Development, LTC
-------------------------------------------------------------------------------------
IBM Deutschland Entwicklung GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschaeftsfuehrung: Erich Baier
Sitz der Gesellschaft: Boeblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* modprobe problem
From: Carlos Roberto Moratelli @ 2009-05-05 16:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <mailman.7049.1241524613.26545.linuxppc-dev@ozlabs.org>
Hello,
I have a Kernel 2.6.24 running on a custom board based on mpc8313erdb.
My filesystem is composed by a read-only squashfs and a read-write jffs2
filesystems. A unionfs is used to unificate the filesystems.
Like you know, when a file on my read-only squasfs is modified such file
is copied to read-write jffs2 partition by unionfs. So, when you try to
read such file again, the modified copy on jffs2 will be used.
The kernel modules (.ko) are on squashfs and I am using modprobe to load
the kernel modules.
THE PROBLEM is when I try load a module using modprobe, this module is
copied from squashfs to jffs2 filesystem. But, my intention is not
modify the module, just load it.
I am supposing that is a problem because the modules are using
duplicated space in flash and I don't want to store the modules in jffs2
because the compression is lower.
Does someone know why this happend?
Thanks,
Moratelli
^ permalink raw reply
* Re: PPC8247 booting error
From: Scott Wood @ 2009-05-05 16:26 UTC (permalink / raw)
To: Sauce.Cheng; +Cc: linuxppc-dev
In-Reply-To: <23381214.post@talk.nabble.com>
On Mon, May 04, 2009 at 10:23:50PM -0700, Sauce.Cheng wrote:
> i want to mapping FIFO memory to bank 3 by configure br3 and or3
> the boot info as following.
>
> in my code, i have mapped FIFO to 0xD0000000, then i red the value from this
> address.
>
> the prompts as following
>
> there is some wrong with BRx and ORx set? or something others?
You need to pass your physical address (0xd0000000) to ioremap() to
obtain a virtual address that you can dereference.
> scheduling while atomic: swapper/0x00000002/0
>
> Call trace: [c015fe20] [c0003fe0] [c01a09b4] [c0194614] [000035fc]
You've got another problem here that you'll want to look into.
-Scott
^ permalink raw reply
* [PATCH] Fix wrong register read address and add interrupt acknowledge.
From: Benjamin Krill @ 2009-05-05 19:11 UTC (permalink / raw)
To: linuxppc-dev, linux-serial; +Cc: arnd
The receive interrupt routine checks the wrong register if the
receive fifo is empty. Further an explicit interrupt acknowledge
write is introduced. In some circumstances another interrupt was
issued.
Signed-off-by: Benjamin Krill <ben@codiert.org>
---
drivers/serial/nwpserial.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/nwpserial.c b/drivers/serial/nwpserial.c
index 32f3eaf..9e150b1 100644
--- a/drivers/serial/nwpserial.c
+++ b/drivers/serial/nwpserial.c
@@ -145,11 +145,13 @@ static irqreturn_t nwpserial_interrupt(int irq, void *dev_id)
ch = dcr_read(up->dcr_host, UART_RX);
if (up->port.ignore_status_mask != NWPSERIAL_STATUS_RXVALID)
tty_insert_flip_char(tty, ch, TTY_NORMAL);
- } while (dcr_read(up->dcr_host, UART_RX) & UART_LSR_DR);
+ } while (dcr_read(up->dcr_host, UART_LSR) & UART_LSR_DR);
tty_flip_buffer_push(tty);
ret = IRQ_HANDLED;
+ /* clear interrupt */
+ dcr_write(up->dcr_host, UART_IIR, 1);
out:
spin_unlock(&up->port.lock);
return ret;
--
1.5.4.5
^ permalink raw reply related
* Re: [PATCH] Fix wrong register read address and add interrupt acknowledge.
From: Timur Tabi @ 2009-05-05 19:24 UTC (permalink / raw)
To: Benjamin Krill; +Cc: linuxppc-dev, arnd, linux-serial
In-Reply-To: <20090505191116.GA7267@codiert.org>
On Tue, May 5, 2009 at 2:11 PM, Benjamin Krill <ben@codiert.org> wrote:
> The receive interrupt routine checks the wrong register if the
> receive fifo is empty. Further an explicit interrupt acknowledge
> write is introduced. In some circumstances another interrupt was
> issued.
The one-line summary of your patch is too vague. It should mention
the name of the driver somehow.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Setting Kernel Allocated Memory Uncached on the PPC460
From: Timur Tabi @ 2009-05-05 21:16 UTC (permalink / raw)
To: Judd Gilbert; +Cc: linuxppc-dev
In-Reply-To: <16691A8B34B5D9458EA3A1C37A11555A01351C87@tanisys-ex2.Tanisys.Local>
On Mon, May 4, 2009 at 1:55 PM, Judd Gilbert <JuddG@tanisys.com> wrote:
> I have a driver which maps some kernel allocated memory to user space which
> works, and now I am trying to set that memory non-cacheable, on a power PC
> using the Denx ELDK (linux-2.6.24) on a PPC460ex.
Because of the way the kernel maps main memory, you cannot do this.
It is a violation of the PowerPC architecture to map a particular
memory address as both cached and uncached (using different TLB
entries) at the same time. When the kernel boots, it uses large
mappings to map all of memory as cached. There is no mechanism to
punch holes in these mappings. Therefore, if the memory is already
mapped cached by the kernel, you cannot remap it as uncached.
The only way around this is to use high memory, which is not mapped by
the kernel normally. You can "bring in" a high memory page and map it
uncached. However, I don't think there is a way for you to manually
specify certain memory to be high.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: MSR_SPE - being turned off...
From: Kumar Gala @ 2009-05-05 21:18 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90110C30D34@EMPBEDEX.empirix.com>
On May 5, 2009, at 7:56 AM, Morrison, Tom wrote:
> Hi Kumar/Michael...
>
> Sorry, I really didn't explain myself very well...
>
> The Problem (answer to Michael):
> ================================
> We started using a new compiler that upon -O2 optimization - added
> heavy SPE related instructions into our applications (where the older
> compiler might not use as many). Once this was done, we started
> experiencing problems with data being 'shifted' and/or corrupted
> throughout the applications which didn't immediately cause problems,
> but either scribbled on someone else's memory and/or bad results...
> We knew where one of the offending scribbles started (by the shifting
> by 1 byte of a structure) and found by comparing binaries with 'older'
> compiler vs. this one that the only major difference was the 'density'
> of the SPE instructions...
>
> As to your question, Kumar:
> ===========================
> Naively, I explicitly enabled the SPE in a BSP 'early_init' program
> (as well as enabling Machine Checks) - which is what I meant by
> Enabling SPE...
Are you setting MSR_SPE in your own board code? If so stop doing so.
There isn't any need or reason to be doing that. MSR_SPE will get set
when an application starts using SPE code and the kernel will manage
it properly.
- k
^ permalink raw reply
* [PATCH v7] introduce macro spin_event_timeout()
From: Timur Tabi @ 2009-05-05 21:53 UTC (permalink / raw)
To: linuxppc-dev, galak, benh, scottwood, smaclennan, jwboyer
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware register until a
status bit changes. The timeout ensures that the loop still terminates if the
bit doesn't change as expected. This macro makes it easier for driver
developers to perform this kind of operation properly.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
v7: add if-statement to use cpu_relax() if the delay is 0. gcc will optimize
out the if-statement if 'delay' is a constant.
I'm making this a PowerPC-specific patch because I want to use
tb_ticks_per_usec, which does not exist on all other platforms. I don't want
to use jiffies because jiffies works only when interrupts are enabled, and
the resolution may not be fine enough.
arch/powerpc/include/asm/delay.h | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/delay.h b/arch/powerpc/include/asm/delay.h
index f9200a6..2bde26f 100644
--- a/arch/powerpc/include/asm/delay.h
+++ b/arch/powerpc/include/asm/delay.h
@@ -2,6 +2,8 @@
#define _ASM_POWERPC_DELAY_H
#ifdef __KERNEL__
+#include <asm/time.h>
+
/*
* Copyright 1996, Paul Mackerras.
*
@@ -30,5 +32,35 @@ extern void udelay(unsigned long usecs);
#define mdelay(n) udelay((n) * 1000)
#endif
+/**
+ * spin_event_timeout - spin until a condition gets true or a timeout elapses
+ * @condition: a C expression to evalate
+ * @timeout: timeout, in microseconds
+ * @delay: the number of microseconds to delay between eache evaluation of
+ * @condition
+ * @rc: the last value of the condition
+ *
+ * The process spins until the condition evaluates to true (non-zero) or the
+ * timeout elapses. Upon exit, @rc contains the value of the condition. This
+ * allows you to test the condition without incurring any side effects.
+ *
+ * This primary purpose of this macro is to poll on a hardware register
+ * until a status bit changes. The timeout ensures that the loop still
+ * terminates even if the bit never changes. The delay is for devices that
+ * need a delay in between successive reads.
+ *
+ * gcc will optimize out the if-statement if @delay is a constant.
+ */
+#define spin_event_timeout(condition, timeout, delay, rc) \
+{ \
+ unsigned long __loops = tb_ticks_per_usec * timeout; \
+ unsigned long __start = get_tbl(); \
+ while (!(rc = (condition)) && (tb_ticks_since(__start) <= __loops)) \
+ if (delay) \
+ udelay(delay); \
+ else \
+ cpu_relax(); \
+}
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_DELAY_H */
--
1.6.0.6
^ permalink raw reply related
* Re: Setting Kernel Allocated Memory Uncached on the PPC460
From: Josh Boyer @ 2009-05-05 23:08 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, Judd Gilbert
In-Reply-To: <ed82fe3e0905051416u79e431bdy8544a437c79c1cd1@mail.gmail.com>
On Tue, May 05, 2009 at 04:16:45PM -0500, Timur Tabi wrote:
>On Mon, May 4, 2009 at 1:55 PM, Judd Gilbert <JuddG@tanisys.com> wrote:
>> I have a driver which maps some kernel allocated memory to user space which
>> works, and now I am trying to set that memory non-cacheable, on a power PC
>> using the Denx ELDK (linux-2.6.24) on a PPC460ex.
>
>Because of the way the kernel maps main memory, you cannot do this.
>It is a violation of the PowerPC architecture to map a particular
>memory address as both cached and uncached (using different TLB
>entries) at the same time. When the kernel boots, it uses large
>mappings to map all of memory as cached. There is no mechanism to
>punch holes in these mappings. Therefore, if the memory is already
>mapped cached by the kernel, you cannot remap it as uncached.
>
>The only way around this is to use high memory, which is not mapped by
>the kernel normally. You can "bring in" a high memory page and map it
>uncached. However, I don't think there is a way for you to manually
>specify certain memory to be high.
That isn't entirely true. You can always limit the memory mapped via the
kernel with mem= (or via a memreserve), and then have a driver ioremap the
now unused memory.
josh
^ permalink raw reply
* Re: [PATCH] Fix wrong register read address and add interrupt acknowledge.
From: Josh Boyer @ 2009-05-05 23:09 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev, arnd, linux-serial
In-Reply-To: <ed82fe3e0905051224j30a54ef3s3d5e6c88987ea65a@mail.gmail.com>
On Tue, May 05, 2009 at 02:24:04PM -0500, Timur Tabi wrote:
>On Tue, May 5, 2009 at 2:11 PM, Benjamin Krill <ben@codiert.org> wrote:
>> The receive interrupt routine checks the wrong register if the
>> receive fifo is empty. Further an explicit interrupt acknowledge
>> write is introduced. In some circumstances another interrupt was
>> issued.
>
>The one-line summary of your patch is too vague. It should mention
>the name of the driver somehow.
That is quite true. Although resending the patch just for that seems overkill.
The maintainer can edit the summary rather easily.
josh
^ permalink raw reply
* Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely select CONFIG_FRAME_POINTER
From: Steven Rostedt @ 2009-05-05 23:11 UTC (permalink / raw)
To: Segher Boessenkool
Cc: linux-kernel, linuxppc-dev, Paul Mackerras, Ingo Molnar,
Sam Ravnborg
In-Reply-To: <299D7402-29D3-4602-8F42-58FDF034DEC5@kernel.crashing.org>
On Tue, 2009-05-05 at 15:51 +0200, Segher Boessenkool wrote:
> >>> When we add "-pg" to gcc, it automatically causes frame pointers
> >>> to be
> >>> used.
> >>
> >> Nope, it does no such thing.
> >
> > Well, mcount is expected to be able to get to not just who called
> > mcount, but also the parent of that function. The way mcount is
> > implemented does not let you do that. If mcount was the first thing to
> > be called in a function, then it would have been perfect. We could get
> > to the caller, its parent, and even the parameters. But unfortunately,
> > mcount is called after the stack is set up. Thus, without frame
> > pointers
> > (the way to find a previous frame) there's no way (on some archs) to
> > find the parent. Nor can we figure out the parameters, which really
> > sucks.
>
> Yes, and this is (supposedly) why GCC does not like seeing -pg and
> -fomit-frame-pointer at the same time -- because that cannot work
> *on some architectures*. These are the same architectures that
> do not enable -fomit-frame-pointer automatically at -O.
>
> >> NO_NO_OMIT_FRAME_POINTER ? Or better, just never use -fno-o-f-p,
> >> I don't see why you would ever need it.
> >
> > Because on x86_64 it gives better back traces. x86_64 has no way to
> > get
> > to the previous frames without it. There's code to use other debug
> > metadata to get back tracing, but for uses of things like the stack
> > tracer, we need to be able to use the actual stack frames.
> >
> > As you said above, -fomit-frame-pointer is default when we
> > optimize, and
> > that is how the kernel is built. If we optimize on x86_64 and do
> > not use
> > -fno-omit-frame-pointer, the stack tracer is useless.
>
> No. -fomit-frame-pointer is only the default when optimising on
> archs/ABIs where it doesn't hinder debugging and -pg and all that
> goodness; specifically, you do not get it by default on x86, not
> at any optimisation level.
OK, so what's the status with this patch series?
I don't want to pull it in unless I have an ack from Sam, and now
there's issues with having -fno-omit-frame-pointer. Should we add a
patch instead that simply removes that?
If we eliminate the -fno-omit-frame-pointer, would that solve the PPC
problem? And would it cause any other issues with other archs?
-- Steve
^ permalink raw reply
* Re: MSR_SPE - being turned off...
From: Michael Neuling @ 2009-05-06 0:01 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90110C30D34@EMPBEDEX.empirix.com>
> Hi Kumar/Michael...
>
> Sorry, I really didn't explain myself very well...
>
> The Problem (answer to Michael):
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D
> We started using a new compiler that upon -O2 optimization - added
> heavy SPE related instructions into our applications (where the older
> compiler might not use as many). Once this was done, we started=20
> experiencing problems with data being 'shifted' and/or corrupted=20
> throughout the applications which didn't immediately cause problems,
> but either scribbled on someone else's memory and/or bad results...
> We knew where one of the offending scribbles started (by the shifting=20
> by 1 byte of a structure) and found by comparing binaries with 'older'
> compiler vs. this one that the only major difference was the 'density'=20
> of the SPE instructions...
>
> As to your question, Kumar:=20
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D
> Naively, I explicitly enabled the SPE in a BSP 'early_init' program=20
> (as well as enabling Machine Checks) - which is what I meant by
> Enabling SPE...
Yeah, you don't want to do this. It'll potentially break your
application.
I'm not that familiar with the CPU you are using but I'm guessing that
you can't write the MSR from user space anyway.
> Michael explained that it is 'normal' if we asynchronously polled
> the MSR (in an application and/or in the kernel) that it might be
> disabled at the moment, but that you do a 'lazy switch' that=20
> enables it...and gets turned on when an SPE exception comes in...
>
> ...ok...I can live with that...
>
> -------where I was really going---------
>
> This is where I was trying to go. A developer at our company (who no
> longer works for us) - did some research/development on the SPE=20
> functionality, in the hopes that we could create an optimized library.
> The results were successful, but because of some of the restrictions=20
> (including 8 byte alignment for some instructions) - we decided not
> to incorporate this library into our application(s)
>
> But, this developer in his results, indicated that he believed our
> kernels were NOT properly saving/restoring the upper 32bits of the
> GPR (which can/will be used in the SPE instructions)... Thus, if the
> upper 32bits were not saved (and restored when the application got
> the SPE to operate on)...then, he thought there would be problems.
> He unfortunately, was unable to finish his work and fix these 'bugs'
> before he left our company...
>
> Again, I am only going on his results, and not my own investigations
> (I am not sure where to start to find this problem to begin with)...
>
> So, I was REALLY asking - has anybody else run into this type of
> problem, and/or the Linux community has recognized this problem and
> has fixed this?
If GPRs where getting corrupted in userspace, that would be a serious
bug and would be noticed by someone pretty quickly.
We'd really need a test case to get anywhere with this report.
Mikey
^ permalink raw reply
* RE: MSR_SPE - being turned off...
From: Morrison, Tom @ 2009-05-06 0:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <756DA1CE-4951-4087-9F1B-FE83A53BB253@kernel.crashing.org>
Ok...taken out...
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Tuesday, May 05, 2009 5:18 PM
>> To: Morrison, Tom
>> Cc: linuxppc-dev@ozlabs.org; Michael Neuling
>> Subject: Re: MSR_SPE - being turned off...
>>=20
>>=20
>> On May 5, 2009, at 7:56 AM, Morrison, Tom wrote:
>>=20
>> > Hi Kumar/Michael...
>> >
>> > Sorry, I really didn't explain myself very well...
>> >
>> > The Problem (answer to Michael):
>> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
>> > We started using a new compiler that upon -O2 optimization - added
>> > heavy SPE related instructions into our applications (where the
older
>> > compiler might not use as many). Once this was done, we started
>> > experiencing problems with data being 'shifted' and/or corrupted
>> > throughout the applications which didn't immediately cause
problems,
>> > but either scribbled on someone else's memory and/or bad results...
>> > We knew where one of the offending scribbles started (by the
shifting
>> > by 1 byte of a structure) and found by comparing binaries with
'older'
>> > compiler vs. this one that the only major difference was the
'density'
>> > of the SPE instructions...
>> >
>> > As to your question, Kumar:
>> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
>> > Naively, I explicitly enabled the SPE in a BSP 'early_init' program
>> > (as well as enabling Machine Checks) - which is what I meant by
>> > Enabling SPE...
>>=20
>> Are you setting MSR_SPE in your own board code? If so stop doing so.
>> There isn't any need or reason to be doing that. MSR_SPE will get
set
>> when an application starts using SPE code and the kernel will manage
>> it properly.
>>=20
>> - k
>>=20
^ permalink raw reply
* RE: MSR_SPE - being turned off...
From: Morrison, Tom @ 2009-05-06 0:42 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev
In-Reply-To: <13221.1241568099@neuling.org>
The test case we found is under 'extreme' duress=20
(intense loading on an MPC8572)...with many applications....
using A LOT of SPE instructions...
----
If you look at the context switch code (in latest code entry_32.S),=20
I believe the context switch performs a SAVE_NVGPR() - which in our=20
interpretation (in ppc_asm.h) - only saves the lower 32 bits of=20
the GPR (stw/lwz)...
This is only a guess of where the problem lies - based upon the single
SPE instruction that seemingly got misinterpreted, and shifts the data
By '1 byte' (and this code gets executed successfully MANY more times=20
at lower bandwidths - than failures seen at higher bandwidths)...
----
I am not sure how to proceed...we know how to recreate with our=20
application, but we would love to know how to change (safely)=20
the pt_regs to "long long" for the GPRs and then safely move
all 64bits of each GPR into these doubles...
We could then re-test and see if this helps?
Tom
>> -----Original Message-----
>> From: Michael Neuling [mailto:mikey@neuling.org]
>> Sent: Tuesday, May 05, 2009 8:02 PM
>> To: Morrison, Tom
>> Cc: Kumar Gala; linuxppc-dev@ozlabs.org
>> Subject: Re: MSR_SPE - being turned off...
>>=20
>> > Hi Kumar/Michael...
>> >
>> > Sorry, I really didn't explain myself very well...
>> >
>> > The Problem (answer to Michael):
>> >
>>
=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D=
3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D
=3D
>> 3D=3D
>> > =3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D
>> > We started using a new compiler that upon -O2 optimization - added
>> > heavy SPE related instructions into our applications (where the
older
>> > compiler might not use as many). Once this was done, we =
started=3D20
>> > experiencing problems with data being 'shifted' and/or =
corrupted=3D20
>> > throughout the applications which didn't immediately cause
problems,
>> > but either scribbled on someone else's memory and/or bad results...
>> > We knew where one of the offending scribbles started (by the
>> shifting=3D20
>> > by 1 byte of a structure) and found by comparing binaries with
'older'
>> > compiler vs. this one that the only major difference was the
>> 'density'=3D20
>> > of the SPE instructions...
>> >
>> > As to your question, Kumar:=3D20
>> >
>>
=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D=
3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D=3D3D
=3D
>> 3D=3D
>> > =3D3D=3D3D
>> > Naively, I explicitly enabled the SPE in a BSP 'early_init'
program=3D20
>> > (as well as enabling Machine Checks) - which is what I meant by
>> > Enabling SPE...
>>=20
>> Yeah, you don't want to do this. It'll potentially break your
>> application.
>>=20
>> I'm not that familiar with the CPU you are using but I'm guessing
that
>> you can't write the MSR from user space anyway.
>>=20
>> > Michael explained that it is 'normal' if we asynchronously polled
>> > the MSR (in an application and/or in the kernel) that it might be
>> > disabled at the moment, but that you do a 'lazy switch' that=3D20
>> > enables it...and gets turned on when an SPE exception comes in...
>> >
>> > ...ok...I can live with that...
>> >
>> > -------where I was really going---------
>> >
>> > This is where I was trying to go. A developer at our company (who
no
>> > longer works for us) - did some research/development on the =
SPE=3D20
>> > functionality, in the hopes that we could create an optimized
library.
>> > The results were successful, but because of some of the
restrictions=3D20
>> > (including 8 byte alignment for some instructions) - we decided not
>> > to incorporate this library into our application(s)
>> >
>> > But, this developer in his results, indicated that he believed our
>> > kernels were NOT properly saving/restoring the upper 32bits of the
>> > GPR (which can/will be used in the SPE instructions)... Thus, if
the
>> > upper 32bits were not saved (and restored when the application got
>> > the SPE to operate on)...then, he thought there would be problems.
>> > He unfortunately, was unable to finish his work and fix these
'bugs'
>> > before he left our company...
>> >
>> > Again, I am only going on his results, and not my own
investigations
>> > (I am not sure where to start to find this problem to begin
with)...
>> >
>> > So, I was REALLY asking - has anybody else run into this type of
>> > problem, and/or the Linux community has recognized this problem and
>> > has fixed this?
>>=20
>> If GPRs where getting corrupted in userspace, that would be a serious
>> bug and would be noticed by someone pretty quickly.
>>=20
>> We'd really need a test case to get anywhere with this report.
>>=20
>> Mikey
^ permalink raw reply
* Re: [PATCH v7] introduce macro spin_event_timeout()
From: Sean MacLennan @ 2009-05-06 0:43 UTC (permalink / raw)
To: Timur Tabi; +Cc: scottwood, linuxppc-dev
In-Reply-To: <1241560385-26868-1-git-send-email-timur@freescale.com>
On Tue, 5 May 2009 16:53:05 -0500
"Timur Tabi" <timur@freescale.com> wrote:
> The macro spin_event_timeout() takes a condition and timeout value
> (in microseconds) as parameters. It spins until either the condition
> is true or the timeout expires. It returns the result of the
> condition when the loop was terminated.
>
> This primary purpose of this macro is to poll on a hardware register
> until a status bit changes. The timeout ensures that the loop still
> terminates if the bit doesn't change as expected. This macro makes
> it easier for driver developers to perform this kind of operation
> properly.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
Nice. I could have used a routine like this in a couple of our drivers.
So, for what it is worth:
Acked-by: Sean MacLennan <smaclennan@pikatech.com>
Cheers,
Sean
^ permalink raw reply
* Re: MSR_SPE - being turned off...
From: Kumar Gala @ 2009-05-06 4:23 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90110C94528@EMPBEDEX.empirix.com>
On May 5, 2009, at 7:42 PM, Morrison, Tom wrote:
> The test case we found is under 'extreme' duress
> (intense loading on an MPC8572)...with many applications....
> using A LOT of SPE instructions...
>
> ----
>
> If you look at the context switch code (in latest code entry_32.S),
> I believe the context switch performs a SAVE_NVGPR() - which in our
> interpretation (in ppc_asm.h) - only saves the lower 32 bits of
> the GPR (stw/lwz)...
>
> This is only a guess of where the problem lies - based upon the single
> SPE instruction that seemingly got misinterpreted, and shifts the data
> By '1 byte' (and this code gets executed successfully MANY more times
> at lower bandwidths - than failures seen at higher bandwidths)...
>
> ----
>
> I am not sure how to proceed...we know how to recreate with our
> application, but we would love to know how to change (safely)
> the pt_regs to "long long" for the GPRs and then safely move
> all 64bits of each GPR into these doubles...
>
> We could then re-test and see if this helps?
>
> Tom
If you use SPE in an application the full 64-bits are saved and
restored it just split into two locations (one for the lower 32-bits
and one for the upper 32-bits).
Look at load_up_spe and giveup_spe in arch/powerpc/kernel/
head_fsl_booke.S
On the 8572 are you running w/SMP? What kernel version are you using
if so? Do you see the same issue on the MPC8548?
- k
^ permalink raw reply
* RE: MSR_SPE - being turned off...
From: Morrison, Tom @ 2009-05-06 8:31 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <B5440F25-74DB-46BB-9374-837441826097@kernel.crashing.org>
Kumar,
=20
What about the case of a context switch (i.e.: when things are setup
in registers for the SPE, but then a context switch happens before
the SPE is executed)?=20
=20
As to load_up_spe & give_up_spe, it was pointed out to me tonight by a =
co-worker
to look at how things are saved in those routines, I definitely will =
look at this again,=20
and see how it is done...
=20
This is happening for us on an 8572 SMP. We are trying to get it to =
happen=20
on 8548 (and single core 8572), but we haven't been able to push this =
part=20
of the application as hard as it is being pushed on 8572...but we will =
keep trying....
=20
thank you for your patience and suggestions on this...and I will keep =
working it
=20
Tom=20
________________________________
From: Kumar Gala [mailto:galak@kernel.crashing.org]
Sent: Wed 5/6/2009 12:23 AM
To: Morrison, Tom
Cc: Michael Neuling; linuxppc-dev@ozlabs.org
Subject: Re: MSR_SPE - being turned off...=20
On May 5, 2009, at 7:42 PM, Morrison, Tom wrote:
> The test case we found is under 'extreme' duress
> (intense loading on an MPC8572)...with many applications....
> using A LOT of SPE instructions...
>
> ----
>
> If you look at the context switch code (in latest code entry_32.S),
> I believe the context switch performs a SAVE_NVGPR() - which in our
> interpretation (in ppc_asm.h) - only saves the lower 32 bits of
> the GPR (stw/lwz)...
>
> This is only a guess of where the problem lies - based upon the single
> SPE instruction that seemingly got misinterpreted, and shifts the data
> By '1 byte' (and this code gets executed successfully MANY more times
> at lower bandwidths - than failures seen at higher bandwidths)...
>
> ----
>
> I am not sure how to proceed...we know how to recreate with our
> application, but we would love to know how to change (safely)
> the pt_regs to "long long" for the GPRs and then safely move
> all 64bits of each GPR into these doubles...
>
> We could then re-test and see if this helps?
>
> Tom
If you use SPE in an application the full 64-bits are saved and=20
restored it just split into two locations (one for the lower 32-bits=20
and one for the upper 32-bits).
Look at load_up_spe and giveup_spe in arch/powerpc/kernel/
head_fsl_booke.S
On the 8572 are you running w/SMP? What kernel version are you using=20
if so? Do you see the same issue on the MPC8548?
- k
^ permalink raw reply
* [PATCH] mmc: Fix the wrong accessor to HOSTVER register
From: Dave Liu @ 2009-05-06 10:40 UTC (permalink / raw)
To: drzeus-sdhci; +Cc: linuxppc-dev, sdhci-devel, ben-linux
Freescale eSDHC controller has the special order for
the HOST version register. that is not same as the other's
registers. The address of HOSTVER in spec is 0xFE, and
we need use the in_be16(0xFE) to access it, not in_be16(0xFC).
Signed-off-by: Dave Liu <daveliu@freescale.com>
---
drivers/mmc/host/sdhci-of.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of.c b/drivers/mmc/host/sdhci-of.c
index 3ff4ac3..e167131 100644
--- a/drivers/mmc/host/sdhci-of.c
+++ b/drivers/mmc/host/sdhci-of.c
@@ -55,7 +55,13 @@ static u32 esdhc_readl(struct sdhci_host *host, int reg)
static u16 esdhc_readw(struct sdhci_host *host, int reg)
{
- return in_be16(host->ioaddr + (reg ^ 0x2));
+ u16 ret;
+
+ if (unlikely(reg == SDHCI_HOST_VERSION))
+ ret = in_be16(host->ioaddr + reg);
+ else
+ ret = in_be16(host->ioaddr + (reg ^ 0x2));
+ return ret;
}
static u8 esdhc_readb(struct sdhci_host *host, int reg)
--
1.5.4
^ permalink raw reply related
* Re: MSR_SPE - being turned off...
From: Kumar Gala @ 2009-05-06 12:31 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D9010EEBF67D@EMPBEDEX.empirix.com>
On May 6, 2009, at 3:31 AM, Morrison, Tom wrote:
> Kumar,
>
> What about the case of a context switch (i.e.: when things are setup
> in registers for the SPE, but then a context switch happens before
> the SPE is executed)?
context switches will be fine. What we normally do is keep track of
which user app used SPE last and when some other app needs it we clear
MSR_SPE for the old app, save its registers. Than we load up the
registers for the new app and set MSR_SPE. When the old app context
switches in it will get an SPE unavail exception at the point it
executes its next SPE insn and we will repeat the process.
> As to load_up_spe & give_up_spe, it was pointed out to me tonight by
> a co-worker
> to look at how things are saved in those routines, I definitely will
> look at this again,
> and see how it is done...
>
> This is happening for us on an 8572 SMP. We are trying to get it to
> happen
> on 8548 (and single core 8572), but we haven't been able to push
> this part
> of the application as hard as it is being pushed on 8572...but we
> will keep trying....
Again, what kernel version for 8572? Its possible old SMP kernels are
broken on 8572.
- k
> ________________________________
>
> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> Sent: Wed 5/6/2009 12:23 AM
> To: Morrison, Tom
> Cc: Michael Neuling; linuxppc-dev@ozlabs.org
> Subject: Re: MSR_SPE - being turned off...
>
>
>
>
> On May 5, 2009, at 7:42 PM, Morrison, Tom wrote:
>
>> The test case we found is under 'extreme' duress
>> (intense loading on an MPC8572)...with many applications....
>> using A LOT of SPE instructions...
>>
>> ----
>>
>> If you look at the context switch code (in latest code entry_32.S),
>> I believe the context switch performs a SAVE_NVGPR() - which in our
>> interpretation (in ppc_asm.h) - only saves the lower 32 bits of
>> the GPR (stw/lwz)...
>>
>> This is only a guess of where the problem lies - based upon the
>> single
>> SPE instruction that seemingly got misinterpreted, and shifts the
>> data
>> By '1 byte' (and this code gets executed successfully MANY more times
>> at lower bandwidths - than failures seen at higher bandwidths)...
>>
>> ----
>>
>> I am not sure how to proceed...we know how to recreate with our
>> application, but we would love to know how to change (safely)
>> the pt_regs to "long long" for the GPRs and then safely move
>> all 64bits of each GPR into these doubles...
>>
>> We could then re-test and see if this helps?
>>
>> Tom
>
> If you use SPE in an application the full 64-bits are saved and
> restored it just split into two locations (one for the lower 32-bits
> and one for the upper 32-bits).
>
> Look at load_up_spe and giveup_spe in arch/powerpc/kernel/
> head_fsl_booke.S
>
> On the 8572 are you running w/SMP? What kernel version are you using
> if so? Do you see the same issue on the MPC8548?
>
> - k
>
^ permalink raw reply
* RE: MSR_SPE - being turned off...
From: Morrison, Tom @ 2009-05-06 12:42 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Michael Neuling
In-Reply-To: <343F1A10-459E-4024-B0DD-ADB1D6DCDB9D@kernel.crashing.org>
I'm sorry I forgot to put that, this issue was found with our=20
currently running kernel 2.6.23.final (what comes with the=20
Freescale LTIB BSP package dated 05/23/2009).=20
I am sorry if I don't understand your statement that the SMP might
be broken on this kernel, because I tried to analyze the kernel that=20
came with the latest BSP LTIB [ackage from Freescale (dated 12/18/2009=20
(where we got the 4.2.171 compiler from)), and the associated 'switch=20
context' code is exactly the same. Unfortunately, I have not started=20
the process of porting my current platform's BSP to this new kernel -=20
otherwise, I would have done the test on that platform (this also=20
requires a new version of u-boot in order to test correctly))..
I may have mis-interpreted something and/or I am sure I don't=20
understand everything about the SMP resource management (and=20
associated SPE management), so thank you for any insight you=20
may have on this front...
Tom
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Wednesday, May 06, 2009 8:32 AM
>> To: Morrison, Tom
>> Cc: Michael Neuling; linuxppc-dev@ozlabs.org
>> Subject: Re: MSR_SPE - being turned off...
>>=20
>>=20
>> On May 6, 2009, at 3:31 AM, Morrison, Tom wrote:
>>=20
>> > Kumar,
>> >
>> > What about the case of a context switch (i.e.: when things are
setup
>> > in registers for the SPE, but then a context switch happens before
>> > the SPE is executed)?
>>=20
>> context switches will be fine. What we normally do is keep track of
>> which user app used SPE last and when some other app needs it we
clear
>> MSR_SPE for the old app, save its registers. Than we load up the
>> registers for the new app and set MSR_SPE. When the old app context
>> switches in it will get an SPE unavail exception at the point it
>> executes its next SPE insn and we will repeat the process.
>>=20
>> > As to load_up_spe & give_up_spe, it was pointed out to me tonight
by
>> > a co-worker
>> > to look at how things are saved in those routines, I definitely
will
>> > look at this again,
c>> > and see how it is done...
>> >
>> > This is happening for us on an 8572 SMP. We are trying to get it to
>> > happen
>> > on 8548 (and single core 8572), but we haven't been able to push
>> > this part
>> > of the application as hard as it is being pushed on 8572...but we
>> > will keep trying....
>>=20
>> Again, what kernel version for 8572? Its possible old SMP kernels
are
>> broken on 8572.
>>=20
>> - k
>>=20
>> > ________________________________
>> >
<snip previous emails>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox