REP MOVS bug in Opteron (& presumably FX)

http://www.3dchips.net/content/story.php?id=3927

No information on any BIOS update from my motherboard manufacturer (ASUS)
yet.

Jeff Butler wrote:
http://www.3dchips.net/content/story.php?id=3927

No information on any BIOS update from my motherboard manufacturer
(ASUS) yet.

Wonder how a BIOS update is going to resolve a problem within the
instruction set? Unless it's a firmware patch that's included in the BIOS.

Yousuf Khan

Yousuf Khan wrote:
Jeff Butler wrote:

http://www.3dchips.net/content/story.php?id=3927

No information on any BIOS update from my motherboard manufacturer
(ASUS) yet.


Wonder how a BIOS update is going to resolve a problem within the
instruction set? Unless it's a firmware patch that's included in the BIOS.


One gathers that Opteron has the microcode update feature that allows
the correction of at least some bugs and that Intel has had since 2000.

Redhat Linux boxes automatically update at least Intel microcode at each
boot:

http://kerneltrap.org/node/view/2678

It sounds a good deal safer, actually, than messing with the BIOS.

RM

"Robert Myers" wrote in message
news:LrJBc.68599$2i5.9849@attbi_s52...
Yousuf Khan wrote:
Jeff Butler wrote:

http://www.3dchips.net/content/story.php?id=3927

No information on any BIOS update from my motherboard manufacturer
(ASUS) yet.


Wonder how a BIOS update is going to resolve a problem within the
instruction set? Unless it's a firmware patch that's included in the
BIOS.


One gathers that Opteron has the microcode update feature that allows
the correction of at least some bugs and that Intel has had since 2000.

Redhat Linux boxes automatically update at least Intel microcode at each
boot:

http://kerneltrap.org/node/view/2678

It sounds a good deal safer, actually, than messing with the BIOS.

RM


That's what I was thinking, that it's going to be a microcode patch. Another
less likely possibility is to trap the instruction to software as was once
proposed for the Pentium FDIV bug before Intel decided to recall the chip.

One more piece of information: It's not just Opterons. It's all AMD64 at
revision C0 and higher.

"Yousuf Khan" wrote in message
.cable.rogers.com...
Jeff Butler wrote:
http://www.3dchips.net/content/story.php?id=3927

No information on any BIOS update from my motherboard manufacturer
(ASUS) yet.

Wonder how a BIOS update is going to resolve a problem within the
instruction set? Unless it's a firmware patch that's included in the BIOS.

Yousuf Khan

The description of the bug suggests that it is due to a performance
optimization - e.g. only occurs when some other microcoded insructions are
in the pipeline. Its possible that AMD has a means to disable such
optimizations which would reduce performance in some cases. Hopefully this
won't have much impact on performance in the typical case.

Peter

On Mon, 21 Jun 2004 22:56:05 GMT, "Jeff Butler"
wrote:



That's what I was thinking, that it's going to be a microcode patch. Another
less likely possibility is to trap the instruction to software as was once
proposed for the Pentium FDIV bug before Intel decided to recall the chip.

One more piece of information: It's not just Opterons. It's all AMD64 at
revision C0 and higher.



Maybe that's why amd64 boards were so touchy with ram early on.

I'd imagine aggressive timings on weak ram might aggravate the
situation.

On Tue, 22 Jun 2004 11:03:14 +0100, "Peter Dickerson"
wrote:
"Yousuf Khan" wrote in message
t.cable.rogers.com...
Jeff Butler wrote:
http://www.3dchips.net/content/story.php?id=3927

No information on any BIOS update from my motherboard manufacturer
(ASUS) yet.

Wonder how a BIOS update is going to resolve a problem within the
instruction set? Unless it's a firmware patch that's included in the BIOS.

Yousuf Khan

The description of the bug suggests that it is due to a performance
optimization - e.g. only occurs when some other microcoded insructions are
in the pipeline. Its possible that AMD has a means to disable such
optimizations which would reduce performance in some cases. Hopefully this
won't have much impact on performance in the typical case.

Microcode instructions are already pretty slow and therefore rarely
used anyway, so I doubt that it would make a big difference. These
sorts of errata are not particularly rare in modern processor designs,
pretty much all chips have bugs that are not entirely unlike this one.
FWIW here's the link to AMD's own Revision Guide (aka errata sheet):

http://www.amd.com/us-en/assets/cont...docs/25759.pdf


The particular bug in question is number 109 and was just added in the
latest update along with bug 111 ("Rtt Specification Violation", a
seemingly inconsequential issue with hypertransport).

-------------
Tony Hill
hilla underscore 20 at yahoo dot ca