[X86] Fix up silly i1586 boot message.

[X86] Fix up silly i1586 boot message.

[Dave Jones]

Trying to boot a 64-bit kernel on a 32bit Pentium 4 gets
you an amusing message along the lines of.
"you need an x86-64, but you only have an i1586"
due to the P4 being family F.  Munge it to be 686.

Signed-off-by: Dave Jones <davej@redhat.com>

diff --git a/arch/x86/boot/cpu.c b/arch/x86/boot/cpu.c
index 00e19ed..882c839 100644
--- a/arch/x86/boot/cpu.c
+++ b/arch/x86/boot/cpu.c
@@ -28,6 +28,8 @@ static char *cpu_name(int level)
 	if (level == 64) {
 		return "x86-64";
 	} else {
+		if (level == 15)
+			level = 6;
 		sprintf(buf, "i%d86", level);
 		return buf;
 	}

-- 
http://www.codemonkey.org.uk

Re: [X86] Fix up silly i1586 boot message.

[H. Peter Anvin]

Dave Jones wrote:
> Trying to boot a 64-bit kernel on a 32bit Pentium 4 gets
> you an amusing message along the lines of.
> "you need an x86-64, but you only have an i1586"
> due to the P4 being family F.  Munge it to be 686.
> 
> Signed-off-by: Dave Jones <davej@redhat.com>

LOL.  Merged.

	-hpa

Re: [X86] Fix up silly i1586 boot message.

[H. Peter Anvin]

Dave Jones wrote:
> Trying to boot a 64-bit kernel on a 32bit Pentium 4 gets
> you an amusing message along the lines of.
> "you need an x86-64, but you only have an i1586"
> due to the P4 being family F.  Munge it to be 686.
> 
> Signed-off-by: Dave Jones <davej@redhat.com>

Merged; however, if you could in the future use x86: instead of [X86] as 
the prefix, it would save us having to edit it manually.

	-hpa

Re: [X86] Fix up silly i1586 boot message.

[Jan Engelhardt]

On Wednesday 2008-05-28 18:57, Dave Jones wrote:

>Trying to boot a 64-bit kernel on a 32bit Pentium 4 gets
>you an amusing message along the lines of.
>"you need an x86-64, but you only have an i1586"
>due to the P4 being family F.  Munge it to be 686.

What is wrong with it? If i386, 486, 586 and 686 are valid names,
why should not 786 (or rather 1586... since someone thought it
would be cool to jump the number^1) be?


[^1 Which also is interesting because the original number had an 80
prepended, i.e. 80286, 80586,... and you'd guess what number 1586
would map to.]

Re: [X86] Fix up silly i1586 boot message.

[Maciej W. Rozycki]

On Wed, 28 May 2008, Jan Engelhardt wrote:

> [^1 Which also is interesting because the original number had an 80
> prepended, i.e. 80286, 80586,... and you'd guess what number 1586
> would map to.]

 Pardon my ignorance -- is there anything special about the number 801586?
It might be fun to display the family in hexadecimal though -- if86 or
80F86. ;)

  Maciej

Re: [X86] Fix up silly i1586 boot message.

[Dave Jones]

On Wed, May 28, 2008 at 07:48:03PM +0200, Jan Engelhardt wrote:
 > 
 > On Wednesday 2008-05-28 18:57, Dave Jones wrote:
 > 
 > >Trying to boot a 64-bit kernel on a 32bit Pentium 4 gets
 > >you an amusing message along the lines of.
 > >"you need an x86-64, but you only have an i1586"
 > >due to the P4 being family F.  Munge it to be 686.
 > 
 > What is wrong with it? If i386, 486, 586 and 686 are valid names,
 > why should not 786 (or rather 1586... since someone thought it
 > would be cool to jump the number^1) be?

When you find the Intel literature that refers to the '786' or the '1586',
feel free to send a patch. In the meantime, we'll refer to it as
the rest of the world does.

	Dave

-- 
http://www.codemonkey.org.uk

Re: [X86] Fix up silly i1586 boot message.

[Jan Engelhardt]

On Wednesday 2008-05-28 19:53, Maciej W. Rozycki wrote:

>On Wed, 28 May 2008, Jan Engelhardt wrote:
>
>> [^1 Which also is interesting because the original number had an 80
>> prepended, i.e. 80286, 80586,... and you'd guess what number 1586
>> would map to.]
>
> Pardon my ignorance -- is there anything special about the number 801586?

801586 or 81586, that is the question. Or 80F86.


