About Celeron processor memory barrier problem

Message ID 4015029078.19991223172443@turbolinux.com.cn
State New, archived
Headers show
Series
  • About Celeron processor memory barrier problem
Related show

Commit Message

michael chen Dec. 23, 1999, 9:24 a.m. UTC
Hi,
        I found that when I compiled the 2.4 kernel with the option
    of Pentium III or Pentium 4 on a Celeron's PC, it could cause  the
    system hang at very beginning boot stage, and I found the problem
    is cause by the fact that Intel Celeron doesn't have a real memory
    barrier,but when you choose the Pentium III option, the kernel
    assume the processor has a real memory barrier.
    Here is a patch to fix it:

    Merry Christmas :)
    Michael Chen



-
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/

Comments

Erik Mouw Dec. 23, 2000, 11:04 a.m. UTC | #1
On Thu, Dec 23, 1999 at 05:24:43PM +0800, michael chen wrote:
>         I found that when I compiled the 2.4 kernel with the option
>     of Pentium III or Pentium 4 on a Celeron's PC, it could cause  the
>     system hang at very beginning boot stage, and I found the problem
>     is cause by the fact that Intel Celeron doesn't have a real memory
>     barrier,but when you choose the Pentium III option, the kernel
>     assume the processor has a real memory barrier.

I think there is some confusion in the name "Celeron". AFAIK there are
two kinds of Celerons: the original PII based Celeron, or the newer
PIII based Celeron. My laptop has a PIII (Coppermine) based Celeron,
and it boots perfectly well without your patch. 

If you are using a PII based Celeron, you should compile the kernel
with support for the "Pentium-Pro/Celeron/Pentium-II". You certainly
should not try to run a kernel with support for P4 on a "lower" CPU,
read the documentation about CONFIG_M386 in Documentation/Configure.help
for more information.


Erik
Linus Torvalds Dec. 23, 2000, 5:21 p.m. UTC | #2
On Thu, 23 Dec 1999, michael chen wrote:
>         I found that when I compiled the 2.4 kernel with the option
>     of Pentium III or Pentium 4 on a Celeron's PC, it could cause  the
>     system hang at very beginning boot stage, and I found the problem
>     is cause by the fact that Intel Celeron doesn't have a real memory
>     barrier,but when you choose the Pentium III option, the kernel
>     assume the processor has a real memory barrier.
>     Here is a patch to fix it:

No.

The fix is to not lie to the configurator.

A Celeron isn't a PIII, and you shouldn't tell the configure that it is.

The whole point of being able to choose the CPU to optimize for is that we
can optimize things at compile-time.

		Linus

-
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/
Pavel Machek Dec. 23, 2000, 10:34 p.m. UTC | #3
Hi!

> diff -Nur linux/include/asm-i386/system.h linux.new/include/asm-i386/system.h
> --- linux/include/asm-i386/system.h     Mon Dec 11 19:26:39 2000
> +++ linux.new/include/asm-i386/system.h Sat Dec 23 16:06:01 2000
> @@ -274,7 +274,14 @@
>  #ifndef CONFIG_X86_XMM
>  #define mb()   __asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
>  #else
> -#define mb()   __asm__ __volatile__ ("sfence": : :"memory")
> +#define mb()  do { \
> +       if ( cpu_has_xmm ) { \
                ~~~~~~~~~~~~~~~~~~

Cost of test may well be bigger than gain by using sfence...

Pavel
Kai Henningsen Dec. 24, 2000, 9:36 a.m. UTC | #4
torvalds@transmeta.com (Linus Torvalds)  wrote on 23.12.00 in <Pine.LNX.4.10.10012230920330.2066-100000@penguin.transmeta.com>:

> On Thu, 23 Dec 1999, michael chen wrote:
> >         I found that when I compiled the 2.4 kernel with the option
> >     of Pentium III or Pentium 4 on a Celeron's PC, it could cause  the
> >     system hang at very beginning boot stage, and I found the problem
> >     is cause by the fact that Intel Celeron doesn't have a real memory
> >     barrier,but when you choose the Pentium III option, the kernel
> >     assume the processor has a real memory barrier.
> >     Here is a patch to fix it:
>
> No.
>
> The fix is to not lie to the configurator.
>
> A Celeron isn't a PIII, and you shouldn't tell the configure that it is.
>
> The whole point of being able to choose the CPU to optimize for is that we
> can optimize things at compile-time.

Which is all fine, but maybe the kernel really ought to detect that  
problem and complain at boot time?

Or does that happen already?

MfG Kai
-
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/

Patch

diff -Nur linux/include/asm-i386/system.h linux.new/include/asm-i386/system.h
--- linux/include/asm-i386/system.h     Mon Dec 11 19:26:39 2000
+++ linux.new/include/asm-i386/system.h Sat Dec 23 16:06:01 2000
@@ -274,7 +274,14 @@ 
 #ifndef CONFIG_X86_XMM
 #define mb()   __asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
 #else
-#define mb()   __asm__ __volatile__ ("sfence": : :"memory")
+#define mb()  do { \
+       if ( cpu_has_xmm ) { \
+               asm volatile("sfence": : :"memory"); \
+       } \
+       else { \
+               asm volatile("lock; addl $0,0(%%esp)": : :"memory"); \
+       } \
+} while (0)                                                            
 #endif
 #define rmb()  mb()
 #define wmb()  __asm__ __volatile__ ("": : :"memory")
diff -Nur linux/include/linux/tqueue.h linux.new/include/linux/tqueue.h
--- linux/include/linux/tqueue.h        Sat Dec 23 16:16:44 2000
+++ linux.new/include/linux/tqueue.h    Sat Dec 23 16:06:01 2000
@@ -17,6 +17,7 @@ 
 #include <linux/list.h>
 #include <asm/bitops.h>
 #include <asm/system.h>
+#include <asm/processor.h>
 
 /*
  * New proposed "bottom half" handlers:
diff -Nur linux/include/asm-i386/system.h linux.new/include/asm-i386/system.h
--- linux/include/asm-i386/system.h     Mon Dec 11 19:26:39 2000
+++ linux.new/include/asm-i386/system.h Sat Dec 23 16:06:01 2000
@@ -274,7 +274,14 @@ 
 #ifndef CONFIG_X86_XMM
 #define mb()   __asm__ __volatile__ ("lock; addl $0,0(%%esp)": : :"memory")
 #else
-#define mb()   __asm__ __volatile__ ("sfence": : :"memory")
+#define mb()  do { \
+       if ( cpu_has_xmm ) { \
+               asm volatile("sfence": : :"memory"); \
+       } \
+       else { \
+               asm volatile("lock; addl $0,0(%%esp)": : :"memory"); \
+       } \
+} while (0)                                                            
 #endif
 #define rmb()  mb()
 #define wmb()  __asm__ __volatile__ ("": : :"memory")
diff -Nur linux/include/linux/tqueue.h linux.new/include/linux/tqueue.h
--- linux/include/linux/tqueue.h        Sat Dec 23 16:16:44 2000
+++ linux.new/include/linux/tqueue.h    Sat Dec 23 16:06:01 2000
@@ -17,6 +17,7 @@ 
 #include <linux/list.h>
 #include <asm/bitops.h>
 #include <asm/system.h>
+#include <asm/processor.h>
 
 /*
  * New proposed "bottom half" handlers: