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."
You make a good point, but my question is: how did RedHat and TurboLinux -- arguably the most commercial of distros -- just *happen* to be the only ones who managed to get this info? And that's not a preanswered question... I would like to know how this kind of info typically gets disseminated, whether this was just bad planning on the other distros' parts, etc.
But the Rambus thing... sheesh. That alone is enough to make me question whether Intel has one tiny clue.
A hen is only an egg's way of making another egg. -- Samuel Butler
Moderator are on crack. (Score:0, Offtopic)
by Rares Marian (rmarian@winblowsstart.com) on 11:35 AM December 11th, 2000 EST (#14)
(User #83629 Info)
That's a perfectly good comment.
Caught signal SIGSIG read this comment again.
The message on the other side of this sig is false.
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
Having read all the comments so far, it seems that the issue is INsignificant, has already been fixed, and warrants no further reporting. It doesn't even merit a headline anymore, as existing P4 users and linux hackers alike have agreed that most things don't check CPUID for functionality anyway, only for optimization.
The fact is that the article was unnecessary. It seems to be a plea to rectify the "unfairness" of the Linux community for not embracing Intel's new chip with proper fervor. BIG DEAL!! Intel has an inflated ego brimming with self-importance. Did you ever stop to think that if only "users", market ANALysts and Intel loves Intel when most Slashdot readers could care less, maybe there's not all that much to get excited about.
The fact of the matter is that Linux is a kernel and it does work on the P4. What supposedly doesn't, are some of the distributions. By definition, "Linux" can't look bad because the kernel works.
You can tell a college man, but you can't tell him much.
This is more of a question. Does unix operating systems like netbsd and such work on the new PIV or have there been any tests. Cause that is inportanat for me because I run that on my newer freebsd box and want to know if I should get athlon or a PIV.
--
Okay, I can very much see where you're coming from, but the difference, even when you consider the fact that most users don't install their OSes, linux is still a hell of a lot harder to get running, and linux apps are a hell of a lot harder to get installed than windoze and windoze apps. Not that it is impossible of course! Certainly I'm a linux newbie, but I'm making the effort, but forget not that it is indeed an effort. I'm not a fan of windoze, but I can admit that it is a hell of a lot more intuative than linux.
Joshua
Terradot
When in danger or in doubt, run in circles, scream and shout!
At this point I am still more comfortable with Solaris than linux and I agree with the poster above, there is a steep learning curve here. Of course if I had used linux at work instead of Solaris then it would probably be reversed but I would still say a Win install is tons easier....
From what I hear the P4 ain't so great so I don't know what the big deal with this story is....
Hey, you think your house is cool?
By those definitions, since the Linux kernel doesn't run on 6502 CPUs (by my knowledge anyway), it must be brittle. Man, that's harsh.
GPL made simple: What was my stuff is now our stuff. If you improve our stuff, please keep it our stuff.
That's indeed very true, and I hear it all the time from people here on /. as well as other sites. You know what though... I don't mind. I think it's fine that Taco and gang post what interests them, as I think many of my interests mirror theirs, which is why I'm drawn here to slashdot.
The most important thing though, is that you are totally free to post any viewpoint that you want, and people are free to read it, mod it up, or mod it down depending on how they personally feel. Taco and crew don't do the moderating, we do! (actually, I haven't moderated yet, but that's beside the point, cause in theory it's us). Nothing is stopping people from making pro-M$ comments and pro-Intel comments... that's just not the sort we've ended up with here.
Joshua
Terradot
When in danger or in doubt, run in circles, scream and shout!
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?
That's exactly what all those "other OSes" do. Seems that someone forgot the old "be liberal in what you accept" maxim...
Since they are: 1.Intel QA using Win2000 2. The guy at TomsHardware playing Quake on Win98 3. The R&D guy at Rambus using NT I don't think they've been informed.....
Hey, you think your house is cool?
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
Thats funny as hell, I loaded Slackware 7.1 on a P4 day b4 yesterday, and it works fine.
Who is the idiot who made this article?
M$ stock dropped in 1/2 since last year. If you are a MCSE, you will be broke.
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...
Maybe Intel needs to do a better job of getting cpu information and test setups out to software developers, more than just two or three big ones?
Given the rapid development time of the open source community, Intel shouldn't have a problem getting support out there by the time chips reach production.
I have a quad board fully populated with P4's and it works great on my tomsrtbt distro. Pretty fast too, I might add! Except booting from the floppy is still kinda slow. I dunno what u d00ds are talking about?
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]
remember moto did the same thing on a 68000 part. It was a 32 bit part with a 8 bit bus!
Actually, the 68000 had a 32 bit internal bus and a 16 bit external bus. The 68008 (which came out later) had an 8 bit external bus.
--
Sometimes it's best to just let stupid people be stupid.
Most distro will come out with a patch that solves this problem. Or someone has to pay $1.99 to get a up to date linux cd. Big deal
Troll? WTF... I'm not even running linux right now, and I get moderation-flamed for quite justifiably lauding the benefits of an open-source based business. The one time I decide to post (usually I just stick to posting stories) and I get marked a troll... I thought the definition of troll was one who posts solely to either incite annoyance or for the sake of posting? Whatever...
Because Intel puts out a new CPU that behaves differently given the same set of instructions, thus causing a failure in the Linux kernel, the Linux kernel is brittle?
No, the CPU is fine, it's the Kernel that's broken. The CPU operates exactly the same with the same set of instructions. The Kernel is just bombing because it doesn't like the CPU ID.
--
Sometimes it's best to just let stupid people be stupid.
One small problem with this.
Turbo Linux, which is not funded by Intel, also works just fine with the P4. I'm not shure if either will work with the P6 though.
Minne-snow-da: Winter is comming...
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
Floppy disk controller not responding is probably not a real big problem on a web server, for example. You both make good points, it should be a user switchable option.
Just because it CAN be done, doesn't mean it should!
If any distribution has a solution, then don't all distributions have access to that same solution?
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
Dont most installs come compiled for a i386 Generic? I mean one that will run on a K5/i386/Cyrix or whatever?
Even most of the default precompiled kernels like in the slack install are like this.
Sounds Like FUD
Free Unix? Free Windows. http://www.reactos.com
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.
Maybe they *asked*?
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.
Yes... just a hack job of an article. True, Intel could have contacted more Distros and provided the necessary CPUID information before had but... it is interesting that more developers who have been seeded P4 systems didn't catch this before hand. All in all.. it's a good lesson. In the future Intel will take measures to make sure that the info is distributed in a timely fashion and I suspect more of the Distros will request info earlier as well. Hey.. it's a win-win. Lesson learned..find a problem and fix it so it does't happen again.
"The distributions will have to come out with new boot disks."
It's not like you're scaling Everest.
The message on the other side of this sig is false.
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
Intel has QA people? ;)
Just because it CAN be done, doesn't mean it should!
Slackware installs just fine on a Pentium 4. What the hell is a CPUID database ?
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
Repeat after me:
READ THE FUCKING ARTICLE
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?
You just can't get the moderator's these days, when I was a lad...
UNIX? They're not even circumcised! Savages!
If the same problem cropped up on a new AMD cpu, do you think the article would be blaming AMD for it?
I just want to recall that the same thing HAS in fact happened with a new AMD cpu!
I still remember when I've not been able to install SuSE 6.4 on my brand new Athlon because of a stupid SMP optimization in that distro's default kernel.
Quick disclaimer. I like Linux. I heartily endorse open source software and developers.
That said, just the title of the previous post illustrates why Linux isn't ready for the general public. I try to imagine talking my grandfather through the process. You might as well tell him to build his own car from parts as tell him to build his own kernel. I can only imagine the trouble calls:
"Ok, Sir. Here's what you've got to do. Can you boot in single user mode?"
"What's a mode? Oh shit...."
Once again, I would remind the moderating public that not every post that questions the preeminence of Linux is a Troll.
Welcome to the adhoc, seat of the pants world of Linux kernel design.
I think that the only reason that TurboLinux supports the Pentium 4 is because TurboLinux is based on RedHat.
I could be totally wrong.
( And another thing, the reason the movie industry uses roman numerals for movie copyright dates is to obfuscate when the movie was actually created. Is Intel doing the same thing? )
aÍÍ©ÍÌÍ£Ì'̽ͩÌÍzÍYÌÍÌY
..and here I was going to rush out and spend oodles of $$ to buy one along with some of that stellar RAMBUS ram so that I can surf the web faster since it's suppose to handle media sooo much better than my P3...right? ;) Personally, I can wait for the dual Athlon boards.
"Klaatu, verada, necktie!" -Ash
Any OS vendor that will sign the NDA gets equal access to advance CPU information. Many open source developers (rightly, IMHO) avoid signing the NDA's because of IP contamination issues. As a devloper, you have to make choices around advance information.
As the one time (and a blessedly *short* time it was) code owner for the offical CPU identification code published in the Intel ap note, all I can say is: It ain't that hard! And CPUID information is public pretty early, before any production parts are shipping.
Disclaimer: Not speaking for Intel, etc, etc.
Intel seems to speculate that Linux users are apt to purchase the P4 as soon as it hits the shelves. This is, most likely, not the case and certainly not news worthy. Linux users, and especially *nix users, are likely to review a hardware compatibility list before they throw down for a new piece of hardware.
IMHO, it is typical of Intel to place excessive value on their rollouts and generate hype at any opportunity. Their opinion of the importance of their own products is far more lofty than the reality of it.
You can tell a college man, but you can't tell him much.
Yup, had same problem with Duron 700 and RH 6.2. -ted
Woa, I've got a plus-one bonus! Where did that come from?
of course, it would be nice if they had an automated compilation, but as it is, i like my system better than redhat.
And, they are working on automating it, but that part isn't even alpha-level yet. Right now it's just an LDP book.
tiamat
67.5% Slashdot Pure I guess I need to work on that....
That Linux is awesome, right? We also know that Pentium 4's are not really that great, so why put a good OS (Linux distros) on a shitty processor(Pent 4)? Think for a minute... That is what I thought.
Read the article moron.
Use a pIV to begin with? AMD
I actually did this twice responding to this article alone.
Note To Intel: We use Arabic numerals, thanks. Next thing you know, they'll be talking about moving from LXIV-bit chips to CXXVIII-bit chips.
Check your Roman numerals so you don't look like an idiot (or me, for that matter).
aÍÍ©ÍÌÍ£Ì'̽ͩÌÍzÍYÌÍÌY
"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?
And people want Linux to replace Minix as the case study in undergraduate OS classes?
Did you seem to miss the fact that this seems to be a problem with the distro, and not the chip? While i'll agree that the P4 isn't all its cracked up to be, you should blame those really at fault; the linux vendors who's programs crash when they encounter something they don't expect.
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.
Don't be an idiot.. it's unbecoming and makes your mutha look bad for raising such a beast. We're talking CPUID information here.. it''s NOTHING. Sign up as a devloper at developer.intel.com and that's all it takes... You can also download the standard Manuals from any of the "Manual" links on any processor page and get much the same info.
P.S. Don't be so sure that Intel and Microsoft are "buddy-buddy"...
- The article claims that RedHat has the updated CPUID database, but how recently was that packaged with the CD? Is it in RedHat 7.0 only, or did it come with the "Pinstripe" beta as well?
- RedHat is the distribution that most other distros are based on (Trustix, TurboLinux, Mandrake). Will these distributions have issues with the Pentium VI?
- Where can I go to get information on a real fix for this issue other than installing RedHat/TurboLinux exclusivly on Pentium VI boxes.
The article that Slashdot actually links to about the problem is a total fluff piece for corporate-types, not the techies that will end up actually having to fix the problem. I would think that there would be a more technical link for us Slashdot readers. I could find nothing on RedHat's or SuSe's site. You would think they would at least mention it.At least we're still light-years ahead of the Windows in terms of 64-bit functionality. Our only saving grace. ;)
aÍÍ©ÍÌÍ£Ì'̽ͩÌÍzÍYÌÍÌY
Uhh, you have no idea what you're talking about. Maybe people shouldn't have bought a 386, either, since initially they were still running 16-bit apps anyway.
Please get a clue and at least say you wouldn't buy one _yet_.
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.
I'm pretty sure Slackware doesn't "probe" your cpu to tailor the install.
Why would the Slackware setup hose on this? It just assumes everyone has a i386 cpu, you want Pentium optimized binaries and kernel, compile it your fucking self.
Pentium 4's aren't even SMP capable yet. If what you're saying is true, then no one should have no problems.
When /. can mention a kernel has problems with a new piece of hardware and they have the next kernel out within the hour! Even if the kernel really doesn't have problems with the hardware, and /. has done it's usual piss-poor job of reporting the facts in it's stories, to jumpstart kernel development like that. Here I thought /. just DOSed websites.
Come on guys, use this power for good. Start saying that the P4 doesn't work with the 2.4 kernel, I want a kernel upgrade!
Steven
-- I have marked myself unwilling to moderate-- I don't have other accounts to artificially inflate the karma of
Despite the article's BS, Linux WILL run on a Pentium 4.
I have been subscribed to the lkml (Linux Kernel developer Mailing List) for several months now, and it was over a month ago when this topic came up. There was much controversy over why Intel chose a nonsequential number for the CPU ID, so it had to be coded around.
But the article speaks rubbish. Dealing with CPU IDs is not a distro-specific problem, it is an issue for the kernel only.
Now, RedHat might have gotten around it--but they've been releasing their own versions of the kernel, gcc, binutils, and their own kernel drivers for several versions now. (They get flamed often in lkml for this...)
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.
You troll, that's a bunch of FUD. You can read Intel's official statement on their website.
--
Bush's assertion: there ought to be limits to freedom
For the "peanut gallery," yes, that should have been 40GB.
If you're not part of the solution, you're part of the precipitate.
I am curious as to why China's Linux is 'notorious'? What makes it so? I think the editors here are just biased against China and are acting very unprofessionally here by taking a stab at China for no reason.
*They**do*that**a**lot**don't**they*
Windows 95 runs on a Pentium 4. Why shouldn't Linux? Oh yeah, I forgot that hardware compatibility (even basic hardware) sucks ass on Linux ...
Peanut Butter IS Peanut Butter, but Peanut Butter is NOT jelly.
How did this get modded up to 2?
But did the 386 have serious competitor like AMD is now?
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.
... it shows Linux distro intallation-program writers to be right dozy fsckers.
The code makes the following decision:
"You appear to be running this code, but I can't tell what chip you are so I won't let you run any other code."
Imagine a toll-booth on a motorway saying "nice car, however I've never seen it before, I don't know if it's suitable for this motorway, so you can't drive on it."
Open source, begins to sound more like they're trying to type Shakepeare after all.
FatPhil
Also FatPhil on SoylentNews, id 863
... 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
It's not news that Intel gave a large sum of money to RedHat back in its pre-IPO days. In this case RedHat is the only major distro to support the new Pentium VI. So now, if you're not firmly in bed with Intel, then you're the last the get the necessary chipset updates to make your distro run on the Pentium VI.
Anyone else see anything fishy about that?
aÍÍ©ÍÌÍ£Ì'̽ͩÌÍzÍYÌÍÌY
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
You can easily add the CPUID database to any distro. It's just a bunch of bytes and it's the SAME bloody kernel.
The message on the other side of this sig is false.
Funny... The above article got it right, as some others. Score 0. I have seen my article modded both as "insightful" (which it really isn't) and "troll", due to people not being able to lookup an MX record and reacting funny to everything which reminds them of "Signal 11" (No, sorry, pure coincidence, I have nothing to do with him.)
Anyhow, I really don't know why every little Linux problem gets so much attention. What do you think ? Artificial intelligence in the kernel that automagically adapts to new hardware ?
--
Actually the thermal dissipation of P4 is about equivalent to a 1.2 Ghz Athlon (slightly less if my memory is right, in the range of 55 Watts). But contrary to AMD, Intel took care to design large heatsink/fan and larger dissipation surfaces, while AMD still use the same Socket 7 heatsink type (way not enough). Also Intel CPU have an embedded thermal probe, which allow the BIOS to turn of the system in case of overheating.
Just because it doesn't recognize the CPUID it doesn't run?
Even Windows 95 doesn't have to be recompiled to run on P4s.
Do the *BSD have such problems? Or is this just a silly Linux thing?
Cheerio,
Link.
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.
You try and run on as many platforms as Linux does and work 100% of the time. Distributions tend to support hardware that has saturated the market rather well. I wouldn't be too upset if ANY distribution didn't support the P4 out of the box, as long as the information on how to fix this was readily available.
Sude, distributors probally could have been a bit more proactive about getting the information, but think people. The latest distributions we're released before the P4, and older distributions released long before P4 based test systems were even available.
Keep in mind, programming is like sex. One mistake and you have to support it for the rest of your life. Why don't you try supporting every platform Linux runs on and ensure that Linux boots 100% of the time even on the wackiest of hardware configurations. If you're complaining about the situation your definitly lack insight.
I'm going to go back in my box and will think within the limits of my box: MS Sucks Linux Good I read too much Slashdot.
Sounds like more than Intel dropped the ball.
If you're going to install an OS, shouldn't you check the HCL prior to installation?
I've been bitten by this sort of thing in the past, so I make a point of grabbing the HCL before installation! It's not tough, doesn't take long, and avoids sufering!
Note that this procedure works for ANY Os, not just Linux!
But Herr Heisenberg, how does the electron know when I'm looking?
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 was an article on Yahoo today that joined the throng of P4 critics: "No Pentium under my Christmas tree". Makes some good points about the problem with using Mhz alone to gauge speed these days (probably why Apple has a hard time selling its processors as "fast" anymore). Also points out where the problems will be with the P4 gaining acceptance in the market.
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?
Amigori
----------
Patience is a virtue.
"The quality of life is determined by its activites."--Aristotle
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.
.technomancer
.technomancer
Your hint appears broken.
Given that there are programs that work correctly on a 386 but not on a 486 (compack.exe, an executable compressor for MSDOS comes to mind), saying that the PIV is fully 386 compatible indicates that it is not 486/Pentium/PentiumII/etc. compatible.
Similarly, since the PIV doesn't emulate the original Pentium's famous FP bug, the PIV isn't compatible with the Pentium either.
Besides, consider an MMX instruction opcode. Execute it on a 386 and you'll likely get an invalid instruction exception, whereas on an MMX enabled CPU that is rather unlikely!
In short, the 486/P5/P6/etc. do not ALWAYS do the same thing given the SAME opcodes and arguments (i.e. the same binary code to execute). The point is that the basic instruction set is the same across the processors. They are nearly always the same, but there are exceptions.
John
John_Chalisque
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.
OK. How do you make an identifier for a product that is unique to it but also identical to its predecessor?
Perhaps you should have looked up what a CPUID was rather than how known broken code uses it!
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
we CAN'T imagine a beowolf cluster of Pentium IVs?
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.
I have an Athlon/Asus combo with Suse 6.4 installed and it works like a charm so maybe this is distro specific and not the chip... the old Red Hat installed lilo on my dual boot/dual HD (with NT) system a while back (5.0 maybe) thereby cutting me off from getting to the NT drive and there was no documentation on lilo in the manual and so after some time researching I found out that I had to fdisk the MBR. I wasn't happy about that experience. I looked at a Suse manual which documented the fact that one should be very careful with lilo and I bought their package and have been happy ever since.
Hey, you think your house is cool?
Umm, how many processors does Linux run on? And someone is saying Linux won't work on p4's? Hug wash!!
Ever since I been in Linux I have heard, Linux won't run on this, it won't do this, blah blah blah. If there is one thing I have heard about Linux is it will run anywhere and do anything. Through some "default" linux kernels will burf, who uses "defualt" kernels anyways? A few months from now... Linux will be all over these P4... and thanks to slashdot, I'll will have to kick all of the Linux newbies and sale jackasses in the head when they says anything about if Linux will work on the P4.
Hopefully, I won't have to deal with thier whines...
MarNuke
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...
> host sig11.net
sig11.net mail is handled (pri=50) by mail.netsign.net
It's called a mail exchanger. Who said using a fake address made you a troll anyway? That address was the contents of the fake email field of the database. It is obviously encouraged.
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?'"---