Slashdot Mirror
Most Linux Distros Won't Run on Pentium 4
linugen writes "According to this article on LinuxGram, the majority of Linux distributions won't install on the Pentium 4. Apparently this is caused by the CPUID database, which contains no information on the Pentium IV. Currently only Red Hat and Turbolinux have updated versions of the CPUID databases."
No, but they should do some due diligence to make sure that new systems will work with existing OSes. At keast if they want to claim that the CPU is backwards-compatbile with x86.
Software sucks. Open Source sucks less.
The P4 is *NOT* that bad. It's main problem is that it performs poorly with existing software. Software that is recompiled with a P4 aware compiler to avoid P4 bottlenecks (not necessarily optimized for a P4 even) gains much.
This will be a trend we continue to see. People clung to their socket 7 motherboards for years after the PII technology came out, then what happened? AMD followed Intel's lead and went to Socket A.
Existing pipeline technology will hit a brick wall eventually, and everyone will have to upgrade to CPU's which make today's software perform poorly.
If you need web hosting, you could do worse than here
--
Why couldn't it optionally enable features specific to a detected chip, starting with 386 as default?
Each generation of Intel processors has included complete set of bugs: Listing of x86 bugs
These bugs can do anything from giving a spreadsheet incorrect results to allowing user-level programs to do things they shouldn't. The Linux Kernel fixes these hardware bugs with software, but the kernel must know which chip is present in order to apply the correct fixes.
Would you rather have the kernel tell you on startup that something is wrong or randomly crash later?
Why not have it just fall back to a more compatible mode as has been stated but with a warning? An error message stating things are going to be run in a compatability mode. Press any key to continue kind of thing.
yvan eht nioj
As people are so quick to point out, Distro X is not Linux.
Seeing as how it works on two distros, I think its fairly safe to say that the CPU does work fine.
Did the other distro makers contact them and ask for the Information? Its not hard to notice the P4 coming out, unless you've had your ears plugged, under a rock, in a cave, on Mars.
If say Caldera asked for the Info and was turned down by Intel (who then turned around and gave it to Redhat), then maybe there would be a story here.
There is nothing that says any of that happened. It seems more like the people who have updated are just more on the ball.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
Intel is working with Linux ISV's to update their CPUID databases.
CPUID databases, what the heck is that? There's no such thing. And Intel doesn't have to "work with the ISV's" to fix anything, Alan Cox has fixed this proc cpuid reporting problem a long time ago (in 2.2.18pre20), so P4 owners only need to download 2.2.18 which should be out any day now (pre25 which is out is supposed to be the final version).
Depends on how you propose to fix the problem. ...
How about if it works, say, the way NT works??? It doesn't seem to have this problem.
But if Intel knew a year ago what changes would need to be made to the cpuid list, and didn't tell kernel developers well in advance of product release, it's their own fault.
Kernel developers didn't know that Intel was going to use a different CPUID for a new processor? Come on.
The Kernel should just plain not be this brittle.
--
Sometimes it's best to just let stupid people be stupid.
Ohh come on... Something like: "Linux will never run on a P4" would be news worthy...
Just browsing the 2.2.18 kernel changes log and came accross this: 2.2.18pre20 o Report PIV in proc as family 15 and uname as model 6 as discussed Check it out here
Joshua
Terradot
When in danger or in doubt, run in circles, scream and shout!
The installer of specific Linux distributions fails. The kernel really doesn't mind.
Linux won't install on those systems - not "won't run" as stated in the title.
Linux != Red Hat
Package Management != RPM
Slackware runs just fine ;-)
'nuff said
Okay... I'll do the stupid things first, then you shy people follow.
Okay... I'll do the stupid things first, then you shy people follow.
[Zappa]
Come on it's just an ID entry in the CPUID database how hard can it be to fix?
The death of one man is a tragedy; the death of a million is a statistic --Joseph Stalin
Isn't the /proc filesystem created by the kernel? AFAIK, /proc/cpuinfo deals with this, not any distro-specific database...
Ceci n'est pas un sig
Microsoft probably has had a Pentium-IV test box for ages. Months at least. Intel probably gave it to them.
If there was a Windows problem with the P4s that was this obvious it would have been fixed before the P4s hit the market.
I hate to say it but this is not a win for Open Source advocacy.
-Andy
Problem is - until AMD comes out with new cores (Q2 2001 I think), there won't be faster Athlon coming out. Those 1.2 Ghz Athlons are probably the real cause to global warming... and I've seen plenty of fried one coming back at dealers.
Falling back to an i386 without FPU should work, all the time. CPU-specific informations (e.g. MTRR) are for optimizations only. If the cpuid database does not match the CPU, it is the kernel's best interest behave like an ad hoc i386 kernel - working slowly is better than not working at all.
What if the CPU is not x86? Then it is highly unlikely that the kernel even runs to that point thus far. Not impossible, but almost - like changing a few random bytes of a file and still getting the same MD5 checksum.
The problem is that the kernel on the boot disk has to be able to run on the system. You can't compile a kernel if you can't get the distribution's boot disk to run on the system. The distributions will have to come out with new boot disks. (Although I did see a possible work-around that you can just type at the Linux boot prompt.)
Software sucks. Open Source sucks less.
Whether this is good or bad depends on how you want your OS to work. Personally (and I will readily agree I'm probably in the minority) I want my OS to stop when it sees something it doesn't recognise happening in the hardware. I do not want it to just muddle on and hope for the best.
Remember that a broken CPU could also be a CPU that linux "doesnt understand." If you just carry on as usual if you don't know what CPU you are on and it's broken you have a much greater chance of doing damage than if you stop there and then.
But like I said, I'm probably in the minority and I think linux does the Right Thing, which is one reason why I use it. The majority probably think windows does the right thing, which is presumably why they use it. Good look to them.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
This new processor has all new SSE-4 for the ultimate gaming experience, you'll be able to finish your important assignments at work in record time, in short, it HAULS!
<fine print>Pentium VI speeds are achieved via a 75x multiplier. New Celeron III processor speeds are achieved via a multiplier in excess of 100x. And no, we still haven't increased the FSB from 66MHz, and no you can't have any more cache, that would cost too much for us to make and sell at a decent price. </fineprint>
Yes but do you have to really have that even? The ideal answer would be yes. But I don't think you'd need it to be perfectly identical either. You can just deal with the problems later. People freak out and act like this is a real serious problem (yeah, it is a problem, but nothing to panic about...) when it just isn't!
Gorkman
Its not a matter of the kernel being brittle. Its a matter of kernel developers ensuring your privacy is safeguarded from Intels poorly thought out CPUID feature.
Now that the world has shown its disdain for the CPUID feature [of which this act was a part] , and Intel has abandoned it, Linux kernels need to be updated slightly do they don't bother to imlement this feature [which NT, 2K, 9x, or Solaris never had] on new CPUs.
That sounds like a good idea (might be nice to print a warning as well). That way you can boot and make a new kernel that knows about the new CPU as long as the CPU maker has done their job and it works like the a 386! If you can't even boot, then you can't fix the problem unless you have a whole other computer, and the ability to make boot media for the first machine on it (which can be a pain if you are installing on something like a laptop that can have *either* a CD or a floppy....).
I admit Intel was (once again) lame. However lameness on their part does not excuse lameness on Linuxes part.
Why do they have to dictate anything? Why not just put in on thier web page?
Yup, had same problem with Duron 700 and RH 6.2. -ted
"The rest of the Linux herd won't run on the hardware."
Hey,
This article sounds SUSPICIOULSY biased. First it calls for panic. Hey not everyone rides an installation setup prog... For example, I always install everything by hand. Second it turns blame over some oversuspicious database updating Intel should do, sounding as if this was some sort Herculean effort. Then it speaks about "Intel investment SuSE" as if Intel disregards something of its own (why to look at this second-rate OS?).
Also it is interesting to note that it says that:
"Chen says that he's been in contact with SuSE, Caldera and Debian and "we have told all of them about the issue and they're aware." However none of them has given him a schedule for releasing a new CPUID."
As if the Linux "herd" didn't give a bunch about the matter.
Meanwhile. We have something like 80 distros. NO DISTRO works? NONE of them? Even over-conservative Slackware?
Why couldn't it optionally enable features specific to a detected chip, starting with 386 as default?
This is just as bad as a BIOS that halts on any error. That's the kind of thing that makes remote server rebooting extremely dangerous. The system should be designed to work at all cost, and send errors to syslog if there is any reason for concern.
No, a BIOS that halts on any error is highly desirable for any production machine that deals with sensitive transactions. If there is an error on that type of machine, you WANT a halt. You don't want a system with a BIOS fault that'll hobble along corrupting the data set!
Turning off "Halt On Error" is a great option in BIOSes that support it for hobbyists and non-critical remote systems as you describe, but to the degree that a BIOS can have a default, it should ALWAYS default to halt on error, even during failure of the BIOS itself.
Well, if not done right, it can be pretty fatal to the boot process :-( if not to the user :-).
It's not as if this is the only thing that occasionally requires some upgraded tools; I did a Linux install on the weekend on an Athlon 600 box where I am still fighting with fdisk to get it to properly recognize the 40MB UDMA IDE hard drive. Apparently UDMA doesn't agree all that well with many of the distributions.
I tried out what I had around with pretty mixed results:
I'm still looking for a better answer; I suspect fiddling with LILO parameters should clear things up so I can finish partitioning the disk and transfer FSes over to ReiserFS.
The really relevant point here is that the distributions from about a year ago were quite completely unable to cope with the new hard drive. It should be no great surprise when new classes of hardware cause some breakage.
A year from now, we'll probably all need to do some upgrading to cope with the new USB and Serial ATA hardware that is likely to be available; install disks from 1999 will be so much shrapnel as far as some of the "new-for-2002" hardware is concerned.
This is why there actually is something of a business model for those that sell Linux distributions... :-)
If you're not part of the solution, you're part of the precipitate.
It must be a slow news day :-)
Thanks
Bruce
Bruce Perens.
Pentium 4's aren't even SMP capable yet. If what you're saying is true, then no one should have no problems.
I installed Mandrake 7.1 on a 1Ghz P4 back in August or so. Installation worked fine, as well as everything else. The only thing I've noticed was how linux_logo package that comes with Mandrake couldn't figure out what cpu we were running. When the machine first boots, it'll say that I'm running a P3, and then when I login and logout, it'll say I'm running Athlon. It couldn't get the cpu clock right either. One login, it would say 700Mhz, 300Mhz on the next login. Amused me for about 20 seconds and then I moved on.
For the "peanut gallery," yes, that should have been 40GB.
If you're not part of the solution, you're part of the precipitate.
... the existing three Pentium 4 owners about this?
The P4, at this stage, is a white elephant, particularly for Win* apps:
Locked into pricey RDRAM, which may or may note be available in the future
Highly unattractive, speedwise, because Joe and Jane Consumer won't even know to get a P4 version of all the software they've already bought
Priced high, AMD just slashed Athlon prices, which brings a 1.2 GHz cpu to your desk for $254 (1.3GHz P4 ~300)
However, and more to the point of the article, these only partially interest Linuxii, as the compiler for your kernal build is either going to know how best to take advantage of P4 & RDRAM or it won't. As long as you have the sources to all your software, you should be able to recompile to take better advantage of what the P4 has to offer.
--
A feeling of having made the same mistake before: Deja Foobar
Yeah, the installer may not run, (have to have someway for the distro to pick the right kernel), but big deal! Just use another machine to run the install on with similar equipment (everything except motherboard and CPU from your new P4 installed in a new PII or PIII system). Once installed, put the HD back into the P4 system and your running Linux on the P4. I know there WAS a SMP bug or something in that AC fixed, but AFAIK, it is fixed in later releases(2.2.18), and the P4 has no SMP systems just yet. The article should be updated to indicate that it's the installer that will choke, and not Linux in general.
Gorkman
I misread the CPUID supplement. The family is, indeed, 15 (all ones).
I guess I don't know the assumptions that Linux makes. Intel's usage guidelines caution that you should "not assume that a given family ... has any specific feature. For example, do not assume the family 5 value (Pentium processor) means there is a floating-point unit on-chip. Use the feature flags for this determination."
I find it interesting how the article sounds like its blaming Intel for the problem of Linux distros not being properly updated yet to support the P4. I guess that means its Intel's job to run around all over the world making sure that these things are updated before they dare to release a new cpu.
Yeesh.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
Unfortunatly the article here seems to indicate that there's a problem with the Linux kernel itself, when instead the problem is with some of Redhat's user-space installation tools. I've personally not used Redhat since version 4.x - so have no experience of their software, but I do know for a fact that there is nothing in the linux kernel itself that prevents it from not working on a Pentium IV. Granted it may not work as well as possible until the proper tweaks are added, but it will work.
Could we please have accurate articles? You are starting to look like Linux Format, which is an utterly dreadful UK magazine famed for clueless reporting.
When an RPM based system goes to install, it needs to know what arch type to use (i386, sparc, etc) and it doesn't have the CPUID for the Pentium 4 lined up as "i386 compatible" so it basically throws it's hands up, and says "I can't find any packages to install, I give!" Although slightly improper, if Redhat had included a catchall, like "if you don't know what it is, try i386" then things would have been fine.
As it is, 7.0 just masks the cpuid in the kernel to lie and say "686", which I consider a fix at the wrong end of the pipe. They should have fixed the kernel to report the CPUID properly (it's "f86" but everyone thought x would be base10 not hex, so they all parse it wrong and give "?86") and patch the RPM arch database to match the real Pentium 4 CPUID to an i386 compatible install.
My opinions are not those of my employer. Made fresh daily!
It seems to me that the Linux shouldn't just fail if it doesn't understand a CPUID. Is there some reason it can't fall back to a "compatibility mode" (like, 486 or Pentium mode or something) so that it at least works? Maybe it won't run optimally, but a little warning message is better than a full-blown barf.
--
Sometimes it's best to just let stupid people be stupid.
Sounds like more than Intel dropped the ball.
What were they thinking? "Hey, let's design a failure mode into the kernel!"
Why couldn't it optionally enable features specific to a detected chip, starting with 386
as default?
This is just as bad as a BIOS that halts on any error. That's the kind of thing that makes remote server rebooting extremely dangerous. The system should be designed to work at all cost, and send errors to syslog if there is any reason for concern.
The CPUID instruction returns three important values: family, model, and stepping. The Pentiums comprise family 5. The Pentium Pro, II, and III comprise family 6. The Pentium 4, apparently, introduces family 8. The family number increases, and processors are backwards compatible (right?). So why not fall back to the most recent family?
I'm getting this information from AP-485 Intel Processor Identification and CPUID Instruction and Intel Pentium 4 Processor Identification and the CPUID Instruction.
I'll just wait a couple months then get something nice and safe and out of date. ;)
--
A feeling of having made the same mistake before: Deja Foobar
There is a quick and easy way of fixing this. Most Distro's that aren't based on a brand-spankin new kernel (most) will fail to install any RPM's because RPM checks the CPU-ID first. You will have to re-compile either the kernel on your install media or RPM to auto-select 0x686. (It goes into compatability mode - 0x?86)
If you want to modify your Kernel, you can add a quick IF statement in the setup.c code to detect if the CPUID is a P4, then just set it back to a 0x686. You obviously won't get optimized code for a P4, but it works to install RPMS, and who cares because there is no optimized code yet anyway. (Atleast that i know of)
You can also mess with your RPM code to auto-set the package type, but I prefer the above. Cheers
I'm guessing you don't know what a CPUID is. It is the identifier for a specific processor family. It is the one thing that CAN'T be backward compatible.
Someone suggested that the kernel should "fall back" and assume it is an i386 if it can't determine the CPU type. At least you can get the red-flag warning and still be able to boot / install and get your update somehow rather than just totally failing.
Always being backward compatible to everything ia32 is part of Linus' mantra that I remember, he eschewed support for 16 and 32 processor machines to maintain support for the 386 systems.
Personally I'd love to see if DOS runs on a P4.
I work for one of the non-P4 installable distros, and with ours at least, the problem lies with RPM itself. The installer works, it's just that we're using an older version of RPM (3.0). If you notice, RedHat and Turbo use 4.0, which doesn't have the problem. It's a simple fix, at least with ours you can switch to a virtual console, manually update the CPUID database and then continue. Not the best solution, but it works for now until we release a new version. Should realistically work for any distro that way.
Not exactly. At the same clock speed, running 286 code, it was about the same (even a bit slower). :-)
It was the 32 bit instructions that made it roar.
And of course, the fact that it ran at much higher clock speeds.
I this for a fact, I used to tweak 3D rendering code in assembler at that time and every clock tick counted... good old times
If con is the opposite of pro, is Congress the opposite of progress?
I know what a CPUID is. In fact, I looked at the kernel code that pertains to the CPUID before I posted. There isn't much there. It just turns some features off and on depending upon the CPU. And CPUID is in fact somewhat backwards-compatible: the feature bits for the Penitum still apply to the Pentium III.
Software sucks. Open Source sucks less.
According to c't (german magazine), the problem is just with SMP-Kernels, that have problems to identify the IO-APIC to know the number of CPUs.
Quickfix: Boot with kernel parameter "noapic".
or get a new install disk. (SuSE: ftp://ftp.suse.com/pub/suse/i386/update/7.0/kernel /pentium4/)
--
The article makes it sound like there is this big database (like the size of the Windows registry or something). In reality, there is just some code that makes some comparisons of a few numbers to determine the capabilities of a given CPU. Unfortunately, the kernel doesn't know about the Pentium IV yet.
Software sucks. Open Source sucks less.
You don't have to make the CPUID identical to the predecessor (duh!), just predicatable. That was one of the big problems. The ID numbers were previously sequential, but Intel decided that it would be cool to skip to 15 for this CPU. I guess 4=IV=15 in Roman-numeral coded decimal.
Some of the other problems were actaully due to the chipset, not the CPU.
Software sucks. Open Source sucks less.
The kernel won't work if it can't work out the CPUID, _only_ if it was compiled for something above a 486, since most 486's had no CPUID, they used other methods.
So, it isn't bad kernel design, it's bad distribution design, my guess is that debian will work, and some others should too, as long as the kernel was compiled for a 386, with a math-co emulator.
VK3TST
-- "People aren't stupid. Usually." -- jd
This sounds like the problem I had with my Athlon 900MHz when I first got it. I had to tell Lilo to disable it and then it worked fine.
Werd.
Informative? Am I missing something here?
A deep unwavering belief is a sure sign you're missing something...
However, although this is disconcerting, I wouldn't blame this one on the kernel hackers - it could be argued that whoever compiled it should have turned it off. However, I blame this on the major chip vendors. If they help the linux community by releasing specs and information about chips ahead of release there is a better chance this kind of thing can be avoided (I notice the 2.4.0tests have P4 support in them...).
Moreover, why can't they do a quick test on Linux before shipping? I bet they don't ship a single chip before throughly testing it on M$'s OSes...
Yes, I have identical systems just lying around my secret lab. I buy 'em in bulk for occasions such as these.
Get real.
A deep unwavering belief is a sure sign you're missing something...
The article says that Intel is working with Linux ISV's to update their CPUID databases. Seems like they're doing the right thing. Is Intel really responsible to contact EVERY OS manufacturer for x86 and let them know that they are releasing a new CPU? I suppose that this is not a popular opinion on Slashdot, but maybe Intel does do some things right...
Actually, most users wouldn't want Linux or a Pentium 4.
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
Oh...the kernel has to be updated to do this automatically or you have to do it yourself by hand???
I bet half the ppl that bitch about this are the same ones that bitch about all the hotfixes and Service Packs that M$ puts out.
---"What did I say that sounded like 'Tell me about your day?'"---