> I was a little skeptical to think that the X11 server code
> has such a bug for SVGA 16bits color server today,
> and yet was still wondering if
Corner cases could exist. If you can replicate it the X folks will be most
interested I suspect.
>
> But can the same problem manifest on AMD 751
>On Sun, May 06, 2001 at 01:51:59PM +0100, Alan Cox wrote:
>
>> > There really needs to be a hardware fix... this doesn't stop some
>> > application having it's owne optimised code from breaking on some
>> > hardware (think games and similation software perhaps).
>>
>> prefetch is virtually
Alan Cox wrote:
>
> > So only working kernel (without noautotune) on that A7V133 machine is
> > RedHat's 2.4.2-2 shipped with RedHat 7.1... But that's not good either
> > because the system has large reiserfs volume and 2.4.2-2 has some
> I wish I knew why the Red Hat one worked 8)
Here's my
Alan Cox wrote:
So only working kernel (without noautotune) on that A7V133 machine is
RedHat's 2.4.2-2 shipped with RedHat 7.1... But that's not good either
because the system has large reiserfs volume and 2.4.2-2 has some
I wish I knew why the Red Hat one worked 8)
Here's my kernel
On Sun, May 06, 2001 at 01:51:59PM +0100, Alan Cox wrote:
There really needs to be a hardware fix... this doesn't stop some
application having it's owne optimised code from breaking on some
hardware (think games and similation software perhaps).
prefetch is virtually addresses. An
I was a little skeptical to think that the X11 server code
has such a bug for SVGA 16bits color server today,
and yet was still wondering if
Corner cases could exist. If you can replicate it the X folks will be most
interested I suspect.
But can the same problem manifest on AMD 751
On Sun, May 06, 2001 at 01:51:59PM +0100, Alan Cox wrote:
> > There really needs to be a hardware fix... this doesn't stop some
> > application having it's owne optimised code from breaking on some
> > hardware (think games and similation software perhaps).
>
> prefetch is virtually addresses.
> Ahmm, 2.4.3 doesn't work. Gives some IDE DMA timeouts on boot. Kernel w=
> as
> compiled with Pentium-MMX processor setting, but I don't know if that's
> enough to disable the Athlon code parts (autodetected at runtime?).
That sounds totally unrelated to any Athlon optimisations
> So only
Christian Bornträger wrote:
>
> Can you try and mail me if the Kernel 2.4.3 (without any ac patch) is
> stable with your system even if you use autotune? "Downgrade" to this
> kernel works fine for me.
Ahmm, 2.4.3 doesn't work. Gives some IDE DMA timeouts on boot. Kernel was
compiled with
Christian Bornträger wrote:
Can you try and mail me if the Kernel 2.4.3 (without any ac patch) is
stable with your system even if you use autotune? Downgrade to this
kernel works fine for me.
Ahmm, 2.4.3 doesn't work. Gives some IDE DMA timeouts on boot. Kernel was
compiled with
Ahmm, 2.4.3 doesn't work. Gives some IDE DMA timeouts on boot. Kernel w=
as
compiled with Pentium-MMX processor setting, but I don't know if that's
enough to disable the Athlon code parts (autodetected at runtime?).
That sounds totally unrelated to any Athlon optimisations
So only working
On Sun, May 06, 2001 at 01:51:59PM +0100, Alan Cox wrote:
There really needs to be a hardware fix... this doesn't stop some
application having it's owne optimised code from breaking on some
hardware (think games and similation software perhaps).
prefetch is virtually addresses. An
Christian Bornträger wrote:
>
> Can you try and mail me if the Kernel 2.4.3 (without any ac patch) is
> stable with your system even if you use autotune? "Downgrade" to this
> kernel works fine for me.
At least RedHat's 2.4.2-2 doesn't seem to lockup. I'll compile and try 2.4.3
tomorrow.
-
Christian Bornträger wrote:
Can you try and mail me if the Kernel 2.4.3 (without any ac patch) is
stable with your system even if you use autotune? Downgrade to this
kernel works fine for me.
At least RedHat's 2.4.2-2 doesn't seem to lockup. I'll compile and try 2.4.3
tomorrow.
- Jussi
On Sunday, May, 2001-05-06 at 20:18:36, Christian Bornträger wrote:
> > Hmm, I'm wondering if this could be same bug that I'm seeing with ASUS
> > A7V133 & Duron/800 when using IDE autotuning (PDC20265).
> > Still haven't got any replies suggesting any reason for lockups I'm seeing
> > (no
> Hmm, I'm wondering if this could be same bug that I'm seeing with ASUS
> A7V133 & Duron/800 when using IDE autotuning (PDC20265).
> Still haven't got any replies suggesting any reason for lockups I'm seeing
> (no oopses). Or is the Promise driver just buggy, because system is solid
> with
On Sun, May 06, 2001 at 07:44:19PM +0300, Jussi Laako wrote:
> Seth Goldberg wrote:
> >
> > and rebooted, the system stayed up a lot longer, but it still crashed (I
> > was in Xwindows and the crash was partially written to the log file)
> > after around 3 minutes of work in X.
>
> Hmm, I'm
Seth Goldberg wrote:
>
> and rebooted, the system stayed up a lot longer, but it still crashed (I
> was in Xwindows and the crash was partially written to the log file)
> after around 3 minutes of work in X.
Hmm, I'm wondering if this could be same bug that I'm seeing with ASUS
A7V133 &
> There really needs to be a hardware fix... this doesn't stop some
> application having it's owne optimised code from breaking on some
> hardware (think games and similation software perhaps).
prefetch is virtually addresses. An application would need access to /dev/mem
or similar. So the only
There really needs to be a hardware fix... this doesn't stop some
application having it's owne optimised code from breaking on some
hardware (think games and similation software perhaps).
prefetch is virtually addresses. An application would need access to /dev/mem
or similar. So the only
Seth Goldberg wrote:
and rebooted, the system stayed up a lot longer, but it still crashed (I
was in Xwindows and the crash was partially written to the log file)
after around 3 minutes of work in X.
Hmm, I'm wondering if this could be same bug that I'm seeing with ASUS
A7V133 Duron/800
On Sun, May 06, 2001 at 07:44:19PM +0300, Jussi Laako wrote:
Seth Goldberg wrote:
and rebooted, the system stayed up a lot longer, but it still crashed (I
was in Xwindows and the crash was partially written to the log file)
after around 3 minutes of work in X.
Hmm, I'm wondering if
Hmm, I'm wondering if this could be same bug that I'm seeing with ASUS
A7V133 Duron/800 when using IDE autotuning (PDC20265).
Still haven't got any replies suggesting any reason for lockups I'm seeing
(no oopses). Or is the Promise driver just buggy, because system is solid
with noautotune.
On Sunday, May, 2001-05-06 at 20:18:36, Christian Borntrger wrote:
Hmm, I'm wondering if this could be same bug that I'm seeing with ASUS
A7V133 Duron/800 when using IDE autotuning (PDC20265).
Still haven't got any replies suggesting any reason for lockups I'm seeing
(no oopses). Or is
>
> As all this is trying to avoid bus turnarounds (i.e. switching from
> reading to writing), wouldn't it be fastest to just trust that the CPU
> has at least 4k worth of cache? (and hope for the best that we don't
> get interrupted in the meanwhile).
>
> void copy_page (char *dest, char
On Sat, May 05, 2001 at 06:26:30PM +0200, Rogier Wolff wrote:
>
> As all this is trying to avoid bus turnarounds (i.e. switching from
> reading to writing), wouldn't it be fastest to just trust that the CPU
> has at least 4k worth of cache? (and hope for the best that we don't
> get interrupted
> + __asm__ __volatile__ (
> + " 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"
> +
Assuming Manfred's diagnosis is right something like this might fix it
*note*: Not tested this is just off the top of my head...
--- arch/i386/lib/mmx.c~Sun Apr 15 16:49:54 2001
+++ arch/i386/lib/mmx.c Sat May 5 08:03:17 2001
@@ -57,7 +57,11 @@
: : "r" (from) );
Assuming Manfred's diagnosis is right something like this might fix it
*note*: Not tested this is just off the top of my head...
--- arch/i386/lib/mmx.c~Sun Apr 15 16:49:54 2001
+++ arch/i386/lib/mmx.c Sat May 5 08:03:17 2001
@@ -57,7 +57,11 @@
: : r (from) );
+ __asm__ __volatile__ (
+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,
On Sat, May 05, 2001 at 06:26:30PM +0200, Rogier Wolff wrote:
As all this is trying to avoid bus turnarounds (i.e. switching from
reading to writing), wouldn't it be fastest to just trust that the CPU
has at least 4k worth of cache? (and hope for the best that we don't
get interrupted in
As all this is trying to avoid bus turnarounds (i.e. switching from
reading to writing), wouldn't it be fastest to just trust that the CPU
has at least 4k worth of cache? (and hope for the best that we don't
get interrupted in the meanwhile).
void copy_page (char *dest, char *source)
{
32 matches
Mail list logo
