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;
}
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.]
--
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
--
--
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
--
uname reports i686 on these chips. The rest is ridiculous.
-hpa
--
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
--
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
--
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
--
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
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
--
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
--
LOL. Merged.
-hpa
--
| Alan Cox | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 004/196] Chinese: add translation of SubmittingPatches |
| Bart Van Assche | Re: Integration of SCST in the mainstream Linux kernel |
| Andrew Morton | Re: [RFC/PATCH] Documentation of kernel messages |
git: | |
| Winkler, Tomas | RE: iwlwifi: fix build bug in "iwlwifi: fix LED stall" |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Mark Lord | Re: [BUG] New Kernel Bugs |
