Re: missing mxcsr initialization

Re: missing mxcsr initialization

[Alan Cox]

> > corrected for include the facts that the XMM feature bit is an Intel specific
> > bit that other vendors may use for other things, so you need to test vendor ==
> 			 ^^^
> Note that they shouldn't do that! I would consider a very bad thing if they
> goes out of sync on those bits.

CPUID is vendor specific. Every bit in those fields is vendor specific. Every
piece of documentation tells you to check the CPU vendor.  Every time we didnt 
bother we got burned.

I keep hearing people saying things like 'bad thing' 'assume standards'. Well
all I can say is cite a vendor issued document which says 'dont bother checking
the vendor'. 

And when you can't find that document, put the checks in so we dont crash on
an Athlon or when using MTRR on a Cyrix III etc

Alan



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: missing mxcsr initialization

[H. Peter Anvin]

MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Comment-To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Disclaimer: Not speaking for Transmeta in any way, shape, or form.
Copyright: Copyright 2000 H. Peter Anvin - All Rights Reserved

Followup to:  <E13oy7T-00043v-00@the-village.bc.nu>
By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
>
> > > corrected for include the facts that the XMM feature bit is an Intel specific
> > > bit that other vendors may use for other things, so you need to test vendor ==
> > 			 ^^^
> > Note that they shouldn't do that! I would consider a very bad thing if they
> > goes out of sync on those bits.
> 
> CPUID is vendor specific. Every bit in those fields is vendor specific. Every
> piece of documentation tells you to check the CPU vendor.  Every time we didnt 
> bother we got burned.
> 
> I keep hearing people saying things like 'bad thing' 'assume standards'. Well
> all I can say is cite a vendor issued document which says 'dont bother checking
> the vendor'. 
> 

Intel does it because they want every other chip out there to act like
a 486.

> 
> And when you can't find that document, put the checks in so we dont crash on
> an Athlon or when using MTRR on a Cyrix III etc
> 

Chips that don't implement what they claim to implement are buggy and
should be treated as such.  SPECIAL-CASE THE BUGGY CHIPS, NOT THE
PROPERLY FUNCTIONING ONES.

	-hpa


-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: missing mxcsr initialization

[Alan Cox]

> Let's face it. People who don't follow the intel ordering of bits are
> _buggy_. And yes, there are tons of buggy chips out there (mainly from

Its tricky to do so, some of them were not even documented. And one of them
(SEP) changed in the undocumented phase from one version of SYSCALL to 
another (now documented one)

> bitmap is all about, and should be forced to go back to the bad old times
> when you had to check the stepping levels etc to figure out what the CPU's
> could do.

You still do. In fact your example SEP specifically requires this due to 
Intel specification changes in the undocumented=->documented versions

Alan

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: missing mxcsr initialization

[Linus Torvalds]

On Fri, 27 Oct 2000, Alan Cox wrote:
> > bitmap is all about, and should be forced to go back to the bad old times
> > when you had to check the stepping levels etc to figure out what the CPU's
> > could do.
> 
> You still do. In fact your example SEP specifically requires this due to 
> Intel specification changes in the undocumented=->documented versions

NO.

Go back. Read ym email. Realize that you do this ONCE. At setup time.

You can even split SEP into SEPOLD and SEPNEW, and _always_ just test one
bit. You should not have to test stepping levels in normal use: that
invariably causes problems when there are more than one CPU that has some
feature.

It is insidious. It starts out as something simple like

	if (stepping < 5) {
		...
	}

and everybody thinks it is cool. Until somebody notices that it should be

	if (vendor == intel && stepping < 5) {
		...
	}

and it appears to work again, until it turns out that Cyrix has the same
issue, and then it ends up being the test from hell, where different
vendor tests all clash, and it gets increasingly difficult to add a new
thing later on sanely. 

In contrast, having the test be

	if (feature & SEPNEW) {
		...
	}

your test is simplified, easier to read and understand, AND it is much
easier to account for different vendors who have different stepping levels
etc. Especially as some vendors need setup code for the thing to work at
all, so it's not even stepping levels, it's stepping levels PLUS some
certain magic sequence that must have been done to initialize the thing.

No thank you. We'll just require fixed feature flags. Which can be turned
on as the features are enabled.

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: missing mxcsr initialization

[Alan Cox]

> Go back. Read ym email. Realize that you do this ONCE. At setup time.

(I've got about 2000 to read after this jaunt so I may have missed some)

> You can even split SEP into SEPOLD and SEPNEW, and _always_ just test one
> bit. You should not have to test stepping levels in normal use: that
> invariably causes problems when there are more than one CPU that has some
> feature.

Agree

> 	if (vendor == intel && stepping < 5) {
> 		...
> 	}
> 
> and it appears to work again, until it turns out that Cyrix has the same
> issue, and then it ends up being the test from hell, where different
> vendor tests all clash, and it gets increasingly difficult to add a new
> thing later on sanely. 

And you end up with mtrr.c

> No thank you. We'll just require fixed feature flags. Which can be turned
> on as the features are enabled.

That seems sensible

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: missing mxcsr initialization

[H. Peter Anvin]

Followup to:  <E13p7te-0004MB-00@the-village.bc.nu>
By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
In newsgroup: linux.dev.kernel
> > 
> > and it appears to work again, until it turns out that Cyrix has the same
> > issue, and then it ends up being the test from hell, where different
> > vendor tests all clash, and it gets increasingly difficult to add a new
> > thing later on sanely. 
> 
> And you end up with mtrr.c
> 

Indeed.

> 
> > No thank you. We'll just require fixed feature flags. Which can be turned
> > on as the features are enabled.
> 
> That seems sensible
> 

I'm working on the patch right now.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/