Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Intel

Most Linux Distros Won't Run on Pentium 4 182

Posted by Hemos from the bad-news-for-all dept.
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."
This discussion has been archived. No new comments can be posted.

Most Linux Distros Won't Run on Pentium 4 More

Most Linux Distros Won't Run on Pentium 4

Comments Filter:
  • 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.
  • 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.

  • Is Intel really responsible to contact EVERY OS manufacturer for x86 and let them know that they are releasing a new CPU

    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.

  • 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.
  • 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.

  • 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.
  • Maybe. But that directory on SuSE's ftp site *does* exist.

    --

  • Wonder how long these claims would last if Windows users didn't get their software preinstalled...

    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 [terradot.org]

  • Not sure what you're talking about here other than the usual Windows bashing. The jillion or so Win installs that I have done are pretty much push button, push button, push button, "give me the CD so I can install your drivers". The linux installs that I have done (RH and Suse) were far more complex than that. Hell I think installing Solaris on Sun was easier (though installing Solaris7 on Intel is a bitch due to hardware compatibility issues which it looks like linux has its own with the P4).

    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....

  • Brittle? The Linux kernel is brittle? 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?

    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.

  • Taco & Co post what they feel like.

    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 [terradot.org]

  • 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 [uni-magdeburg.de]

    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.....
  • 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.
  • 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?

  • 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.
  • 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.


    --

  • 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?

  • PIV CPUID was fixed in 2.2.18pre20 (Score:3)

    by gordzilla ( 97994 ) on Monday December 11, 2000 @07:56AM (#567310)
    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 [kernel.org]

  • Kernel panics and AMD (Score:4)

    by joshuaos ( 243047 ) <ouroboros@@@freedoment...com> on Monday December 11, 2000 @07:57AM (#567311) Journal
    It seems that the linux kernel has more problems than just the Pentium IV. I recently bought a brand new machine (piece by piece), with an AMD Thunderbird 800Mhz processor, and when I installed RedHat 6.2, the installation went fine, but as soon as I tried to boot, it tried to disable the CPUID and kernel panics and goes into a hard lock every time. I managed to pass a parameter to the kernel at boot, but it's rather rediculous that the kernel seems to have this problem fairly often.

    Joshua

    Terradot [terradot.org]

  • Repeat after me: Linux != Red Hat (Score:3)

    by morzel ( 62033 ) on Monday December 11, 2000 @01:19PM (#567312)
    Some thoughts:

    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.

  • 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.


    --

  • 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.


    --

  • 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.
  • props to you for sticking to it, even tho most people are like "jeeze, he can't even do that simple little thing" or "RTFM". I highly recommend any of the O'Reilly (http://www.oreilly.com) books. On any subject for that matter. if you want "instant" help, the www.linux.org and www.(nameyourdistro).com has pretty good information. I've always had good results with re-compiling my kernel with Slackware

    As far as windows being more intiutive for users, no contest. Developers for linux don't care about the common man, and generaly won't help them (before you flame me, make the software easy to use/install!) Generaly however, most of them do write good man pages (type man man at a command prompt in linux for help with stuff (it's man (commandname) to get the man page, not much help tho if you don't know what it's called))

    Also, I learned much about linux by hanging out with linux gurus. Find someone better than you at linux, and learn from them. Watch them use it, ask for help setting up your system. Join a Linux User Group. Go bug the local high school/college. I have found that people are the best help, once they get off their high horse.

  • lilo: linux x86_serial_nr=1

    That is indeed how I finally got the bugger to boot, thanks to some very similar (and helpful advice from DJBongHit [smokedot.org] on IRC, after trying to install RedHat7.0, which was so screwed up that the install program barely worked, and the screen didn't redraw properly. It booted, but it was whack.

    Unfortunately, I'm still a bit of a newbie, and haven't braved the compiling of the kernel yet, but I willdo soon, I'm sure. :)

    Cheers, Joshua

    Terradot [terradot.org]

  • One could also argue that Linux should be installed by those that have that knowledge. This is not intended as a flame. Windows is user-friendly you say? But remember, the consumer almost NEVER imstalls it themselves. They get it pre-installed. As for "user performed" upgrades, I had a neighbor upgrade from 95 to 98. They didn't do it themselves, they called me. ;)

    Installing an OS should be easier, but Windows isn't necessarily easy. Especially when trying to install on a system with a badly hosed Windows system that the CD wants to try to salvage. (which makes things worse)

    Maybe the Linux community needs more people willing to help their friends with Linux problems, just as knowledgable Windows users help those in need.

  • Come on it's just an ID entry in the CPUID database how hard can it be to fix?
  • 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.
  • 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...
  • 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

  • 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.

  • Robustness (Score:3)

    by Wolfier ( 94144 ) on Monday December 11, 2000 @07:59AM (#567328)
    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.

  • Re:Bull (Score:2)

    by booch ( 4157 )
    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.)

  • Re:Just get 2.2.18 (Score:5)

    by Majix ( 139279 ) on Monday December 11, 2000 @08:02AM (#567332) Homepage
    P4 owners only need to download 2.2.18 which should be out any day now

    ... and mere moments after posting, Linux 2.2.18 [kernel.org] was released :)
  • 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.
  • and uhm... passing a parameter to the kernel at boot should not be THAT hard...

    It is for a total linux newbie like myself! This, I think is the real problem with any *nix getting really mainstream and in any way competing with windoze/mac... linux users have trouble remembering how steep the linux learning curve really is, and how hard it is to get going. I got through it cause I have plenty of computer knowledge, and plenty of friends to ask, but someone who isn't as knowledgable as me simply couldn't get linux running without help, and that is what needs to change before linux can really get bigger.

    Joshua

    Terradot [terradot.org]

  • The ALL NEW PENTIUM VI

    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!
  • 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.
  • Depends on how you propose to fix the problem. Maybe it might be possible to presume the cpu is an i386 with no floating point if there's not a full database match, but that might piss off a lot of people, or it might not work at all anyway. I'm not sure how detailed the cpuid list is.

    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....).

    It's not really surprising. 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. If it required a kernel developer getting his or her hands on an actual P4, that's not the linux communities fault.

    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?
  • Comment removed based on user account deletion
  • that seems more appropriate to an industrial-strength OS with an approved hardware list, which Linux decidedly doesn't have.

    Here's Red Hat's [redhat.com]. Your Linux distributor is likely to have its own list.
  • On the article:

    "The rest of the Linux herd won't run on the hardware."



    Hey, /. staff. Before BOOMing the news read creafully the article and leave some piece of salt on it, instead of crying PANIC!

    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?

  • 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.

    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.

  • Oh man. I guess this would be optimal behavior for a server situation where you compiled your own kernel with exactly the right drivers (etc...) for your precise hardware, and any weirdness represented failure.

    But in most other situations, I think this could conceptually be way more of a pain than it's worth. If you think about it, the kernel is actually pretty damn tolerant of hardware "failure," which (for me, anyway :) often ACTUALLY indicates a misconfiguration. I mean, I've run the wrong X Server, wrong sound card drivers, bad hard drive, and probably tons of other stuff, and linux at least BOOTS, even if I have to use single-user mode to fix my fsck-ups.

    Personally, I'm glad it works this way, and I honestly would've expected some kind of similar fallback behavior in case of an unrecognized CPU. I mean, I see your point, but that seems more appropriate to an industrial-strength OS with an approved hardware list, which Linux decidedly doesn't have.

  • "It's not like you're scaling Everest."

    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:

    • TurboLinux 4.0 was completely unable to cope with /dev/hda
    • Red Hat 6.2 was completely unable to cope with /dev/hda
    • Debian 2.1 [the "O'Reilly/VA Linux Boxed Set"] was unable to fdisk the drive, but once I had a set of partitions, it could at least recognize them;
    • [Most Recent] Caldera OpenLinux was the only system able to boot off the CD-ROM and successfully run fdisk so I could get the HD partitioned.

    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... :-)

  • Linux has a very small kernel bug that keeps it from running on some Pentium 4 systems, that you can work around with a boot-time command line argument. Nobody has Pentium 4 systems to run Linux on yet. It's not clear that anyone even wants them yet. Intel didn't get talk to the kernel team in time (forget about the distributions, it's not their problem). But a repaired kernel is already available.

    It must be a slow news day :-)

    Thanks

    Bruce

  • Re:Kernel panics and AMD (Score:4)

    by Thagg ( 9904 ) <thadbeier@gmail.com> on Monday December 11, 2000 @08:57AM (#567379) Journal
    Thunderbird and Duron CPUs did have this problem with RedHat 6.2 only; in that RedHat 6.2's installed kernel (as opposed to the installation kernel) tried to turn of the CPUID with a panic resulting.

    The way to fix it is to boot this system at the lilo prompt with the x86_serial_nr=1 flag as in the following

    lilo: linux x86_serial_nr=1

    Then, rebuild a kernel. The defaults, interestingly, don't enable the CPUID; so just making a kernel with all the defaults yeilds something that boots.

    thad

  • 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.

    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.

  • Has anybody told ... (Score:5)

    by Bryan Ischo ( 893 ) on Monday December 11, 2000 @08:34AM (#567397) Homepage
    ... the existing three Pentium 4 owners about this?
  • The author of the article makes some valid points, that AMD has addressed speeding up existing software, whereas Intel has not (i.e. it's a faster car, but it only runs on alcohol, find a pump in every town and you're all set.)

    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 [theregister.co.uk], which brings a 1.2 GHz cpu to your desk for $254 (1.3GHz P4 ~300) [theregister.co.uk]

    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.

    --

  • 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.
  • Discussions on linux-kernel seemed to indicate that the Pentium 4 returned Family 15 (IV, get it?)

    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."

  • Re:Isn't this kernel dependent? (Score:3)

    by Defiler ( 1693 ) on Monday December 11, 2000 @09:08AM (#567403)
    Note: No closed-source OS has a problem with the Pentium IV.
  • 'Damage'? Is the Pentium IV fully 386-compatible or not? (Hint: it is.)

    There's no harm in running 386 (or even 8086) code on any modern Intel x86 processor. They make a lot of effort to keep them 100% compatible - that's why the x86 architecture sucks (relative to other architectures that don't have such burdensome compatibility requirements, and considering the amount of effort put in). Heck, you could even put the CPU into 8080 compatibility mode and run CP/M on it at ridiculous speeds (not sure about this - is the '8080 mode' 100% compatible?)

    It wouldn't even run that slowly, not for most tasks anyway. Fancy stuff like MMX, SIMD, and other extensions are used for graphics and for some tasks like RAID checksums, but not used much on a normal workstation. Pentium-optimized code runs twice as fast *at best* and usually the difference is more like ten per cent.

  • Interesting article... (Score:3)

    by Tridus ( 79566 ) on Monday December 11, 2000 @07:33AM (#567407) Homepage
    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.
  • ... and mere moments after posting, Linux 2.2.18 was released :)

    Actually, I downloaded it (or really, the patch from 2.2.17) a couple of hours before your original comment was posted...

  • Time and time again I see inaccurate reports, either in the printed media or on a web site. Either the author didn't check their facts before writing, or clearly didn't understand the issue in the first place.

    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.

  • It's not the kernel, it's RPM (Score:3)

    by Das Kamikaze ( 17808 ) on Monday December 11, 2000 @12:11PM (#567415) Homepage
    The problem isn't from the kernel not knowing what the CPU is. True, it doesn't, but it doesn't mind that, and works fine on the Pentium 4 anyway. The real problem is in RPM.

    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.


    --

  • The author remarks that this is the sort of thing that we can expect from Intel, but doesn't some of the fault belong to the Linux-distro maintainers? Surely they must have foreseen this problem, and surely Intel should have verified that the problem was taken care of before the P4 ship date.

    Sounds like more than Intel dropped the ball.

  • #define CRAP_OUT_ON_ANY_ERROR true (Score:3)

    by The Dev ( 19322 ) on Monday December 11, 2000 @08:38AM (#567423)
    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.

  • If the cpuid database does not match the CPU, it is the kernel's best interest behave like an ad hoc i386 kernel

    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 [intel.com] and Intel Pentium 4 Processor Identification and the CPUID Instruction [intel.com].

  • This is one reason I'm not jumping on the bandwagon for any new tech, ATM. Intel and AMD are in a horserace and Intel has been very sloppy with Q/A. Although I had assumed one or two evaluation boxes would fall into the hands of other Linux distributors, apparently Intel didn't get enough of these out or the distros didn't see the problem (which should have been immediately obvious.)

    I'll just wait a couple months then get something nice and safe and out of date. ;)

    --

  • 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.
  • > But in most other situations,

    I agree, which is why I pointed out twice that I'm in the minority. All I'm saying is there are some people who don't want an operating system that blindly soldiers on when it finds something wrong. Maybe it should be a config option for those who want it, and maybe Mandrake, Redhat etc can set it to assume unknown processors == i386 with no FPU, but I for one think linux's current behaviour on meeting an unknown processor is the correct default behaviour because it is the safest.
  • 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 :-)
  • News for you. MS is MS. Debian is not MS.
  • 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.

  • fix (Score:3)

    by ee23 ( 257528 ) on Monday December 11, 2000 @07:41AM (#567444)

    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/ [suse.com])

  • 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.
  • 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.
  • linux users have trouble remembering how steep the linux learning curve really is, and how hard it is to get going.

    Wonder how long these claims would last if Windows users didn't get their software preinstalled...
  • 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.

  • Re:Isn't this kernel dependent? (Score:3)

    by be-fan ( 61476 ) on Monday December 11, 2000 @09:36AM (#567453)
    You're rather dim view of closed source companies really doesn't make sense. For something like this, major companies like HP, SCO, etc would have fixed out before the chip hit the market. If Intel is coming out with a totally new generation chip, you don't just sit on your ass, you go ask them if there are compatiblity issues. Response time for comanies really isn't that bad. For example, there was a beta copy of pci-bios out for QNX RtP just a few days after people started reporting problems with graphics cards.

  • Athlon? (Score:2)

    by Suydam ( 881 )
    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.

  • Informative? Am I missing something here?
  • My AMD had exactly the same problem. In the end I think I managed to use a boot disk with a working kernel on it to boot and a quick recompile solved it once and for all.

    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...

  • How? If RedHat has fixes, then the remaining 10% of the Linux population really isn't worth reporting. If Windows has a bug, it affects millions of people. If Linux has a bug, it effects a much smaller percentage. Similarly, if a bomb goes of in DC, everone reports it. If it goes of in (say) Namibia, then its unlikely that anyone outside a radius of 5 miles is going to report it.
  • Yes, I have identical systems just lying around my secret lab. I buy 'em in bulk for occasions such as these.

    Get real.
  • This is falling into a pattern that is being seen way too often on Linux news sites. From LinuxGram's "about" page [linuxgram.com]:
    What makes us unique is our intelligence, which comes from:
    • The best reporters in the industry. We get the story behind the story.
    • The best reporters in the industry. We get the story behind the story. A perspective that comes from the years we've been in this industry. We don't just rewrite press releases.
    • Contacts at the highest level of every company in the industry. We've even been accused of having bugs in their boardrooms.
    • We work harder. We have a proven track record. No other newsweekly breaks more news. Every week. Week after week.
    • A fierce dedication to reporting the facts. We get it right the first time - an accuracy rate that is unchallenged.
    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.

  • Re:Bad kernel design (Score:3)

    by alhaz ( 11039 ) on Monday December 11, 2000 @07:48AM (#567466) Homepage
    Depends on how you propose to fix the problem. Maybe it might be possible to presume the cpu is an i386 with no floating point if there's not a full database match, but that might piss off a lot of people, or it might not work at all anyway. I'm not sure how detailed the cpuid list is.

    AMD Athlons had a similar problem. In kernels before i think 2.2.13, if you enabled the MTRR driver (needed to enable write-combining on video adapters, etc) and booted it on an athlon, it would erroniously detect the cpu as a K6 and promply panic when the MTRRs in the cpu didn't react the way K6's do.

    It's not really surprising. 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. If it required a kernel developer getting his or her hands on an actual P4, that's not the linux communities fault.

  • What happened to the Linux community? (Score:3)

    by somethingwicked ( 260651 ) on Monday December 11, 2000 @07:49AM (#567467)
    I thought that was the great thing about Linux...one guy in BFD figures out how to fix this and everything is cool?

    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.

  • Re:Interesting article... (Score:3)

    by Tridus ( 79566 ) on Monday December 11, 2000 @07:49AM (#567468) Homepage
    I bet they did too. They only have to go to one place to check Windows compatability: MS.

    They may have checked to see if the kernel itself works on a P4, I don't know. (obviously it does, because RH and Turbolinux (I think) will work correctly now.)

    I don't blame them for not running around to every distro maker and checking up on them before releasing the chip. Thats not Intels job, and its rediculous to ask them to babysit the distro makers.

    If the same problem cropped up on a new AMD cpu, do you think the article would be blaming AMD for it?

    Somehow, I doubt it.

Slashdot Top Deals

E = MC ** 2 +- 3db

Close