| Torvalds comments on Core 2 Duo bugs |
Jul. 02, 2007
"Bugs happen," concluded Linus Torvalds after a discussion of Core 2 Duo errata on the Linux Kernel Mailing List (LKML) last week. The pragmatic iconoclast defended Intel for handling bugs publicly, in contrast to embedded chip makers that tend to hide chip bugs behind workarounds in their OS ports.
The discussion of Core 2 Duo bugs was prompted by an OpenBSD mailing list post last week by Theo de Raadt. De Raadt, who founded the high-security oriented OpenBSD distribution, had expressed frustration over what he termed "unfixable" Core 2 Duo bugs. He characterized the Core 2 Duo architecture as "buggy as hell," while adding that AMD has "serious errata lists [that] are growing rapidly too."
For his part, Torvalds defended Intel for aggressively publishing bug reports, to the point of publishing bugs that can only be duplicated by ignoring Intel's own documentation. "[Intel] did learn something from the F00F and FDIV bugs, I think. They're very good about making [bugs] public these days," he wrote.
Torvalds goes on to contrast Intel's pro-active, public bug reporting to that of "boutique" and "embedded" chip makers. Smaller chip houses sometimes opt to "just ship the buggy crud" and "never tell anybody" about bugs, Torvalds suggests, if they can manage to work around bugs in their firmware and OS ports.
One of Torvalds's posts reads in part:A lot of [embedded CPUs] are quite buggy. The way the embedded people define it, though, any bugs becomes just "specifications".
For example, the ARM cache control has always been pretty damn buggy. What is the solution? Document it as a bug, and tell people not to use it.
Or grep for "errata" in arch/arm in the Linux kernel. Trust me, they exist.
But yeah, you can make a microcontroller CPU that is based on some decade-old core that is fairly bug-free. Not that it probably really is, but over the years the bugs have all become "behavior" rather than "bugs".
[Embedded chip vendors] tend to fix the bugs that are user-visible, and then not fix the bugs that can be worked around on an OS level.
Also, boutique vendors tend to not talk about [bugs], because it's all internal to their own stuff. Of course, if they don't catch it in time, they'll have to release OS upgrades, but if they find an errata early, they can just work around it and need never tell anybody, exactly like the random embedded ones.
It's really simple: when you count your CPU's in thousands rather than millions, you generally don't want to do a whole new mask set that costs you months and a few megabucks. It's much cheaper to just ship the buggy crud.
Yeah, x86 errata get more attention. But those things are pretty damn well tested. Better than most. And since the OS is outside the control of the vendors, they get fixed too. In another post, Torvalds said Linux was not affected, as far as he knew, by changes to the Core 2 Duo architecture's TLB (translation look-aside buffer). While De Raadt complained that Intel had "defined 'new ways to handle page tables,'" Torvalds explained, "We had mis-used the TLB earlier, and fixing that software bug we rewrote the page table handling to be more robust, which means that the spec update from Intel didn't affect us at all, afaik."
Torvalds did say Intel should have better-documented its TLB behaviour in the past. Better documentation could have warned users that higher-level page table structures could be cached, in the future. "If you depended on it not happening (and a lot of people did), it's painful," he admitted, adding, "But it really does make the architecture definition better and clearer."
The complete thread can be found here.
Related Stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed