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 |
All times are GMT +1. The time now is 01:54 PM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
HardwareBanter.com