>It might be fun to display the family in hexadecimal though -- if86 or
>80F86. ;)
>
>  Maciej
>

Re: [X86] Fix up silly i1586 boot message.

[H. Peter Anvin]

Dave Jones wrote:
> On Wed, May 28, 2008 at 07:48:03PM +0200, Jan Engelhardt wrote:
>  > 
>  > On Wednesday 2008-05-28 18:57, Dave Jones wrote:
>  > 
>  > >Trying to boot a 64-bit kernel on a 32bit Pentium 4 gets
>  > >you an amusing message along the lines of.
>  > >"you need an x86-64, but you only have an i1586"
>  > >due to the P4 being family F.  Munge it to be 686.
>  > 
>  > What is wrong with it? If i386, 486, 586 and 686 are valid names,
>  > why should not 786 (or rather 1586... since someone thought it
>  > would be cool to jump the number^1) be?
> 
> When you find the Intel literature that refers to the '786' or the '1586',
> feel free to send a patch. In the meantime, we'll refer to it as
> the rest of the world does.

Actually, I have seen some Intel literature talking about the 786.  This 
was back when the 486 was new, and they wanted to impress how advanced 
their roadmap was.  Needless to say, it was completely bogus.

	-hpa

Re: [X86] Fix up silly i1586 boot message.

[Maciej W. Rozycki]

On Wed, 28 May 2008, Jan Engelhardt wrote:

> 801586 or 81586, that is the question. Or 80F86.

 Hmm, 801586 should be fine as with Intel 80 used to stand for
microprocessors and 81586 would be confusing as I think 81 was used for
RAM devices (82 stood for peripherals, BTW).  My vote is for 80F86 though,
with "F" standing for "fast" as in the 74 TTL series. ;)

  Maciej

Re: [X86] Fix up silly i1586 boot message.

[H. Peter Anvin]

Maciej W. Rozycki wrote:
> On Wed, 28 May 2008, Jan Engelhardt wrote:
> 
>> 801586 or 81586, that is the question. Or 80F86.
> 
>  Hmm, 801586 should be fine as with Intel 80 used to stand for
> microprocessors and 81586 would be confusing as I think 81 was used for
> RAM devices (82 stood for peripherals, BTW).  My vote is for 80F86 though,
> with "F" standing for "fast" as in the 74 TTL series. ;)
> 

uname reports i686 on these chips.  The rest is ridiculous.

	-hpa

Re: [X86] Fix up silly i1586 boot message.

[Maciej W. Rozycki]

On Wed, 28 May 2008, H. Peter Anvin wrote:

> >  Hmm, 801586 should be fine as with Intel 80 used to stand for
> > microprocessors and 81586 would be confusing as I think 81 was used for
> > RAM devices (82 stood for peripherals, BTW).  My vote is for 80F86 though,
> > with "F" standing for "fast" as in the 74 TTL series. ;)
> > 
> 
> uname reports i686 on these chips.  The rest is ridiculous.

 Intel started it first with picking up a ridiculous number for the family
ID for the P4 line.  There is no technical justification for not keeping
these numbers consecutive.  Or keeping it at 6 actually if the P4 is meant
to be seen by software as the Pentium Pro and the rest of the P6 gang.

  Maciej

Re: [X86] Fix up silly i1586 boot message.

[H. Peter Anvin]

Maciej W. Rozycki wrote:
>> uname reports i686 on these chips.  The rest is ridiculous.
> 
>  Intel started it first with picking up a ridiculous number for the family
> ID for the P4 line.  There is no technical justification for not keeping
> these numbers consecutive.  Or keeping it at 6 actually if the P4 is meant
> to be seen by software as the Pentium Pro and the rest of the P6 gang.

Yes, this is what we eventually ended up doing as causing fewest 
compatibility problems.  For the message in question, it's better to be 
consistent with uname.

	-hpa

Re: [X86] Fix up silly i1586 boot message.

[Jan Engelhardt]

On Thursday 2008-05-29 02:13, H. Peter Anvin wrote:

> Maciej W. Rozycki wrote:
>> > uname reports i686 on these chips.  The rest is ridiculous.
>> 
>> Intel started it first with picking up a ridiculous number for the family
>> ID for the P4 line.  There is no technical justification for not keeping
>> these numbers consecutive.  Or keeping it at 6 actually if the P4 is meant
>> to be seen by software as the Pentium Pro and the rest of the P6 gang.
>
> Yes, this is what we eventually ended up doing as causing fewest compatibility
> problems.  For the message in question, it's better to be consistent with
> uname.

