calling giveup_altivec on machine with no altivec!?

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..


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


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

Troy Benjegerdes wrote:

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."

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

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

Why did emulate_instruction() get added into traps.c to emulate the
mfspr PVR instruction?  What user space application is using this
instruction?

And why add this extra cruft?  The information is already available to
user applications (one example, /proc/cpuinfo reports the cpu and revision).


Thanks,

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

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

Frank Rowand wrote:

And why add this extra cruft?

Perhaps you should ask the people that requested it, probably one
or two doors down from your office..........

It was added so programs (actually libraries) executing prior to
any of the /proc stuff set up (like init) could detect the processor
type and install (or avoid) a variety of instructions unique to
that processor.  Cache line information, availability of floating point,
Altivec, unique silicon errata workarounds, etc. could be incorporated
into the library, reducing the requirement to have uniquely compiled
libraries for all of the processor variants.  This has been discussed
for ages on a variety of mailing lists, and emulating the 'mfspr PVR',
which is hardly cruft compared to some of the other stuff that exists,
was the easiest and least intrusive method.



	-- Dan

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

Troy Benjegerdes wrote:

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

Crap....

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

Ahhhh, wait a minute......does SMP do the lazy Altivec or does it
always switch it?  On uP systems, MSR_VEC isn't set unless you get an
Altivec trap, but I seem to remember comments about always switching it
on SMP systems.  On an SMP system, if you don't really have Altivec
you probably shouldn't enable it in the configuration.....no common
config here :-).


	-- Dan

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

Frank Rowand wrote:

Why did emulate_instruction() get added into traps.c to emulate the
mfspr PVR instruction?  What user space application is using this
instruction?

And why add this extra cruft?  The information is already available to
user applications (one example, /proc/cpuinfo reports the cpu and revision).

Thanks,

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

The pvr was added so that applications that tune themselves can look at
the pvr information and figure out the processor type.

You can not count on /proc/cpuinfo to exist, or be in the same format
from one kernel version to the next.  The PVR instruction can be counted
on.  (And if someone has a need to emulate a different PVR.)

The idea behind this (originally) was to have glibc tune itself to the
cache-line size, FP ability, and Altivec ability of a CPU, but reading
/proc/cpuinfo wouldn't be acceptible since it may not be mounted, and
the whole open/read/close would have to happen early in glibc's load.
(Not practical)

There was discussion about this and almost everyone agreed it didn't
hurt to have the PVR available in user space as a trapped instruction.

--Mark

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