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:
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: [email protected]
WWW: http://www-ict.its.tudelft.nl/~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
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: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
> > 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.
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
--
<[email protected]>
KEYSERVER=wwwkeys.de.pgp.net
SEARCH STRING=Jeffrey Rose
KEYID=6AD04244
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: [email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
[email protected] (Linus Torvalds) wrote on 23.12.00 in <[email protected]>:
> 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
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 [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
On Sun, Dec 24, 2000 at 11:36:00AM +0200, Kai Henningsen wrote:
> [email protected] (Linus Torvalds) wrote on 23.12.00 in <[email protected]>:
>
> > 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 - [email protected] or [email protected] or [email protected]
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
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
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 - [email protected] or [email protected] or [email protected]
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
* Linus Torvalds ([email protected]) [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/
[email protected] KF6VNC
[email protected] (Tim Wright) wrote on 24.12.00 in <[email protected]>:
> 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
>
> [email protected] (Tim Wright) wrote on 24.12.00 in <[email protected]>:
>
> > 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."
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.
> 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)
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
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.
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 [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
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.
--
** [email protected] ** 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.