Then again, should not all of the i?86 names be collapsed,
much like there is only "sparc" and "sparc64" for
the actual sparcv7, sparcv8, sparcv9, sparcv9a pseudo-arches
used in, for example rpm, etc.

Re: [X86] Fix up silly i1586 boot message.

[Pavel Machek]

On Thu 2008-05-29 11:35:08, Jan Engelhardt wrote:
> 
> On Thursday 2008-05-29 02:13, H. Peter Anvin wrote:
> 
> > Maciej W. Rozycki wrote:
> >> > uname reports i686 on these chips.  The rest is ridiculous.
> >> 
> >> Intel started it first with picking up a ridiculous number for the family
> >> ID for the P4 line.  There is no technical justification for not keeping
> >> these numbers consecutive.  Or keeping it at 6 actually if the P4 is meant
> >> to be seen by software as the Pentium Pro and the rest of the P6 gang.
> >
> > Yes, this is what we eventually ended up doing as causing fewest compatibility
> > problems.  For the message in question, it's better to be consistent with
> > uname.
> 
> Then again, should not all of the i?86 names be collapsed,
> much like there is only "sparc" and "sparc64" for
> the actual sparcv7, sparcv8, sparcv9, sparcv9a pseudo-arches
> used in, for example rpm, etc.

They should, but it is too late for that now.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

RE: [X86] Fix up silly i1586 boot message.

[Yuhong Bao]

 <Pine.LNX.4.55.0805290102340.29522@cliff.in.clinika.pl>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


> Intel started it first with picking up a ridiculous number for the family
> ID for the P4 line. There is no technical justification for not keeping
> these numbers consecutive.=20
Well=2C the problem was that Intel has assigned family 7 for the original I=
tanium processor=2C back when Intel thought that would replace x86 (the cod=
ename for the original Itanium was P7=2C and the codename for the original =
P4 was P68). And then there was a bug in original NT 4 truncating family ID=
s returned by CPUID to 3 bits. This was not the only bug in the original NT=
 4's CPUID code=2C there was another bug relating to CX8 detection with non=
-Intel/AMD/Cyrix processors forcing the other CPU vendors to provide an opt=
ion to mask this bit=2C which caused trouble for MS itself later on when th=
ey decide they would begin to require CX8 in XP=2C and it ignores CPUID if =
max standard CPUID level is greater than 3=2C forcing Intel to again add a =
workaround into their Prescott and later processors.
Geoff Chappell wrote articles describing these problems in NT 4:
http://geoffchappell.com/viewer.htm?doc=3Dstudies/windows/km/cpu/index.htm
http://geoffchappell.com/viewer.htm?doc=3Dstudies/windows/km/cpu/cx8.htm

Yuhong Bao
 		 	   		 =20
_________________________________________________________________
Windows 7: It helps you do more. Explore Windows 7.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=3DPID24727::T:=
WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen3:102009=

RE: [X86] Fix up silly i1586 boot message.

[Yuhong Bao]

 <Pine.LNX.4.55.0805290102340.29522@cliff.in.clinika.pl>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0



> Intel started it first with picking up a ridiculous number for the family
> ID for the P4 line. There is no technical justification for not keeping
> these numbers consecutive. Or keeping it at 6 actually if the P4 is meant
> to be seen by software as the Pentium Pro and the rest of the P6 gang.

Then Mooly Eden started the Pentium M project.
They decided to base Pentium M on the P6 microarchitecture.
Thus=2C the Pentium M was family 6=2C model 9=2C which was the same as orig=
inally used by the cancelled Timna project=2C led by the same Mooly Eden.
As it happened=2C Prescott turned out to have high heat output and power co=
nsumption=2C and as a result=2C Tejas was cancelled=2C and the NetBurst arc=
hitecture was abandoned and along with it the family 15.
The Pentium M project came to the rescue and made the Pentium M core better=
. By Core 2 Duo=2C the core had gained x86-64 support and thus was ready to=
 replace NetBurst on the desktop and server. It was family 6 model 15=2C wh=
ich confused Solaris 64-bit that thought all x86-64 CPUs was family 15. Sin=
ce they ran out of the 4-bit in the model=2C they then had to begin using t=
he extended model field=2C 45nm Core 2 processors was extended model 1. Add=
ing 15 and 1 yielded 16.
In the meantime=2C AMD came out with it's first x86-64 processor called the=
 K8=2C which copied the family 15 used by the P4 processor. Because similar=
 things had not happened at AMD=2C AMD was forced to begin using the extend=
