From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bilbo.ozlabs.org (bilbo.ozlabs.org [203.10.76.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "bilbo.ozlabs.org", Issuer "CAcert Class 3 Root" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 9A817DDDA5 for ; Tue, 5 May 2009 14:17:43 +1000 (EST) From: Michael Neuling To: "Morrison, Tom" Subject: Re: MSR_SPE - being turned off... In-reply-to: References: Date: Tue, 05 May 2009 14:17:42 +1000 Message-ID: <23583.1241497062@neuling.org> Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , > I have both a MPC8548 SBC and MPC8572 system that are running different > flavors of the same Linux - 2.6.23. > > I explicitly am turning it on very early on. Where are you turning this on? In the appication? > Later, I have an application that is compiled with SPE instructions > (e.g.: evstdd) , and there is where the problems happen. What is the problem? > If I explicitly make sure there are NO SPE instructions in the > application, nothing bad happens! > > I am polling the MSR - and it seems the SPE is turned OFF? You are polling MSR in your application? Anyway, this is expected. We do lazy restore of these registers after a context switch. So the SPE bit in the MSR may not be set if no SPE instructions have run since the last context switch. > What have I done wrong and/or has there been fixes in later kernels that > I should be aware of that might help this issue? I'm not clear what the problem is. You've just said "problems happen" when you include SPE instructions. Are you getting a SIGILL or some other signal? Is your program terminating. Can you get a GDB back-trace or dump of which instruction is causing the "problem". Mikey