> 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 chi
>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 address
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 ker
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. A
> 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 work
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 Pent
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.
- J
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 oopses)
> 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 noauto
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 wond
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/80
> 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 f
>
> 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 *sourc
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 i
> + __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) );
16 matches
Mail list logo
