About Celeron processor memory barrier problem

About Celeron processor memory barrier problem

[michael chen]

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

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:


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

Re: About Celeron processor memory barrier problem

[Erik Mouw]

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

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
-
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/

Re: About Celeron processor memory barrier problem

[Linus Torvalds]

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/

Re: About Celeron processor memory barrier problem

[Erik Mouw]

On Sat, Dec 23, 2000 at 09:21:51AM -0800, Linus Torvalds wrote:
> A Celeron isn't a PIII, and you shouldn't tell the configure that it is.

Well, some Celerons are. My laptop has a Celeron with a Coppermine
core, so it is PIII based. Here is the output from /proc/cpuinfo:

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 8
model name	: Celeron (Coppermine)
stepping	: 1
cpu MHz		: 501.140
cache size	: 128 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 vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips	: 999.42

The laptop runs perfectly well when I select a PIII CPU in the kernel
config. Here is a small patch that fixes the documentation:

Index: Documentation/Configure.help
===================================================================
RCS file: /home/erik/cvsroot/elinux/Documentation/Configure.help,v
retrieving revision 1.1.1.57
diff -u -r1.1.1.57 Configure.help
--- Documentation/Configure.help	2000/12/13 15:10:53	1.1.1.57
+++ Documentation/Configure.help	2000/12/23 22:58:12
@@ -2868,7 +2868,7 @@
    - "Pentium-Classic" for the Intel Pentium.
    - "Pentium-MMX" for the Intel Pentium MMX.
    - "Pentium-Pro" for the Intel Pentium Pro/Celeron/Pentium II.
-   - "Pentium-III" for the Intel Pentium III.
+   - "Pentium-III" for the Intel Pentium III/Celeron Coppermine.
    - "Pentium-4" for the Intel Pentium 4
    - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
    - "Athlon" for the AMD Athlon (K7).
Index: arch/i386/config.in
===================================================================
RCS file: /home/erik/cvsroot/elinux/arch/i386/config.in,v
retrieving revision 1.1.1.13
diff -u -r1.1.1.13 config.in
--- arch/i386/config.in	2000/12/13 15:09:15	1.1.1.13
+++ arch/i386/config.in	2000/12/23 23:12:55
@@ -33,7 +33,7 @@
 	 Pentium-Classic		CONFIG_M586TSC \
 	 Pentium-MMX			CONFIG_M586MMX \
 	 Pentium-Pro/Celeron/Pentium-II	CONFIG_M686 \
-	 Pentium-III			CONFIG_M686FXSR \
+	 Pentium-III/Celeron Coppermine	CONFIG_M686FXSR \
 	 Pentium-4			CONFIG_MPENTIUM4 \
 	 K6/K6-II/K6-III		CONFIG_MK6 \
 	 Athlon/K7			CONFIG_MK7 \


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
-
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/

Re: About Celeron processor memory barrier problem

[Jeffrey Rose]

Erik Mouw wrote:
> 
> On Sat, Dec 23, 2000 at 09:21:51AM -0800, Linus Torvalds wrote:
> > A Celeron isn't a PIII, and you shouldn't tell the configure that it is.
> 
> Well, some Celerons are. My laptop has a Celeron with a Coppermine
> core, so it is PIII based. Here is the output from /proc/cpuinfo:
> 
> processor       : 0
> vendor_id       : GenuineIntel
> cpu family      : 6
> model           : 8
> model name      : Celeron (Coppermine)
> stepping        : 1
> cpu MHz         : 501.140
> cache size      : 128 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 vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
> bogomips        : 999.42

I also have a Celeron 600 in my Compaq 5000, but even with the output
below, I am not sure this is what Linus is talking about! I believe
Linus is trying to say, "We HAVE configurations set for that specific
architecture, so please USE them." However, I suppose you are saying you
will get better performance from selecting PIII due to this output? Let
me know ...

jrose$ cat /proc/info 

processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 8
model name	: Celeron (Coppermine)
stepping	: 3
cpu MHz		: 598.064
cache size	: 128 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 vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx fxsr sse
bogomips	: 1192.76

Cheers,

Jeff
-- 
<Jeffrey.Rose@t-online.de>
KEYSERVER=wwwkeys.de.pgp.net
SEARCH STRING=Jeffrey Rose
KEYID=6AD04244
-
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/

Re: About Celeron processor memory barrier problem

[Erik Mouw]

On Sun, Dec 24, 2000 at 10:45:14AM +0100, Jeffrey Rose wrote:
> I also have a Celeron 600 in my Compaq 5000, but even with the output
> below, I am not sure this is what Linus is talking about! I believe
> Linus is trying to say, "We HAVE configurations set for that specific
> architecture, so please USE them." However, I suppose you are saying you
> will get better performance from selecting PIII due to this output? Let
> me know ...

