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

Comments

PIV CPUID was fixed in 2.2.18pre20

[gordzilla]

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 panics and AMD

[joshuaos]

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

Re:Kernel panics and AMD

[Thagg]

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

Repeat after me: Linux != Red Hat

[morzel]

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.

Robustness

[Wolfier]

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:Just get 2.2.18

[Majix]

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 was released :)

Has anybody told ...

[Bryan Ischo]

... the existing three Pentium 4 owners about this?

Re:Isn't this kernel dependent?

[Defiler]

Note: No closed-source OS has a problem with the Pentium IV.

Interesting article...

[Tridus]

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.

Re:Interesting article...

[Tridus]

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.

It's not the kernel, it's RPM

[Das Kamikaze]

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!

Bad kernel design

[Reality Master 101]

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.

--

Re:Bad kernel design

[alhaz]

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.

#define CRAP_OUT_ON_ANY_ERROR true

[The Dev]

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.

fix

[ee23]

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

Re:Isn't this kernel dependent?

[be-fan]

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.

Whatever happened to objective reporting?

[IsleOfView]

This is falling into a pattern that is being seen way too often on Linux news sites. From LinuxGram's "about" page:

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

What happened to the Linux community?

[somethingwicked]

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.