Most Linux Distros Won't Run on Pentium 4 182
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."
Re:Whatever happened to objective reporting? (Score:1)
But the Rambus thing... sheesh. That alone is enough to make me question whether Intel has one tiny clue.
Moderator on crack offtopic when good comments -? (Score:1)
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.
Re:Whatever happened to objective reporting? (Score:2)
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.
Re:Most Linux users wouldn't want Pentium 4 (Score:2)
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.
it would be a good idea to close the topic (Score:1)
Re:This goes into the "who cares" category (Score:1)
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.
Does it (Score:1)
Re:Troll Alert! / Stupid Moderators (Score:2)
--
Re:Kernel panics and AMD (Score:1)
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]
Re:Kernel panics and AMD (Score:1)
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....
Re:Bad kernel design (Score:1)
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.
Re:Kernel panics and AMD (Score:1)
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]
Re:#define CRAP_OUT_ON_ANY_ERROR true (Score:2)
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?
Re:Bad kernel design (Score:1)
Re:Has anybody told ... (Score:1)
Re:Good kernel design. (Score:2)
Funny (Score:1)
Who is the idiot who made this article?
Re:Whatever happened to objective reporting? (Score:2)
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.
Just get 2.2.18 (Score:2)
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).
Re:Bad kernel design (Score:2)
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.
--
SO WHAT, NON -ISSUE, NEXT PLEASE.... (Score:2)
And how many P4 prototype units were available? (Score:1)
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.
works fine for me... (Score:1)
PIV CPUID was fixed in 2.2.18pre20 (Score:3)
Kernel panics and AMD (Score:4)
Joshua
Terradot [terradot.org]
Repeat after me: Linux != Red Hat (Score:3)
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.
Re:Good kernel design. (Score:1)
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.
--
This is a non issue (Score:1)
Re:Isn't this kernel dependent? (Score:1)
Re:Bad kernel design (Score:1)
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.
--
Re:Interesting article... (Score:1)
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.
Re:Kernel panics and AMD (Score:1)
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.
Re:Kernel panics and AMD (Score: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]
Re:Kernel panics and AMD (Score:1)
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.
It shouldn't be that hard to fit (Score:2)
Re:#define CRAP_OUT_ON_ANY_ERROR true (Score:1)
Isn't this what the GPL is supposed to be about? (Score:1)
Isn't this kernel dependent? (Score:2)
i386? (Score:1)
Even most of the default precompiled kernels like in the slack install are like this.
Sounds Like FUD
Are you kidding? (Score:2)
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
Re:Who cares (Score:2)
Robustness (Score:3)
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)
Re:Just get 2.2.18 (Score:5)
Good kernel design. (Score:2)
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.
Re:Kernel panics and AMD (Score:2)
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]
What Intel doesn't tell you about the 10GHz chips (Score:2)
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>
Re:Sheesh! This is messed up.... (Score:2)
Re:Bad kernel design (Score:2)
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.
Re:Bad kernel design (Score:2)
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.
Re:Author pins all blame on Intel... (Score:2)
Re: (Score:2)
Re:Good kernel design. (Score:2)
Here's Red Hat's [redhat.com]. Your Linux distributor is likely to have its own list.
Is this called "news"? (Score:2)
"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?
Re:#define CRAP_OUT_ON_ANY_ERROR true (Score:2)
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.
Re:Good kernel design. (Score:2)
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.
New Boot Disks... (Score:2)
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... :-)
Is this news? (Score:2)
It must be a slow news day :-)
Thanks
Bruce
Re:Kernel panics and AMD (Score:4)
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
That makes no sense. (Score:2)
Pentium 4's aren't even SMP capable yet. If what you're saying is true, then no one should have no problems.
It installed fine last time I tried it... (Score:2)
Typo: 40GB, not 40MB (Score:2)
Has anybody told ... (Score:5)
Re:Not the only problem (Score:2)
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.
--
Sheesh! This is messed up.... (Score:2)
Re:Why fall all the way back to 386? (Score:2)
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)
Re:Good kernel design. (Score:2)
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)
Yeesh.
Re:Just get 2.2.18 (Score:2)
Actually, I downloaded it (or really, the patch from 2.2.17) a couple of hours before your original comment was posted...
Whatever happened to accuracy? (Score:2)
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)
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 (Score:5)
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.
--
Author pins all blame on Intel... (Score:2)
Sounds like more than Intel dropped the ball.
#define CRAP_OUT_ON_ANY_ERROR true (Score:3)
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.
Why fall all the way back to 386? (Score:2)
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].
As I was just discussing with a colleague... (Score:2)
I'll just wait a couple months then get something nice and safe and out of date. ;)
--
Fixing the Linux Distro (Score:2)
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
Re:Whatever happened to objective reporting? (Score:2)
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.
CPUID failing on RPMs (Score:2)
Re:Good kernel design. (Score:2)
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.
Re:Most Linux users wouldn't want Pentium 4 (Score:2)
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
Re:Interesting article... (Score:2)
Re:Whatever happened to objective reporting? (Score:2)
fix (Score:3)
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])
Database? (Score:2)
Re:Whatever happened to objective reporting? (Score:2)
Some of the other problems were actaully due to the chipset, not the CPU.
Re:Kernel panics and AMD (Score:2)
Wonder how long these claims would last if Windows users didn't get their software preinstalled...
Re:Bad kernel design - my understanding of the lk (Score:2)
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)
Athlon? (Score:2)
Re:works fine for me... (Score:2)
Just recompile but blame the chip makers (Score:2)
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...
Re:Is this news? (Score:2)
Re:Sheesh! This is messed up.... (Score:2)
Get real.
Whatever happened to objective reporting? (Score:4)
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...
Re:Most Linux users wouldn't want Pentium 4 (Score:2)
Re:Bad kernel design (Score:3)
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)
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)
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.