missing mxcsr initialization
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines
Quoted 2 lines
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Comment-To: Alan Cox <[email protected]>
Disclaimer: Not speaking for Transmeta in any way, shape, or form.
Copyright: Copyright 2000 H. Peter Anvin - All Rights Reserved
Followup to: <[email protected]> By author: Alan Cox <[email protected]> In newsgroup: linux.dev.kernel
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
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.
Quoted 8 lines
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.
Quoted 4 lines
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
Signature · 7 lines
<[email protected]> at work, <[email protected]> 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 [email protected] Please read the FAQ at http://www.tux.org/lkml/