By: philt (ptay1685.delete@this.bigpond.net.au), June 28, 2007 4:28 pm
Room: Moderated Discussions
Linus Torvalds (torvalds@osdl.org) on 6/28/07 wrote:
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 6/28/07 wrote:
>>
>>Well, most other CPUs are embedded ones.
>
>Well, I'd call those "commodity", wouldn't you? Even more
>so than x86.
>
>That said, a lot of them 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".
>
>>Whether other higher-end CPUs have more errata than x86s
>>I don't know.
>
>They 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 them,
>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.
>
>Linus
FYI just had a look at the Intel pdf for Core 2 errata. Amazed at the number of errata listed. Also, most seem to have the "nofix" code next to them, which if ive read the key correctly, means they are not going to be fixed. The fixed or going-to-be-fixed bugs are in the minority.
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 6/28/07 wrote:
>>
>>Well, most other CPUs are embedded ones.
>
>Well, I'd call those "commodity", wouldn't you? Even more
>so than x86.
>
>That said, a lot of them 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".
>
>>Whether other higher-end CPUs have more errata than x86s
>>I don't know.
>
>They 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 them,
>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.
>
>Linus
FYI just had a look at the Intel pdf for Core 2 errata. Amazed at the number of errata listed. Also, most seem to have the "nofix" code next to them, which if ive read the key correctly, means they are not going to be fixed. The fixed or going-to-be-fixed bugs are in the minority.