Followup to: <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
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
> 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
> in
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 PROTECT
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 s
> > 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 thos
> 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
anot
On Thu, 26 Oct 2000, Andrea Arcangeli wrote:
> On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote:
> > I've made a few correctness changes to this code. Items that needed to be
> > corrected for include the facts that the XMM feature bit is an Intel specific
> > bit that other vendor
On Thu, Oct 26, 2000 at 02:17:31AM +0200, Andrea Arcangeli wrote:
> > INTEL as well as the feature bit before enabling XMM and FXSR features (AMD
> > also has fxsr, but we currently don't do anything with it). I moved the
>
> FXSR is supported and it just works fine on Athlon too with the PIII p
Followup to: <[EMAIL PROTECTED]>
By author:Doug Ledford <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On that specific bit I haven't seen it go out of sync yet. However, I program
> it defensively because I already got bit by the fact that the X86_FEATURE_PN
> bit on Intel means so
Andrea Arcangeli wrote:
>
> On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote:
> > @@ -214,8 +215,8 @@
> > movb ready,%al # First CPU if 0
> > orb %al,%al
> > jz 4f # First CPU skip this stuff
> > - movl %cr4,%eax # Turn on 4Mb
On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote:
> @@ -214,8 +215,8 @@
> movb ready,%al # First CPU if 0
> orb %al,%al
> jz 4f # First CPU skip this stuff
> - movl %cr4,%eax # Turn on 4Mb pages
> - orl $16,%eax
> + movl
Andrea Arcangeli wrote:
>
> On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote:
> > I've made a few correctness changes to this code. Items that needed to be
> > corrected for include the facts that the XMM feature bit is an Intel specific
> > bit that other vendors may use for other t
On Wed, Oct 25, 2000 at 02:46:19PM -0400, Doug Ledford wrote:
> I've made a few correctness changes to this code. Items that needed to be
> 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 =
Followup to: <[EMAIL PROTECTED]>
By author:Doug Ledford <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> I've made a few correctness changes to this code. Items that needed to be
> corrected for include the facts that the XMM feature bit is an Intel specific
> bit that other vendors m
Andrea Arcangeli wrote:
> 2.2.18pre15aa1 is here (I will include in the next aa patchkit):
>
>
>ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.18pre15aa1/PIII-3.bz2
>
> Such patch is been generated by a mix of PIII 2.2.x patch and the PIII 2.4.x
> support plus
mxcsr is per-process thing and it's saved and restored with the fpu and it
should be initialized to its default value at reset the first time a
task uses the FPU as we do with the other parts of the FPU (default value
at reset means all SIMD exceptions are masked).
--- 2.4.0-test10-pre3/arch/i386
On Fri, 20 Oct 2000, Andrea Arcangeli wrote:
> Many thanks to Doug and Gabriel for very useful explanations about this FPU
> stuff. I suggest Gabriel to submit his way faster and more correct tag word
> conversion function to Linus for 2.4.x.
Here it a first shot, twd_i387_to_fxsr is guarantee
17 matches
Mail list logo