The confusion is because Intel reused the name Celeron for a completely
different CPU. The original Celeron was based on a PII core, the new
Celeron is based on a PIII core. Both Celerons have the same features
as the CPU they are based on, but with less cache memory. Selecting
PIII for the new PIII based Celeron will indeed give you slightly
better performance.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/
-
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/

Re: About Celeron processor memory barrier problem

[Matthias Schniedermeyer]

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

This is what 2.2.17 thinks about my Celeron 600MHz

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 8
model name      : Pentium III (Coppermine)
stepping        : 6
cpu MHz         : 601.374
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
sep_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr xmm
bogomips        : 1199.31






Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

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

Re: About Celeron processor memory barrier problem

[Kai Henningsen]

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/

Re: About Celeron processor memory barrier problem

[Tim Wright]

On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote:
> 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?
> 

There was a similar thread to this recently. The issue is that if you
choose the wrong processor type, you may not even be able to complain.
This is a user issue. All the distributions of which I am aware boot happily
on any x86 machine, because they build the kernel for the lowest common
denominator. Some detect the CPU type and install an appropriate kernel
subsequently. So... the only way you can get into this mess is if you build
a kernel yourself and choose the wrong options. There are many ways of
producing a non-bootable kernel. The expectation is that if you want to go
off and build your own kernel, you need to know what you're doing :-)

Tim

-- 
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
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/

Re: About Celeron processor memory barrier problem

[Linus Torvalds]

On Sun, 24 Dec 2000, Tim Wright wrote:
> > 
> > Which is all fine, but maybe the kernel really ought to detect that  
> > problem and complain at boot time?
> > 
> > Or does that happen already?
> 
> There was a similar thread to this recently. The issue is that if you
> choose the wrong processor type, you may not even be able to complain.

Indeed. Some of the issues end up just becoming compiler flags, which
means that anything that uses C is "tainted" by the processor choice. And
happily there isn't all that much non-C in the kernel any more.

One thing we _could_ potentially do is to simplify the CPU selection a
bit, and make it a two-stage process. Basically have a

	bool "Optimize for current CPU" CONFIG_CPU_CURRENT

which most people who just want to get the best kernel would use. Less
confusion that way.

		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/

Re: About Celeron processor memory barrier problem

[Tim Wright]

On Sun, Dec 24, 2000 at 02:25:54PM -0800, Linus Torvalds wrote:
> 
> Indeed. Some of the issues end up just becoming compiler flags, which
> means that anything that uses C is "tainted" by the processor choice. And
> happily there isn't all that much non-C in the kernel any more.
> 
> One thing we _could_ potentially do is to simplify the CPU selection a
> bit, and make it a two-stage process. Basically have a
> 
> 	bool "Optimize for current CPU" CONFIG_CPU_CURRENT
> 
> which most people who just want to get the best kernel would use. Less
> confusion that way.
> 
> 		Linus

Makes sense. Are you thinking along the lines of parsing /proc/cpuinfo to work
out what is there, or did you have something else in mind ?

Regards,

Tim

-- 
Tim Wright - timw@splhi.com or timw@aracnet.com or twright@us.ibm.com
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
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/

Re: About Celeron processor memory barrier problem

[The Doctor What]

* Linus Torvalds (torvalds@transmeta.com) [001224 16:27]:
> One thing we _could_ potentially do is to simplify the CPU selection a
> bit, and make it a two-stage process. Basically have a
> 
> 	bool "Optimize for current CPU" CONFIG_CPU_CURRENT
> 
> which most people who just want to get the best kernel would use. Less
> confusion that way.

Good Lord, YES!  And while we're at it, how about a:
        "Build into kernel every module for hardware I have..."

That'd make a 'make config' one line....

(I'll go back to dreaming)

Ciao!

-- 
Excusing bad programming is a shooting offence, no matter _what_ the circumstances.
	-- Linus Torvalds (linux-kernel mailing list)

The Doctor What: Not that 'who' guy              http://docwhat.gerf.org/
docwhat@gerf.org                                                   KF6VNC
-
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/

Re: About Celeron processor memory barrier problem

[Alan Cox]

> One thing we _could_ potentially do is to simplify the CPU selection a
> bit, and make it a two-stage process. Basically have a
> 
> 	bool "Optimize for current CPU" CONFIG_CPU_CURRENT
> 
> which most people who just want to get the best kernel would use. Less
> confusion that way.

If we do that I'd rather see a make autoconfig that does the lot from
proc/pci etc 8)

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

