Athlon problem report summary

Athlon problem report summary

[Alan Cox]

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.

Re: Athlon problem report summary

[Alan Cox]

Probably worth adding

	Most people using VIA chipsets don't see problems either..

Re: Athlon problem report summary

[Kurt Roeckx]

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

Re: Athlon problem report summary

[Disconnect]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
---
   _.-=<Disconnect>=-._
|     dis@sigkill.net    | And Remember...
\  shawn@healthcite.com  / 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 [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------

Re: Athlon problem report summary

[Alan Cox]

> 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

Re: Athlon problem report summary

[Disconnect]

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 [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------

Re: Athlon problem report summary

[Alan Cox]

> 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.

Re: Athlon problem report summary

[Disconnect]

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 [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------

Re: Athlon problem report summary

[Alan Cox]

> 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;
	}
}

Re: Athlon problem report summary

[Arjan van de Ven]

In article <E14qlMO-0002bj-00@the-village.bc.nu> 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

Re: Athlon problem report summary

[Disconnect]

> 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 [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------

Re: Athlon problem report summary

[Jeff Lightfoot]

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/