On Sat, Mar 17, 2007 at 10:08:10PM +0900, takada wrote:
I tested some patterns. just X86_OOSTORE was effective. WBINVD is needless.
--- arch/i386/Kconfig.cpu~2007-02-05 03:44:54.0 +0900
+++ arch/i386/Kconfig.cpu 2007-02-17 21:25:52.0 +0900
@@ -322,7 +322,7 @@ config
From: [EMAIL PROTECTED] (Lennart Sorensen)
Subject: Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
Date: Thu, 15 Mar 2007 13:31:37 -0400
On Thu, Mar 15, 2007 at 02:39:39PM +0900, takada wrote:
Hiroshi Miura posted `Geode out-of-order store enables' patch in Jun, 2003.
There is http://lkml.org
On Thu, Mar 15, 2007 at 02:39:39PM +0900, takada wrote:
Hiroshi Miura posted `Geode out-of-order store enables' patch in Jun, 2003.
There is http://lkml.org/lkml/2003/6/5/57 .
OOSTORE was enabled at this point in time. It seems to have disappeared
somewhere.
I believe the patch was rejected
From: [EMAIL PROTECTED] (Lennart Sorensen)
Subject: Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
Date: Tue, 20 Feb 2007 09:48:23 -0500
Hiroshi Miura posted `Geode out-of-order store enables' patch in Jun, 2003.
There is http://lkml.org/lkml/2003/6/5/57 .
OOSTORE was enabled at this point in time
From: [EMAIL PROTECTED] (Lennart Sorensen)
Subject: Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
Date: Mon, 19 Feb 2007 19:02:31 -0500
On Tue, Feb 20, 2007 at 08:56:39AM +0900, takada wrote:
/proc/cpuinfo with MediaGXm :
:
flags : fpu tsc msr cx8 cmov mmx cxmmx
bogomips
On Tue, Feb 20, 2007 at 08:34:13PM +0900, takada wrote:
I posted with 2.6.20 + enabled X86_OOSTORE.
The clflush sze line is in /proc/cpuinfo. but clfush is not in flags line.
BTW, can we use WBINVD instruction? I tested compile only.
Do you know a method to change dynamically without #ifdef
On Sat, Feb 17, 2007 at 11:11:13PM +0900, takada wrote:
is it mean what doesn't help with doesn't call set_cx86_reoder()?
this function disable to reorder at 0x4000: to 0x:.
does pcnet32 access at out of above range?
--- arch/i386/Kconfig.cpu~2007-02-05 03:44:54.0
Does anyone know if there is any way to flush a cache line of the cpu to
force rereading system memory for a given address or address range?
There is the clflush instruction, but not all x86 CPUs support it.
You need to check the CPUID flag to know for sure (/proc/cpuinfo will
show a clflush
On Mon, Feb 19, 2007 at 11:48:27AM -0800, Roland Dreier wrote:
Does anyone know if there is any way to flush a cache line of the cpu to
force rereading system memory for a given address or address range?
There is the clflush instruction, but not all x86 CPUs support it.
You need to check
From: Roland Dreier [EMAIL PROTECTED]
Subject: Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
Date: Mon, 19 Feb 2007 11:48:27 -0800
Does anyone know if there is any way to flush a cache line of the cpu to
force rereading system memory for a given address or address range
On Tue, Feb 20, 2007 at 08:56:39AM +0900, takada wrote:
/proc/cpuinfo with MediaGXm :
processor : 0
vendor_id : CyrixInstead
cpu family: 5
model : 5
model name: Cyrix MediaGXtm MMXtm Enhanced
stepping : 2
cpu MHz : 199.750
cache size: 16 KB
From: [EMAIL PROTECTED] (Lennart Sorensen)
Subject: Re: MediaGX/GeodeGX1 requires X86_OOSTORE. (Was: Re: Strange
connection slowdown on pcnet32)
Date: Fri, 16 Feb 2007 19:00:19 -0500
On Fri, Feb 16, 2007 at 05:48:24PM -0500, Lennart Sorensen wrote:
Well so far it really looks like enabling
On Sat, Feb 17, 2007 at 11:11:13PM +0900, takada wrote:
is it mean what doesn't help with doesn't call set_cx86_reoder()?
this function disable to reorder at 0x4000: to 0x:.
does pcnet32 access at out of above range?
No it is accessing system memory by DMA to transfer frames.
On Fri, Feb 16, 2007 at 05:27:28PM -0500, Lennart Sorensen wrote:
On Fri, Feb 16, 2007 at 04:01:57PM -0500, Lennart Sorensen wrote:
It seems whenever it gets stuck, it is always the same descripter it is
stuck on. Here is my current log:
eth1: interrupt csr0=0x4f3 new csr=0x33,
On Fri, Feb 16, 2007 at 05:48:24PM -0500, Lennart Sorensen wrote:
Well so far it really looks like enabling OOSTORE on the Geode
SC1200/GX1 really does make a difference. A bit of searching seems to
indicate the person that originally submitted the patch that enabled
load/store reordering on
15 matches
Mail list logo
