calling giveup_altivec on machine with no altivec!?

calling giveup_altivec on machine with no altivec!?

[Troy Benjegerdes]

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/

Re: calling giveup_altivec on machine with no altivec!?

[Frank Rowand]

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 <frank_rowand@mvista.com>
MontaVista Software, Inc

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

Re: calling giveup_altivec on machine with no altivec!?

[Troy Benjegerdes]

On Thu, Feb 15, 2001 at 02:20:03PM -0800, Frank Rowand wrote:
> 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."

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/

Re: calling giveup_altivec on machine with no altivec!?

[Frank Rowand]

Troy Benjegerdes wrote:


> > 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 <frank_rowand@mvista.com>
MontaVista Software, Inc

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

program exception emulates mfspr PVR

[Frank Rowand]

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 <frank_rowand@mvista.com>
MontaVista Software, Inc

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

Re: program exception emulates mfspr PVR

[Dan Malek]

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/

Re: program exception emulates mfspr PVR

[Mark Hatle]

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 <frank_rowand@mvista.com>
> 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/

Re: calling giveup_altivec on machine with no altivec!?

[Dan Malek]

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/

Re: calling giveup_altivec on machine with no altivec!?

[Troy Benjegerdes]

On Thu, Feb 15, 2001 at 05:57:18PM -0500, Dan Malek wrote:
> 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 :-).

Well, in theory yes, but the fact that MSR_VEC mysteriously got set
implies some other problem somewhere... I also think Common config's are
just too usefull, since more code paths get tested on more machines..
there's something that set MSR_VEC that shouldn't have, and I'd never have
seen it if I didn't have a common config.

SMP does 'somewhat' lazy altivec.. if the process used altivec, it
always switches. UP I think switches only when a second process actually
tries to use altivec, and another process already has data in registers.


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

Somone asked my why I work on this free (http://www.fsf.org/philosophy/)
software stuff and not get a real job. Charles Shulz had the best answer:

"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's why
I draw cartoons. It's my life." -- Charles Shulz

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