MSR_SPE - being turned off...

[Kumar Gala]

Since you are mentioning alignment it looks my patch for SPE alignment  
went in after 2.6.23:

commit 26caeb2ee1924d564e8d8190aa783a569532f81a
Author: Kumar Gala <galak at 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:galak at kernel.crashing.org]
>>>>> Sent: Wednesday, May 06, 2009 8:44 AM
>>>>> To: Morrison, Tom
>>>>> Cc: Michael Neuling; linuxppc-dev at 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>