Re: About Celeron processor memory barrier problem

[Linus Torvalds]

On Mon, 25 Dec 2000, Alan Cox wrote:

> > One thing we _could_ potentially do is to simplify the CPU selection a
> > bit, and make it a two-stage process. Basically have a
> > 
> > 	bool "Optimize for current CPU" CONFIG_CPU_CURRENT
> > 
> > which most people who just want to get the best kernel would use. Less
> > confusion that way.
> 
> If we do that I'd rather see a make autoconfig that does the lot from
> proc/pci etc 8)

Good point. No point in adding a new config option, we should just have a
new configurator instead. Of course, it can't handle many of the
questions, so it would still have to fall back on asking.

That _would_ be a nice addition eventually. It's a bigger project than the
one I envisioned, though.

		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/

Re: About Celeron processor memory barrier problem

[Rogier Wolff]

Linus Torvalds wrote:
> > If we do that I'd rather see a make autoconfig that does the lot from
> > proc/pci etc 8)
> 
> Good point. No point in adding a new config option, we should just have a
> new configurator instead. Of course, it can't handle many of the
> questions, so it would still have to fall back on asking.
> 
> That _would_ be a nice addition eventually. It's a bigger project than the
> one I envisioned, though.

The way I interpreted Alan is that 

	make autoconfig

would spit out the default config, modified for the current setup, as
far as possible. So "my PCI devices" would be configured into the
kernel automatically (the way Linus likes it ;-). Similarly the
"complicated" CPU selection would be "don't touch unless you really
know what you're doing: autoconfig analized your cpuinfo". 

It would at least NOT INPACT anything in the current setup. 

				Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots. 
* There are also old, bald pilots. 
-
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/

Re: About Celeron processor memory barrier problem

[Riley Williams]

Hi Linus.

On Sun, 24 Dec 2000, Linus Torvalds wrote:

> On Sun, 24 Dec 2000, Tim Wright wrote:

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

>> There was a similar thread to this recently. The issue is that if
>> you choose the wrong processor type, you may not even be able to
>> complain.

Perhaps the boot and setup code should always be compiled to assume that
it's running on an i386 (or whatever the lowest common denominator is)
until it has verified that the correct processor is actually present?
Memory says that the boot and setup code is discarded during the boot
process, so this shouldn't cause any problems.

> Indeed. Some of the issues end up just becoming compiler flags,
> which means that anything that uses C is "tainted" by the processor
> choice. And happily there isn't all that much non-C in the kernel
> any more.

> One thing we _could_ potentially do is to simplify the CPU selection
> a bit, and make it a two-stage process. Basically have a

>	bool 'Optimize for current CPU' CONFIG_CPU_CURRENT

> which most people who just want to get the best kernel would use.
> Less confusion that way.

Something along the lines of the enclosed patch ???

Best wishes from Riley.

***********************************************************************

--- linux-2.2.18/arch/i386/config.in~	Tue Dec 12 12:59:50 2000
+++ linux-2.2.18/arch/i386/config.in	Mon Jan  1 11:44:23 2001
@@ -9,16 +9,36 @@
 bool 'Prompt for development and/or incomplete code/drivers' CONFIG_EXPERIMENTAL
 endmenu
 
 mainmenu_option next_comment
 comment 'Processor type and features'
+bool 'Optimize for current CPU' CONFIG_CPU_CURRENT
+if [ "$CONFIG_CPU_CURRENT" = "y" ]; then
+
+  ########################################################
+  ##                                                    ##
+  ## Select current CPU. This is NOT valid in config.in ##
+  ## as it doesn't work with `make xconfig` at all, and ##
+  ## may not work with `make menuconfig` either.        ##
+  ##                                                    ##
+  ## The scripts/cpu shell script produces the variable ##
+  ## for the current processor or CONFIG_CPU_UNKNOWN if ##
+  ## it is unable to determine the current processor.   ##
+  ##                                                    ##
+  ########################################################
+
+  define_bool `bash -c scripts/cpu` y
+
+fi
+if [ "$CONFIG_CPU_CURRENT" != "y" -o "$CONFIG_CPU_UNKNOWN" = "y" ]; then
-choice 'Processor family' \
+  choice '  Processor family' \
 	"386			CONFIG_M386	\
 	 486/Cx486		CONFIG_M486	\
 	 586/K5/5x86/6x86	CONFIG_M586	\
 	 Pentium/K6/TSC		CONFIG_M586TSC	\
 	 PPro/6x86MX		CONFIG_M686" PPro
