Since you are mentioning alignment it looks my patch for SPE alignment
went in after 2.6.23:
commit 26caeb2ee1924d564e8d8190aa783a569532f81a
Author: Kumar Gala <ga...@kernel.crashing.org>
Date: Fri Aug 24 16:42:53 2007 -0500
[POWERPC] Handle alignment faults on SPE load/store instructions
This adds code to handle alignment traps generated by the following
SPE (signal processing engine) load/store instructions, by
emulating
the instruction in the kernel (as is done for other instructions
that
generate alignment traps):
You may want to try and see if you can apply that patch to your kernel
tree and see what happens.
- k
On May 6, 2009, at 3:15 PM, Morrison, Tom wrote:
Sorry, let me try again...
-----Original Message-----
After sitting with the developer of the application for a while,
a) Alignment (aka: alignment exceptions) - Looking at how it
handles the instruction - it interprets these SPE as common
instructions & then resets the 'upper' 32bits.
I was just made aware that on 9/14/2007 - Kumar submitted a
patch that handles these instructions correctly (we don't
have that version - I am in the process of trying to port it
to my current version of the kernel (to see if part of
problem).
In general, this is a VERY disturbing thing. We 'turn on
SPE' in the compiler (-mspe=yes)(a). We are NOT explicitly
using SPE instructions in our application(b), BUT(c), the
4.2.171
compiler (having origins from Code Sourcery (via Freescale))
upon
optimizations put SPE instructions in without any regard for
alignment (which instead of making the code faster - might
actually
make the code slower)? It's a little disturbing to me.
Stay tuned for more details about my port - and seeing if some
of my problems go away..
b) We still contend if you have multiple tasks using a (VERY) high
Density of SPE instructions - and the system is taxed heavily
(with lots of context switches) - there is the possibility that
a task will get unlucky and the registers setup will NOT there
after the context switches back (if some other task does something
else with the entire 64bits).
Tom
-----Original Message-----
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Wednesday, May 06, 2009 8:44 AM
To: Morrison, Tom
Cc: Michael Neuling; linuxppc-dev@ozlabs.org
Subject: Re: MSR_SPE - being turned off...
Can you describe the # of processes you are running in your test.
Is
it possible for you to try the tests w/2.6.29 from kernel.org?
- k
On May 6, 2009, at 7:42 AM, Morrison, Tom wrote:
I'm sorry I forgot to put that, this issue was found with our
currently running kernel 2.6.23.final (what comes with the
Freescale LTIB BSP package dated 05/23/2009).
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
came with the latest BSP LTIB [ackage from Freescale (dated
12/18/2009
(where we got the 4.2.171 compiler from)), and the associated
'switch
context' code is exactly the same. Unfortunately, I have not
started
the process of porting my current platform's BSP to this new
kernel
-
otherwise, I would have done the test on that platform (this
also
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
understand everything about the SMP resource management (and
associated SPE management), so thank you for any insight you
may have on this front...
Tom
-----Original Message-----
<snip other emails>
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
