By: Joe Chang (jchang6.delete@this.Xyahoo.com), June 27, 2007 3:01 pm
Room: Moderated Discussions
since atleast P Pro days, the intel CPU allowed micro-code patches, probably stored in the BIOS
the micro-code patches generally work around these bugs
all cpus have bugs or errata, which means specific instructions do not work as intended, but very rarely is an errata so problematic as to warrant a recall as with Pentium,
when a patch work around is satisfactory, the errata in not fixed in that generation
I recall many people running NetWare servers wanting their CPU changed. NetWare should not use FP instructions right?
(with exceptions for special apps)
when PIII came out with SSE instructions, I remember a discussion with ex-Cray guys on the special intructions for fast divide and square root, which sacrificed accuracy for speed, they all smiled, their idea in the first place
David Kanter (dkanter@realworldtech.com) on 6/27/07 wrote:
---------------------------
>Matt Sayler (sayler@thewalrus.org) on 6/27/07 wrote:
>---------------------------
>>http://marc.info/?l=openbsd-misc&m=118296441702631
>>> :
>>" - Basically the MMU simply does not operate as specified/implimented
>>in previous generations of x86 hardware. It is not just buggy, but
>>Intel has gone further and defined "new ways to handle page tables"
>>(see page 58).
>>- Some of these bugs are along the lines of "buffer overflow"; where
>>a write-protect or non-execute bit for a page table entry is ignored.
>>Others are floating point instruction non-coherencies, or memory
>>corruptions -- outside of the range of permitted writing for the
>>process -- running common instruction sequences."
>>
>>Ignore for a moment the tone, and concentrate on the substance...
>>
>>How significant were the TLB handling changes?
>>
>>In general, do Core2 chips seem to be more or less buggy than previous iterations?
>>Are errata par for the course as we approach >billion-transistor commodity MPUs?
>
>That's kind of hard to say. I think Intel is really the only company that publicly
>discloses their errata. I know that Sun doesn't, and I'm pretty sure AMD does not either.
>
>This doesn't strike me as a huge issue. The folks who are talking about product
>recalls fail to understand that unlike the FDIV bug, this is not something which
>is easy for a consumer to understand, nor is it easy to manifest.
>
>The FDIV bug was uncovered within Intel using either excel or the built in MS calculator.
>I don't know how the folks outside of Intel found it, but it may be along the same
>lines. It sounds like most of these issues only impact developers, and are much harder to uncover.
>
>DK
the micro-code patches generally work around these bugs
all cpus have bugs or errata, which means specific instructions do not work as intended, but very rarely is an errata so problematic as to warrant a recall as with Pentium,
when a patch work around is satisfactory, the errata in not fixed in that generation
I recall many people running NetWare servers wanting their CPU changed. NetWare should not use FP instructions right?
(with exceptions for special apps)
when PIII came out with SSE instructions, I remember a discussion with ex-Cray guys on the special intructions for fast divide and square root, which sacrificed accuracy for speed, they all smiled, their idea in the first place
David Kanter (dkanter@realworldtech.com) on 6/27/07 wrote:
---------------------------
>Matt Sayler (sayler@thewalrus.org) on 6/27/07 wrote:
>---------------------------
>>http://marc.info/?l=openbsd-misc&m=118296441702631
>>> :
>>" - Basically the MMU simply does not operate as specified/implimented
>>in previous generations of x86 hardware. It is not just buggy, but
>>Intel has gone further and defined "new ways to handle page tables"
>>(see page 58).
>>- Some of these bugs are along the lines of "buffer overflow"; where
>>a write-protect or non-execute bit for a page table entry is ignored.
>>Others are floating point instruction non-coherencies, or memory
>>corruptions -- outside of the range of permitted writing for the
>>process -- running common instruction sequences."
>>
>>Ignore for a moment the tone, and concentrate on the substance...
>>
>>How significant were the TLB handling changes?
>>
>>In general, do Core2 chips seem to be more or less buggy than previous iterations?
>>Are errata par for the course as we approach >billion-transistor commodity MPUs?
>
>That's kind of hard to say. I think Intel is really the only company that publicly
>discloses their errata. I know that Sun doesn't, and I'm pretty sure AMD does not either.
>
>This doesn't strike me as a huge issue. The folks who are talking about product
>recalls fail to understand that unlike the FDIV bug, this is not something which
>is easy for a consumer to understand, nor is it easy to manifest.
>
>The FDIV bug was uncovered within Intel using either excel or the built in MS calculator.
>I don't know how the folks outside of Intel found it, but it may be along the same
>lines. It sounds like most of these issues only impact developers, and are much harder to uncover.
>
>DK