Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
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/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 as 'not required' since the data sheet > is not very clear on that "feature". Is it http://lkml.org/lkml/2003/6/5/85 you mean? It seems not to be surely written in data sheet that OOSTORE is necessary. But Geode reorder memory access. > > BTW, I use MediaGX with kernel 2.6.20(and 2.6.20.3) and suspend2. When I > > resume > > the PC and use the PC Card modem, PC is hungup. However, PC isn't hung up > > when > > I apply a WBINVD patch. > > I can't understand it whether there is problem in resume of suspend2 or > > MediaGX > > or both. Many drivers lack support for resume on my PC. > > Which patch are you refering to? 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 X86_USE_3DNOW config X86_OOSTORE bool - depends on (MWINCHIP3D || MWINCHIP2 || MWINCHIPC6) && MTRR + depends on (MWINCHIP3D || MWINCHIP2 || MWINCHIPC6) && MTRR || MGEODEGX1 default y config X86_TSC - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
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. It seems to have disappeared
somewhere.
BTW, I use MediaGX with kernel 2.6.20(and 2.6.20.3) and suspend2. When I resume
the PC and use the PC Card modem, PC is hungup. However, PC isn't hung up when
I apply a WBINVD patch.
I can't understand it whether there is problem in resume of suspend2 or MediaGX
or both. Many drivers lack support for resume on my PC.
> 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 when it works
> > with MediaGX/GeodeGX.
> >
> > diff -Narup a/include/asm-i386/io.h b/include/asm-i386/io.h
> > --- a/include/asm-i386/io.h 2007-02-20 16:23:25.0 +0900
> > +++ b/include/asm-i386/io.h 2007-02-20 17:07:14.0 +0900
> > @@ -232,7 +232,19 @@ static inline void memcpy_toio(volatile
> > * 2. Accidentally out of order processors (PPro errata #51)
> > */
> >
> > -#if defined(CONFIG_X86_OOSTORE) || defined(CONFIG_X86_PPRO_FENCE)
> > +#ifdef CONFIG_MGEODEGX1
> > +
> > +static inline void dma_flush_cache(void)
> > +{
> > + __asm__ __volatile__ ("wbinvd": : :"memory");
> > +}
> > +
> > +#define dma_cache_inv(_start,_size)dma_flush_cache()
> > +#define dma_cache_wback(_start,_size) dma_flush_cache()
> > +#define dma_cache_wback_inv(_start,_size) dma_flush_cache()
> > +#define flush_write_buffers()
> > +
> > +#elif defined(CONFIG_X86_OOSTORE) || defined(CONFIG_X86_PPRO_FENCE)
> >
> > static inline void flush_write_buffers(void)
> > {
> > -
>
> Well it is starting to look like it isn't a caching issue, but more
> likely an issue of which order writes are performed in. I think the MAC
> might be seeing the ownership bit change before the rest of the
> descriptor, which shouldn't happen. With X86_OOSTORE, wmb() is called
> between setting the fields in the descriptor and setting the ownership
> bit to the MAC. I still have to investigate a bit more to find out for
> sure, but that could certainly explain why X86_OOSTORE makes the problem
> become much less frequent. It doesn't completely elliminate it though.
> Of course maybe there are two different problems with the same symptoms.
>
> --
> Len Sorensen
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
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: 401.00
> > clflush size: 32
>
> Hmm with 2.6.18 I am seeing:
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 when it works
with MediaGX/GeodeGX.
diff -Narup a/include/asm-i386/io.h b/include/asm-i386/io.h
--- a/include/asm-i386/io.h 2007-02-20 16:23:25.0 +0900
+++ b/include/asm-i386/io.h 2007-02-20 17:07:14.0 +0900
@@ -232,7 +232,19 @@ static inline void memcpy_toio(volatile
* 2. Accidentally out of order processors (PPro errata #51)
*/
-#if defined(CONFIG_X86_OOSTORE) || defined(CONFIG_X86_PPRO_FENCE)
+#ifdef CONFIG_MGEODEGX1
+
+static inline void dma_flush_cache(void)
+{
+ __asm__ __volatile__ ("wbinvd": : :"memory");
+}
+
+#define dma_cache_inv(_start,_size)dma_flush_cache()
+#define dma_cache_wback(_start,_size) dma_flush_cache()
+#define dma_cache_wback_inv(_start,_size) dma_flush_cache()
+#define flush_write_buffers()
+
+#elif defined(CONFIG_X86_OOSTORE) || defined(CONFIG_X86_PPRO_FENCE)
static inline void flush_write_buffers(void)
{
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
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? > > 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" flag if it is supported). /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 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu tsc msr cx8 cmov mmx cxmmx bogomips: 401.00 clflush size: 32 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MediaGX/GeodeGX1 requires X86_OOSTORE.
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 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 the MediaGX/Geode though it might need OOSTORE, > > but was convinced by others it didn't. Looks like it really does need > > it. The failure that occoured before within a few seconds of starting a > > large transfer, no longer fails and all I did was enable > > CONFIG_X86_OOSTORE, and recompile pcnet32.ko and load the new module on > > the running system. Moving back to the pcnet32.ko built without OOSTORE > > enabled hits the failure again within seconds, until ifconfig eth1 > > down/up reinitialized it's descriptor ring, after which it survices > > another bit of transfer and then fails again. > > Well forcing load/store serialize on the CPU doesn't help, disalbing > memory bypass doesn't help. Enabling the X86_OOSTORE does help. What a > stupid CPU design. 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 +0900 +++ arch/i386/Kconfig.cpu 2007-02-17 21:25:52.0 +0900 @@ -322,7 +322,7 @@ config X86_USE_3DNOW config X86_OOSTORE bool - depends on (MWINCHIP3D || MWINCHIP2 || MWINCHIPC6) && MTRR + depends on (MWINCHIP3D || MWINCHIP2 || MWINCHIPC6) && MTRR || MGEODEGX1 default y config X86_TSC - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
