Re: 2.4.1-pre1 breaks XFree 4.0.2 and "w"

[Andrea Arcangeli <andrea@suse.de>]

On Thu, Jan 11, 2001 at 06:36:05PM +0100, Andrea Arcangeli wrote:
> On Thu, Jan 11, 2001 at 11:31:21AM +0100, Udo A. Steinberg wrote:
> >  CONFIG_MK7=y
> 
> I'm looking into it.

The fxsr fixes from 2.4.1-pre1 allows athlon to correctly use FXSR too (when
nofxsr isn't passed to the kernel of course).

So then this 3dnow breaks here:

void *_mmx_memcpy(void *to, const void *from, size_t len)
{
	void *p=to;
	int i= len >> 6;	/* len/64 */

	if (!(current->flags & PF_USEDFPU))
		clts();
	else
	{
		__asm__ __volatile__ ( " fnsave %0; fwait\n"::"m"(current->thread.i387));
		current->flags &= ~PF_USEDFPU;
	}

The 3dnow is hardcoding the usage of old fnsave, whereas it should be using the
i387 operations in first place as all other parts of the kernel.

Then athlon will be able use both the faster fxsr and the 3dnow code
at the same time (whereas in 2.4.0 it wasn't wrongly using fxsr).

I also noticed this minor leftover:

--- ./arch/i386/kernel/i386_ksyms.c.~1~	Thu Dec 14 22:33:59 2000
+++ ./arch/i386/kernel/i386_ksyms.c	Thu Jan 11 17:15:21 2001
@@ -116,6 +116,7 @@
 EXPORT_SYMBOL(mmx_clear_page);
 EXPORT_SYMBOL(mmx_copy_page);
 #endif
+EXPORT_SYMBOL(mmu_cr4_features);
 
 #ifdef CONFIG_SMP
 EXPORT_SYMBOL(cpu_data);


Until I fix the 3dnow code to use the i387.c library please workaround
this way:

--- ./arch/i386/config.in.~1~	Thu Jan 11 17:52:05 2001
+++ ./arch/i386/config.in	Thu Jan 11 18:38:29 2001
@@ -109,7 +109,7 @@
    define_int  CONFIG_X86_L1_CACHE_SHIFT 6
    define_bool CONFIG_X86_TSC y
    define_bool CONFIG_X86_GOOD_APIC y
-   define_bool CONFIG_X86_USE_3DNOW y
+#   define_bool CONFIG_X86_USE_3DNOW y
    define_bool CONFIG_X86_PGE y
    define_bool CONFIG_X86_USE_PPRO_CHECKSUM y
 fi


FXSR on athlon works like a charm in the aa 2.2.x patchkit because in 2.2.x
there are no special string operations that uses 3dnow.

Sorry for having missed that.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/