+fi
 #
 # Define implied options from the CPU selection here
 #
 if [ "$CONFIG_M386" != "y" ]; then
   define_bool CONFIG_X86_WP_WORKS_OK y
--- linux-2.2.18/scripts/cpu~	Thu Jan  1 01:00:00 1970
+++ linux-2.2.18/scripts/cpu	Mon Jan  1 14:39:11 2001
@@ -0,0 +1,33 @@
+#!/bin/bash
+
+function analyse() {
+	local CPU=CONFIG_CPU_UNKNOWN
+	local WORD
+
+	while read WORD ; do
+		case ".$WORD" in
+			.amd_k5)	CPU=CONFIG_M586 	;;
+			.amd_k6)	CPU=CONFIG_M586TSC	;;
+			.i386)		CPU=CONFIG_M386 	;;
+			.i486)		CPU=CONFIG_M486 	;;
+			.i586)		CPU=CONFIG_M586 	;;
+			.pentium)	CPU=CONFIG_M586 	;;
+		esac
+#		echo "DEBUG: WORD = '$WORD', CPU = $CPU" >&2
+	done
+	echo $CPU
+}
+
+function model() {
+	uname -m
+	grep '^model name' /proc/cpuinfo | cut -d : -f 2-
+}
+
+function prepare() {
+	tr '(-' ' _'				\
+		| tr -cd 'A-Z a-z_0-9\n' 	\
+		| tr A-Z a-z			\
+		| tr -s ' ' '\n'
+}
+
+model | prepare | analyse

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

Re: About Celeron processor memory barrier problem

[Kai Henningsen]

timw@splhi.com (Tim Wright)  wrote on 24.12.00 in <20001224125023.A1900@scutter.internal.splhi.com>:

> On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote:

> There was a similar thread to this recently. The issue is that if you
> choose the wrong processor type, you may not even be able to complain.

Hmm ... I think I can see ways around that (essentially similar to the 16  
bit bootstrap code), but it may indeed be more trouble than it's worth.

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/

Re: About Celeron processor memory barrier problem

[Ian Stirling]

> 
> timw@splhi.com (Tim Wright)  wrote on 24.12.00 in <20001224125023.A1900@scutter.internal.splhi.com>:
> 
> > On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote:
> 
> > There was a similar thread to this recently. The issue is that if you
> > choose the wrong processor type, you may not even be able to complain.
> 
> Hmm ... I think I can see ways around that (essentially similar to the 16  
> bit bootstrap code), but it may indeed be more trouble than it's worth.

What about a simple solution, 
"Ok, Booting the kernel for i486+fpu and above."

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

Re: About Celeron processor memory barrier problem

[Pavel Machek]

Hi!

> > On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote:
> 
> > There was a similar thread to this recently. The issue is that if you
> > choose the wrong processor type, you may not even be able to complain.
> 
> Hmm ... I think I can see ways around that (essentially similar to the 16  
> bit bootstrap code), but it may indeed be more trouble than it's worth.

Actually we are doing cpu detection during "uncompress" stage on
x86-64.

Here's how we do it: You might consider something similar.
								Pavel

--- arch/i386/boot/compressed/misc.c	Mon Nov 20 23:50:36 2000
+++ arch/x86_64/boot/compressed/misc.c	Mon Nov 13 21:10:26 2000
@@ -8,6 +8,7 @@
  * puts by Nick Holloway 1993, better puts by Martin Mares 1995
  * High loaded stuff by Hans Lermen & Werner Almesberger, Feb. 1996
  */
+asm(".code32"); 
 
 #include <linux/vmalloc.h>
 #include <asm/io.h>
@@ -340,6 +341,75 @@
 	}
 }
 