ed family with the K10=2C which was extended family 1. Adding 15 and 1 yiel=
ded 16=2C or family 10h=2C which was what it was often called by AMD.

Yuhong Bao
 		 	   		 =20
_________________________________________________________________
Windows 7: I wanted more reliable=2C now it's more reliable. Wow!
http://microsoft.com/windows/windows-7/default-ga.aspx?h=3Dmyidea?ocid=3DPI=
D24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_myidea:102009=

RE: [X86] Fix up silly i1586 boot message.

[Jan Engelhardt]

On Wednesday 2009-10-28 04:08, Yuhong Bao wrote:
> <Pine.LNX.4.55.0805290102340.29522@cliff.in.clinika.pl>
>
>> Intel started it first with picking up a ridiculous number for the family
>> ID for the P4 line. There is no technical justification for not keeping
>> these numbers consecutive.

Once one knows that there are 4 bits for the family field, 15 is not
such a strange value - it is the last value, one could take it as
"reserved, and look elsewhere".

>[...] Intel has assigned family 7 for the original Itanium processor
>[...] there was a bug in original NT 4 truncating family IDs
>returned by CPUID [...]

That would explain why Intel still shows an oldfashioned family=6 on
many contemporary processors (e.g. core i7). BUT, AMD64 processors
have family=15 "almost throughout", and so seem to have at least some
Intel models. So that tells us that either NT4 works, or nobody uses
NT4 on fam15s.

RE: [X86] Fix up silly i1586 boot message.

[Yuhong Bao]

 <alpine.LSU.2.00.0910280914590.28170@obet.zrqbmnf.qr>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


> On Wednesday 2009-10-28 04:08=2C Yuhong Bao wrote:
>>=20
>>
>>> Intel started it first with picking up a ridiculous number for the fami=
ly
>>> ID for the P4 line. There is no technical justification for not keeping
>>> these numbers consecutive.
>
> Once one knows that there are 4 bits for the family field=2C 15 is not
> such a strange value - it is the last value=2C one could take it as
> "reserved=2C and look elsewhere".
Indeed=2C as I said=2C AMD began to use the extended family field with the =
K10.
>>[...] Intel has assigned family 7 for the original Itanium processor
>>[...] there was a bug in original NT 4 truncating family IDs
>>returned by CPUID [...]
>
> That would explain why Intel still shows an oldfashioned family=3D6 on
> many contemporary processors (e.g. core i7). BUT=2C AMD64 processors
> have family=3D15 "almost throughout"=2C and so seem to have at least some
> Intel models.=A0See my second mailing post message for why.
> So that tells us that either NT4 works=2C or nobody uses
> NT4 on fam15s.Family 15 truncated to 3 bits is family 7=2C which do work =
with NT 4=2C while family 8 truncated to 3 bits is family 0.
Yuhong bao 		 	   		 =20
_________________________________________________________________
Windows 7: Simplify your PC. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=3DPID24727::T:=
WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen1:102009=

Re: [X86] Fix up silly i1586 boot message.

[Dave Jones]

On Wed, Oct 28, 2009 at 09:30:33AM +0100, Jan Engelhardt wrote:
 
 > So that tells us that either NT4 works, or nobody uses
 > NT4 on fam15s.

Or that no-one cares.

I don't know why this year and half old thread was resurrected,
but can we all do our bit for lkml traffic reduction and let it die?
(or at least drop me from the cc. The bug was fixed May 2008,
 there's no reason afaics for endless bibble filling everyones inbox).

	Dave

RE: [X86] Fix up silly i1586 boot message.

[Yuhong Bao]

 <20091028154650.GA13660@redhat.com>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0



>> So that tells us that either NT4 works=2C or nobody uses
>> NT4 on fam15s.
>
> Or that no-one cares.
NT 4 do work on fam15s=2C because 15 truncated to 3 bits is 7=2C while 8 tr=
uncated to 3 bits is 0.
> I don't know why this year and half old thread was resurrected=2C
> but can we all do our bit for lkml traffic reduction and let it die?
> (or at least drop me from the cc. The bug was fixed May 2008=2C
> there's no reason afaics for endless bibble filling everyones inbox).
=A0I know that this bug is now fixed=2C but=A0I wanted to provide more deta=
il on the history behind this.
Yuhong Bao 		 	   		 =20
_________________________________________________________________
Windows 7: Simplify your PC. Learn more.
http://www.microsoft.com/Windows/windows-7/default.aspx?ocid=3DPID24727::T:=
WLMTAGL:ON:WL:en-US:WWL_WIN_evergreen1:102009=