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 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 found disabling IDE DMA fixed this one
Nobody using an AMD chipset has reported either problem.
Probably worth adding
Most people using VIA chipsets don't see problems either..
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 found disabling IDE DMA fixed this one
That's intresting. I had no problem at all.
hda and hdc are using udma33 here. hdb contains the swap, and
gets this error on boot:
hdb: Conner Peripherals 340MB - CP30344, ATA DISK drive
hdb: set_drive_speed_status: status=0x51 { DriveReady
SeekComplete Error }
hdb: set_drive_speed_status: error=0x04 { DriveStatusError }
ide0: Drive 1 didn't accept speed setting. Oh, well.
[...]
[same error message]
hdb: 670320 sectors (343 MB) w/64KiB Cache, CHS=665/16/63, DMA
hdparm -iv /dev/hdb output:
/dev/hdb:
multcount = 0 (off)
I/O support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 665/16/63, sectors = 670320, start = 0
Model=Conner Peripherals 340MB - CP30344, FwRev=6FT1.67, SerialNo=BQB2B7G
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=665/16/63, TrkSize=40887, SectSize=649, ECCbytes=4
BuffType=3(DualPortCache), BuffSize=64kB, MaxMultSect=64, MultSect=off
DblWordIO=no, OldPIO=1, DMA=yes, OldDMA=1
CurCHS=665/16/63, CurSects=980418570, LBA=no
DMA modes: *mword0
Hope this helps.
Kurt
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
matter, the box is on dialup behind masq, but if you are interested I can
set up an account. No serial console, no remote power cycle, so I'm not
sure how much good it'll do, but it's an option if you want/need it.)
On Mon, 16 Apr 2001, Alan Cox did have cause to say:
> 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 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 found disabling IDE DMA fixed this one
>
>
> Nobody using an AMD chipset has reported either problem.
>
> -
> 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 at http://www.tux.org/lkml/
---
_.-=<Disconnect>=-._
| [email protected] | And Remember...
\ [email protected] / He who controls Purple controls the Universe..
PGP Key given on Request Or at least the Purple parts!
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [http://www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P+>+++ L++++>+++++
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t 5---
X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------
> 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 can tell its hardware problems. The fact not a single AMD chipset
user sees it makes me very suspicious indeed.
Alan
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 all on that same via chipset? (I have seen some reports of
the same chipset working on other mobos.)
> As far as I can tell its hardware problems. The fact not a single AMD chipset
> user sees it makes me very suspicious indeed.
Fair enough - I think so as well (although slightly less so since it's
not just the iwill mobo.)
On a (possibly?) unrelated note, memtest-mmx fails immediately (prints the
version, hardlocks). But I've seen that on a stock PIII as well, so I
don't know what that's worth. The oops I managed to decode was in
mmx_copy_page.
Is there a way to enable everything-K7-except-MMX? (Or, for that matter,
an easy way to see what K7 does that K6 doesn't.)
---
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [http://www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P+>+++ L++++>+++++
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t 5---
X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------
> 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 easy way to see what K7 does that K6 doesn't.)
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.
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/etc (I -really- appreciate the help here) but possibly
more stupid questions.
Is there anything out there to test/benchmark MMX ops? (Preferably with
reporting on MMX and equiv non-MMX ops, tunable memory bandwidth, etc.)
Also, I can try that same kernel w/ memory set to HCLK (pc100) instead of
HCLK+33 (pc133). The ram is pc133, but who knows, it might work. (I'm
pretty sure I had it at pc100 before with no change, but not positive.)
---
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [http://www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P+>+++ L++++>+++++
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t 5---
X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------
> 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
#include <stdio.h>
char space[1024*1024];
char target[1024*1024];
void mmx_copy(char *from, char *to)
{
int i;
char fpu_save[108];
__asm__ __volatile__ ( " fsave %0; fwait\n"::"m"(fpu_save[0]) );
__asm__ __volatile__ (
" prefetch (%0)\n"
" prefetch 64(%0)\n"
" prefetch 128(%0)\n"
" prefetch 192(%0)\n"
" prefetch 256(%0)\n"
: : "r" (from) );
for(i=0;i<4096/64;i++)
{
__asm__ __volatile__ (
" prefetch 320(%0)\n"
" movq (%0), %%mm0\n"
" movq 8(%0), %%mm1\n"
" movq 16(%0), %%mm2\n"
" movq 24(%0), %%mm3\n"
" movq %%mm0, (%1)\n"
" movq %%mm1, 8(%1)\n"
" movq %%mm2, 16(%1)\n"
" movq %%mm3, 24(%1)\n"
" movq 32(%0), %%mm0\n"
" movq 40(%0), %%mm1\n"
" movq 48(%0), %%mm2\n"
" movq 56(%0), %%mm3\n"
" movq %%mm0, 32(%1)\n"
" movq %%mm1, 40(%1)\n"
" movq %%mm2, 48(%1)\n"
" movq %%mm3, 56(%1)\n"
: : "r" (from), "r" (to) : "memory");
from+=64;
to+=64;
}
__asm__ __volatile__ ( " frstor %0;\n"::"m"(fpu_save[0]) );
}
int main(int argc, char *argv)
{
char *from=space;
char *to=target;
int r;
int i;
for(r=0;r<2048;r++)
{
for(i=0;i<256;i++)
{
mmx_copy(from, to);
from+=4096;
to+=4096;
}
from=space;
to=target;
}
}
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 version also. The
original January KK266 BIOS can use K7 optimizations, but any BIOS
after that crashes hard.
--
Jeff Lightfoot -- jeffml at pobox.com -- http://thefoots.com/
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
> 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
errors, etc. (Felt pretty silly as I remounted all my drives and brought
it back up to multi-user mode ;) ..)
So am I correct in assuming at this point that MMX is working fine on this
mobo/chip combo? What's next?
Athlon test program $Id: fast.c,v 1.6 2000/09/23 09:05:45 arjan Exp $
clear_page() tests
clear_page function 'warm up run' took 16151 cycles per page
clear_page function '2.4 non MMX' took 11893 cycles per page
clear_page function '2.4 MMX fallback' took 11736 cycles per page
clear_page function '2.4 MMX version' took 10436 cycles per page
clear_page function 'faster_clear_page' took 4998 cycles per page
clear_page function 'even_faster_clear' took 4881 cycles per page
copy_page() tests
copy_page function 'warm up run' took 17595 cycles per page
copy_page function '2.4 non MMX' took 26701 cycles per page
copy_page function '2.4 MMX fallback' took 26708 cycles per page
copy_page function '2.4 MMX version' took 17649 cycles per page
copy_page function 'faster_copy' took 10480 cycles per page
copy_page function 'even_faster' took 10464 cycles per page
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1 [http://www.ebb.org/ungeek]
GIT/CC/CM/AT d--(-)@ s+:-- a-->? C++++$ ULBS*++++$ P+>+++ L++++>+++++
E--- W+++ N+@ o+>$ K? w--->+++++ O- M V-- PS+() PE Y+@ PGP++() t 5---
X-- R tv+@ b++++>$ DI++++ D++(+++) G++ e* h(-)* r++ y++
------END GEEK CODE BLOCK------