> I wrote a set of programs to tune the MMX code. Arjan I suspect did similar
> when he reoptimised the code for the newer Athlon. Simple stuff like
Alan - your proggy ran (no output) for about 5 seconds or so, then exited.
Arjan - from yours, I get the results below. Either way, no OOPs, no
er
In article <[EMAIL PROTECTED]> you wrote:
> I wrote a set of programs to tune the MMX code. Arjan I suspect did similar
> when he reoptimised the code for the newer Athlon.
My app is at http://www.fenrus.demon.nl/athlon.c
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel
Disconnect wrote:
> Addendum to 1. So far everyone (at least on LKML) who has had the
> crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or
> kk266r, IIRC) mobo.
>
> Have we gotten any fix, other than not using K7 optimizations?
I think it has something to do with the BIOS v
> Is there anything out there to test/benchmark MMX ops? (Preferably with
> reporting on MMX and equiv non-MMX ops, tunable memory bandwidth, etc.)
I wrote a set of programs to tune the MMX code. Arjan I suspect did similar
when he reoptimised the code for the newer Athlon. Simple stuff like
#
On Sat, 21 Apr 2001, Alan Cox did have cause to say:
> K7 optimisation basically enabled the MMX copy/clear code which adds 30-40%
> performance to those functions. It also materially ups the maximum memory
> bandwidth the processor will use which may be where the fun starts.
Not to be slow/dull
> Oddness. Is it all on that same via chipset? (I have seen some reports of
> the same chipset working on other mobos.)
Variants of the VIA chipset. But I have reports of works/not working from
the same board even.
> Is there a way to enable everything-K7-except-MMX? (Or, for that matter,
> an e
On Sat, 21 Apr 2001, Alan Cox did have cause to say:
> > Addendum to 1. So far everyone (at least on LKML) who has had the
> > crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or
> > kk266r, IIRC) mobo.
>
> Not quite all. Many have but I have other reports.
Oddness. Is it a
> Addendum to 1. So far everyone (at least on LKML) who has had the
> crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or
> kk266r, IIRC) mobo.
Not quite all. Many have but I have other reports.
> Have we gotten any fix, other than not using K7 optimizations?
As far as I ca
Addendum to 1. So far everyone (at least on LKML) who has had the
crash-immediatly-do-not-pass-go issues has been using an iwill kk266 (or
kk266r, IIRC) mobo.
Have we gotten any fix, other than not using K7 optimizations?
I'm willing to keep trying new patches, if necessary. (And for that
matte
On Mon, Apr 16, 2001 at 01:30:14PM +0100, Alan Cox wrote:
>
> 2. 'My athlon box is fine until I am swapping' {and using DMA}
>
> Compiler independant, CPU version independant. All victims have a VIA chipset.
> This one may be linked to the reported problems with VIA PCI. Two of the
> reporters
Probably worth adding
Most people using VIA chipsets don't see problems either..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
There appear to be two common threads to this
1. 'It runs if I don't use Athlon optimisations'
This one is compiler independant. It seems to be unrelated to obvious
candidates like vesafb. It isnt related to CPU version. Every victim has a
VIA chipset machine.
2. 'My athlon box is fine unt
12 matches
Mail list logo