+void check_cpu(void)
+{
+	int res = 0;
+	asm volatile( " \n\
+	movl $3,%%edx		# at least 386 \n\
+	pushfl			# push EFLAGS \n\
+	popl %%eax		# get EFLAGS \n\
+	movl %%eax,%%ecx		# save original EFLAGS \n\
+	xorl $0x40000,%%eax	# flip AC bit in EFLAGS \n\
+	pushl %%eax		# copy to EFLAGS \n\
+	popfl			# set EFLAGS \n\
+	pushfl			# get new EFLAGS \n\
+	popl %%eax		# put it in eax \n\
+	xorl %%ecx,%%eax		# change in flags \n\
+	andl $0x40000,%%eax	# check if AC bit changed \n\
+	je 1f \n\
+\n\
+	movl $4,%%edx		# at least 486 \n\
+	movl %%ecx,%%eax \n\
+	xorl $0x200000,%%eax	# check ID flag \n\
+	pushl %%eax \n\
+	popfl			# if we are on a straight 486DX, SX, or \n\
+	pushfl			# 487SX we can't change it \n\
+	popl %%eax \n\
+	xorl %%ecx,%%eax \n\
+	pushl %%ecx		# restore original EFLAGS \n\
+	popfl \n\
+	andl $0x200000,%%eax \n\
+	je 1f \n\
+\n\
+	/* get vendor info */ \n\
+#	xorl %%eax,%%eax			# call CPUID with 0 -> return vendor ID \n\
+#	cpuid \n\
+#	movl $5, %%edx \n\
+#	cmpl $0x41757468,%%ebx		# check thats amd \n\
+#	jne 1f \n\
+\n\
+	mov $0x80000000,%%eax\n\	# Is extended cpuid supported?
+	cpuid\n\
+	test %%eax,0x80000000\n\
+	movl $5, %%edx \n\
+	jz 1f\n\
+\n\
+	movl $0x80000001,%%eax \n\
+	cpuid \n\
+	andl $0x20000000,%%edx \n\
+	movl $6, %%edx \n\
+	jz 1f \n\
+\n\
+	movl $7, %%edx \n\
+1:" : "=d" (res) : : "eax", "ebx", "ecx" );
+
+	switch (res) {
+	case 3: puts( "386" );
+		break;
+	case 4: puts( "486" );
+		break;
+	case 5: puts( "no extended cpuid" );
+		break;
+	case 6: puts( "non-64bit 586+" );
+		break;
+	case 7: puts( "64bit" );
+		break;
+	default:puts( "internal error" );
+		break;
+	}
+	if (res !=7)
+		error( "Sorry, your CPU is not capable of running 64-bit kernel." );
+}
 
 int decompress_kernel(struct moveparams *mv, void *rmode)
 {
@@ -360,7 +430,9 @@
 	else setup_output_buffer_if_we_run_high(mv);
 
 	makecrc();
-	puts("Uncompressing Linux... ");
+	puts("Checking CPU type... ");
+	check_cpu();
+	puts(", uncompressing Linux... ");
 	gunzip();
 	puts("Ok, booting the kernel.\n");
 	if (high_loaded) close_output_buffer_if_we_run_high(mv);



-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
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/

Re: About Celeron processor memory barrier problem

[Albert D. Cahalan]

Tim Wright writes:

> There was a similar thread to this recently. The issue is that if you
> choose the wrong processor type, you may not even be able to complain.

An illegal opcode handler could deal with the problem.
It could crudely emulate just enough to make printk work.
-
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/

Re: About Celeron processor memory barrier problem

[Pavel Machek]

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

-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
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/

Re: About Celeron processor memory barrier problem

[Giacomo Catenazzi]

Linus Torvalds wrote:
> 
> On Mon, 25 Dec 2000, Alan Cox wrote:
> 
> > > One thing we _could_ potentially do is to simplify the CPU selection a
> > > bit, and make it a two-stage process. Basically have a
> > >
> > >     bool "Optimize for current CPU" CONFIG_CPU_CURRENT
> > >
> > > which most people who just want to get the best kernel would use. Less
> > > confusion that way.
> >
> > If we do that I'd rather see a make autoconfig that does the lot from
> > proc/pci etc 8)
> 

I have already made such program.
I detect most of PCI devices, filesystem (if in /etc/fstab or
/proc/mounts,
console, devices (char and blk dev), other deviced that use
resources,...
[ and I detect also some net protocols !]

> Good point. No point in adding a new config option, we should just have a
> new configurator instead. Of course, it can't handle many of the
> questions, so it would still have to fall back on asking.

My idea is to add also a CONFIG_EXPERT CONFIG_NOVICE,...
In a CONFIG_NOVICE, we can add the (undetectable) software protocols
(PPP, ...
also if user don't use it! (and IMHO we can configure a NOVICE system
that would boot and work without any questions).

Problem: How include it in 2.4?
I designed it to use esr's CML2 (for 2.5) and backport as user program
a version of CML2 with the autoconfigure.
The other possible mode: autoconfigure write to .config and user will do
a make oldconfig. But there are to many question (my autoconfigure
say that a driver is need, but it doesn't say 'no'.

Problem 2: ESR now requires Python 2, which is not yet in Debian, and I
think
that this further requisite will delay the inclusion of CML2 in kernel
:-(


	giacomo

PS: my autoconfigure is in http://people.debian.org/~cate/autoconfigure
It is updated to the 2.4.0-test12!

PPS: Comments are welcome!

> 
> That _would_ be a nice addition eventually. It's a bigger project than the
> one I envisioned, though.
-
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/