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

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.