Re: calling giveup_altivec on machine with no altivec!?

On Thu, Feb 15, 2001 at 02:20:03PM -0800, Frank Rowand wrote:

Troy Benjegerdes wrote:

quoted

My Motorola MTX just crashed after the following code in _swithc_to
executed:

        if ((prev->thread.regs && (prev->thread.regs->msr & MSR_VEC)))
                giveup_altivec(prev);

Somehow prev->thread.regs->msr & MSR_VEC turned out true. I'm suspecting
something got overwritten somewhere..

This is an SMP machine so I'm wondering if there wasn't a race condition
on something with task structs..

Is it possible that the MSR had the MSR_VEC bit set at some point?  One
IBM processor user's manual says "the reserved fields should be written
as 0 and read as __undefined__.  This is, when writing to a register with
a reserved field, write a 0 to the reserved field.  When reading from a
register with a reserved field, ignore that bit."

Possible, but I doubt it, since I believe the _switch_to code has been
like that for quite awhile. (I was running on a 604ev.. anyone know ofhand
if that bit is defined for something on the 604ev?)

In either case, if that's what the IBM manuals say, then the code is
incorrect and should probably be re-done to check that it's actually
running on a kernel with an altivec unit. Any suggestions on the best way
to fix it?

--------------------------------------------------------------------------
Troy Benjegerdes                'da hozer'                hozer@drgw.net


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Troy Benjegerdes wrote:

quoted

Is it possible that the MSR had the MSR_VEC bit set at some point?  One
IBM processor user's manual says "the reserved fields should be written
as 0 and read as __undefined__.  This is, when writing to a register with
a reserved field, write a 0 to the reserved field.  When reading from a
register with a reserved field, ignore that bit."

In either case, if that's what the IBM manuals say, then the code is
incorrect and should probably be re-done to check that it's actually
running on a kernel with an altivec unit. Any suggestions on the best way
to fix it?

Assuming a CONFIG_ALTIVEC flag (or equivalent) existed, then in processor.h:

#ifdef CONFIG_ALTIVEC
#define MSR_VEC         (1<<25)
#else
#define MSR_VEC         (0)
#endif

-Frank
--
Frank Rowand [off-list ref]
MontaVista Software, Inc

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/