From: "H. Peter Anvin" <hpa@zytor.com>
To: linux-kernel@vger.kernel.org
Subject: Re: missing mxcsr initialization
Date: 27 Oct 2000 00:34:47 -0700 [thread overview]
Message-ID: <8tbb6n$85r$1@cesium.transmeta.com> (raw)
In-Reply-To: <20001026021731.B23895@athlon.random> <E13oy7T-00043v-00@the-village.bc.nu>
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/
next prev parent reply other threads:[~2000-10-27 7:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20001026021731.B23895@athlon.random>
2000-10-27 1:15 ` missing mxcsr initialization Alan Cox
2000-10-27 7:34 ` H. Peter Anvin [this message]
[not found] <Pine.LNX.4.10.10010260835340.2335-100000@penguin.transmeta.com>
2000-10-27 0:39 ` Alan Cox
2000-10-27 5:35 ` Linus Torvalds
2000-10-27 11:42 ` Alan Cox
2000-10-27 19:07 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='8tbb6n$85r$1@cesium.transmeta.com' \
--to=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.