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 @@ conf
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.
>
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 reject
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
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 #if
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
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
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 ra
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
> 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 "clfl
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
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. Si
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
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 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,
15 matches
Mail list logo
