| Message ID | 4015029078.19991223172443@turbolinux.com.cn |
|---|---|
| State | New, archived |
| Headers | show |
| Series |
|
| Related | show |
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
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/
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
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/
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:
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/