Slashdot Mirror
AMD Confirms CPU Bug Found By DragonFly BSD's Matt Dillon
An anonymous reader writes "Matt Dillon of DragonFly BSD just announced that AMD confirmed a CPU bug he found. Matt quotes part of the mail exchange and it looks like 'consecutive back-to-back pops and (near) return instructions can create a condition where the processor incorrectly updates the stack pointer.' The specific manifestations in DragonFly were random segmentation faults under heavy load."
Though, it's still very serious. At least it generally causes your program to crash rather than spitting out a wrong answer. And it sounds like the sequence of instructions that causes it is not commonly found.
I can well understand the guy who found it being all excited. The CPU is the last place you'd look for a bug, and finding one is pretty impressive, especially a really elusive one like this.
Need a Python, C++, Unix, Linux develop
I wonder if AMD likes apples.
This is cool, but...?
Why does it matter that it's the lead developer of DragonflyBSD?
Find free books.
Nice work tracking that one down. It must have been very frustrating - what we used to call a "ring-tailed b1tch"
Breathe continuously
I'm wondering if they will. This seems like a very odd timing issue that may be a problem in the electronics. Of course, I suppose they could just put in some microcode to wait after certain operations to make sure things settle and so avoid the hardware bug.
Need a Python, C++, Unix, Linux develop
What has Taiwan got to do with this ?
I mean, was the CPU bug somehow introduced by TSMC ?
Muchas Gracias, Señor Edward Snowden !
After reading the links and knowing how I have time trying to find out why something doesn't work right I think I understand why he is so stoked at finding the root of the problem. Good for Matt, maybe they will send you a fixed processor someday.
I can only imagine the time and effort spent on tracking down this problem - a rare CPU condition is exponentially more difficult to narrow down than most programming mistakes. A lot of progress in IT depends on engineers like this, who obsessively solve problems even when it's much easier to just ignore them, try to hack around them or pass the buck around. Kudos.
A pertinent addition to the submission would be which CPUs have been found to be affected.
The second link says Opteron 6168 and Phenom II X4 820. For a second I thought that bulldozer hasn't managed to do anything right, but these two examples are pre bulldozer.
No doubt this is not an exhaustive list.
Windows? Does this mean that those users and devs aren't so important as far as total CPU load?
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
Anyone know if that "Test case" image is available? I'd like to check if my Phenom II x6 is affected.
Interestingly enough after mentioning this to my dad, his reply was 'It sounds like crosstalk in the decoder logic (this may be slightly inaccurate since my memory is lousy). So hopefully it's microcode fixable, but given how long it's taken to track down, I assume it hasn't bitten nearly as many people as it should have. Although I have had a number of quirky crashes running an overclocked sempron that sounds very similiar to what this was doing.
Ohh, I'm sure AMD will want you to believe that :-)
-- no sig today
FWIW:
The failure has been observed on three different machines, all running AMD cpus. A quad opteron 6168 (48 core) box, and two Phenom II x4 820 boxes.
When information is power, privacy is freedom.
Indeed. I instantly thought of the microcode update as well.
Their other options are to do a processor recall (like Intel + the infamous Pentium bug), or inform the compiler manufacturers that 'there be the dragons' (special case inserted into the code for the affected processor / architecture to bypass the affliction).
I am John Hurt.
I have to worry about stack smashing bugs here... can there be a way for (say) a data pattern in a media file, or carefully crafted javascript or java code that's been JIT-compiled, to break out of its sandbox? What about a hostile OS kernel running inside a VPS container taking over the hypervisor or bare iron? Hmm.
I remember division not being exactly accurate, so the solution I needed to use was to round up and down results that are really close.
Just so you know, division is never accurate in floats, even when the CPU doesn't have bugs. If you're using doubles you'll get better accuracy, but with a 32 bit floating point number, you shouldn't be surprised to find errors in the third digit after the decimal point.
Just to be clear its not limited to division. Hell, errors can creep in just by converting a decimal number to floating point. This is why calculators use decimal arithmetic, well some of them - like Perpenso Calc for iPhone iPad RPN Scientific Stats Business Hex. Try "0.5 - 0.4 - 0.1" in your favorite calculator app, it might indicate whether the app is using the FPU or decimal arithmetic. Of course the app may be doing something naive like the "BASIC MMORG", rounding results. Its naive because it is another source of rounding error, some results are legitimately a little bit off from a nicely round number.
A floating point precision error. Floating points cannot represent quite a diverse collection of numbers, this is especially problematic when you're doing intersections with small objects. Say a ray projected from an object will, because of the minute errors in floating point, collide with the same object (which produces some cool patterns).
Floating points are kind of crappy. Not that I have a better option with viable performance on a desktop machine. That's not a division bug, that's just the nature of representing numbers in binary with a fixed number of bits.
Matt Dillon, desperate after chasing unsuccessfully mary in Something about Mary radically changed jobs and started to study computer science...
Slashdot, fix the reply notifications... You won't get away with it...
Pop two off the stack and ret to the calling routine seems fairly common to me. Lots of functions use two arguments and are called with near calls in various programming languages.
That might have been true on 386s.
But currently we're in 2012 and the most widely used instruction set for Linux on AMD processors is x86_64. Because these 64bit processors feature a big number of registers, the two arguments will be passed as registers, not on the stack. So the sequence of instructions isn't indeed common.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Linux in 64bit mode use register to pass arguments to functions.
So the most common sequence at the end of a function isn't "bunch of pops then a (near) return", but "move the results into target registers and the return".
Thus the bug sequence doesn't happen that often.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
You try and find something that "the other guy" had a problem with and bring it up as worse so as to try and "protect" the thing you are a fan about? Because I see nothing about the FDIV bug anywhere but your post.
Oh and you know what that bug applied to, right? The Intel Pentium, the ORIGINAL Pentium. Not the Pentium MMX, not the Pentium Pro, not the Pentium II, not the Pentium III, not the Pentium 4, not the Core, not the Core 2, not the Core i, not the second generation Core i. And yes, that's how many major processor versions from Intel there have been since then (with another to launch in the next couple weeks). The original Pentium chips that had this problem came out almost 2 decades ago, 1993.
So seriously, leave off it. I get tired of any time there is a problem with $Product_X fans of it will point out how $Product_Y had a similar or worse error way back in the day and that somehow changes things.
No it doesn't. The story is about the AMD chips, nobody gives a shit about the FDIV bug and I'll wager there are people reading Slashdot who weren't alive when it happened.
The good news for AMD is that processors can often patch around this shit in microcode these days so a recall may not be needed. Have to see, but the potential is there for a software (so to speak) fix.
Presumably AMD will announce affected CPUs fairly soon, after they get done testing. This isn't the kind of thing they would be able to sit on, even if they wanted to. If your CPU has been working for you in general it isn't like it is going to suddenly go and beat up your cat or something, it'll be fine for a bit longer while AMD figures out which ones are all affected and figures out how to fix it.
As I noted in another post, depending on it may be possible to fix it via microcode. CPUs aren't "pure" hardware these days. They have a bit of software that tells them how to do things and on some of them (Intel CPUs I know for sure) it is field upgradable. So they may find a way to patch out the bug.
Just keep an eye on their page, maybe send them an e-mail saying you'd like a notice when they know. Should be soon I'd imagine.
for a guy like me, this is pretty much an honest-to-god bughunt ;)
512bit calculations aren't that expensive
Yes they are.
"His name was James Damore."
Except I very much doubt that would solve whatever "problems" this guy was having. As a newbie programmer, it's entirely understandable that he wouldn't know about the fun you can (or can't) have with floating point operations. However, I very much doubt that sheer accuracy was the issue, rather he was probably making assumptions such as 1.0 - 1.0 == 0.0, when in reality the result isn't necessarily exactly 0.0. Considering it's an MMO, he probably had something like "Why is this guy not dying, he has 4 HP left and this attack does exactly 4 damage? Must be a bug!". /* die */", you do something like "if (Health is less than 0.0 + epsilon) /* die */", with "epsilon" being a very small number (such as 0.00000001).
Really, it doesn't matter a huge amount, if such "accuracy" is important to your game then instead of doing "if(Health is less than 0.0)
The real fun with floats, however, is that each platform does something different. It's possible that the OP ran the game on Intel hardware and got one result (which may have seemed more "correct"), then ran it on an AMD machine and got a different (seemingly less-correct) result - you can see why he naturally jumped to the conclusion that the AMD system had a bug.
In reality, chances are both systems were "wrong" anyway, they just happen to use different implementations for floating-point logic. To solve this, once again higher rates of calculations aren't the answer, but rather there's a compiler switch (/fp:strict in VS) that will use the ISO standard floating point model. It's not as fast as the other methods, but you will at least game the same results across different platforms (assuming that CPU has implemented the standard correctly which these days is almost certain).
There's LOTS of fantastic info on this here: http://gafferongames.com/networking-for-game-programmers/floating-point-determinism/
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
The same binary on the same platform (x86 in this case) will render the same results. That's part of the contract of the x86 ISA. However, unless you're using /fp:strict or equivalent in your compiler, just recompiling with ANY kind of changes can alter behavior.
So hopefully it's microcode fixable
Another even easier fix could be to add a (3000 thousandth) compiler option to insert a NOP or two before the RET.
Non-Linux Penguins ?
...the CPUs suck :-)
Actually how (Free)BSD made use of available hardware resources back then in the 90s was the big reason for me to use it instead of Linux.
Okay, you do that in your compiler first, and then we'll add more binary size and i-cache usage benchmarks to our marketing materials...
I am TheRaven on Soylent News
I'm pretty sure that TSMC doesn't even fab AMD CPUs. They did GPUs for ATI, and likely still handle some portion of the discrete GPU parts under AMD; but I believe that AMD CPU production is all still in their formerly-in-house-now-spun-off fabs...
I'm very interested on this, since the original posting by Matt Dillon hints at the bug being present in all Opteron and Phenom models. The bug seems hard enough to replicate, but still, corrupting the stack is no minor detail.
I'm pretty sure it was with the introduction of the Pentium (which had the famous FDIV bug) that John Carmack officially made the switch to single precision FP for most things because it was finally fast enough. FP wasn't cheap, per se, but the simplification it brings over keeping track of binary points and precision/range tradeoffs in integerized algorithms should not be underestimated either.
For example, if I want to do a floating point multiply and add, I just say: f3 = f0 * f1 + f2. Before I even start writing a fixed-point multiply and add, I need to ask what the Q points (binary points) are for each of the terms, what Q point you'd like for the result, and what sort of rounding (if any) the result requires for stability. You can end up with a monstrosity like this, assuming all four numbers are at the same Q point:
x3 = (int)(((long long)x0 * x1 + (1LL > Q) + x2;
Ok, maybe you hide that behind a macro, but what about cases where some of the terms are at different Q points? A fully general macro (which is no fun to write, BTW) would also have a ton of arguments, and only reduce you to something like x3 = FXMULADD(x0, Q0, x1, Q1, x2, Q2, Q3); which won't win you any awards in the clarity department.
And look at the operations themselves, too. You have type promotion, extra adds and shifts... the instruction sequence itself isn't super efficient. It pays off when floating point takes 10s and 100s of cycles, but is a dubious win when most of the core FP starts coming down into the single digits. With the Pentium's dual pipes and the fact you could keep integer instructions flowing in parallel to the float, that's effectively what happened. And notice we haven't even talked about dynamic range and overflow errors and how they screw you up. If you have to add tests for that... yuck. With floating point, you degrade gracefully if your dynamic range spikes a little higher than you expect.
Anyway, getting back on topic: This isn't the first time an x86 has had a stack-pointer related bug. I remember the 80386s that had the so-called "POPAD bug". That one was a bit easier to hit.
Hopefully, AMD will be able to publish a microcode update or something to work around theirs. That's one thing modern x86s have over their predecessors: A good number of CPU bugs can be patched around with microcode updates. I believe Intel added that with the Pentium Pro, and AMD followed suit. I believe my Phenom is one of the affected parts. I guess I'll have to keep an eye out for such a patch.
Program Intellivision!
Ugh... this expression was correct when I typed it. Part of it got eaten due to missing HTML escapes. Grrr...
x3 = (int)(((long long)x0 * x1 + (1LL << (Q-1)) >> Q) + x2;
Program Intellivision!
Then why has it only been seen on DragonFly BSD?
My opinion is that the sequence that leads to the bug is rare. DragonFly BSD happen to have it somewhere (due to sheer luck, because otherwise the sequence is uncommon) and under some stress condition, the bug got triggered.
Under the same stress condition Linux didn't barf, simply because the sequence is so rare that the Linux kernel didn't have it.
Can someone do some screening of the binary image of a few kernels and see how common is the pop-pop-nearret sequence ? :-P )
(Lazy and don't have the material to do it here now
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
AMD has indicated to me that the Bulldozer is not effected, which is a relief.
I guess I should have realized this would get slashdotted. In anycase, it took quite a bit of effort to track the bug down. It was very difficult to reproduce reliably. It isn't a show stopper in that it really takes a lot of work to get it to happen and most people will never see it, but it's certainly a significant bug owing to the fact that it can be reproduced with normal instruction sequences.
I began to suspect it might be a cpu bug last year and after exhaustive testing I posted my suspicions in December:
http://leaf.dragonflybsd.org/mailarchive/kernel/2011-12/msg00025.html
Older versions of GCC were more prone to generate the sequence of POP's + RET, coupled with a deep recursion and other stack state, that could result in the bug. It just so happened that DragonFly's buildworld hit the right combination inside gcc, and even then the bug only occurred sometimes and only one a small subset of .c files being compiled (like maybe 2-3 files). The bug never manifested anywhere else, doing anything else, running any other application. Ever.
In particular the bug disappeared with later versions of GCC and disppeared when I messed with the optimizations. We use -O by default, not -O2. The bug disappeared when I produced code with gcc -O2 (using 4.4.7).
It is really unlikely that Linux is effected... the sensitivity to particular code sequences laid out in the compiler is so fine that adding a single instruction virtually anywhere could make the bug disappear. Even just shifting the stack pointer a little bit would make it disappear.
In anycase, for a programmer like me being able to find an honest-to-god cpu bug in a modern cpu is very cool :-)
-Matt
It affects the Opteron -- used in, for example, the SUN X series servers (Dell and HP also use it).
So, these are in a lot of "mission critical" financial and other applications. The preferred fix is a microcode update. A recall would be an alternative, but the costs of that would be enormous. And AMD would be expected to cover it.
If a suitable microcode update cannot be pushed, I would short AMD. This has the potential to kill the company, especially considering the other problems they are having now.
I don't believe that a compiler modification would be a suitable fix. That would require building and QA'ing the entire software stack (as it is a "software change"). A very expensive proposition. My recommendation would be to lean on AMD, and get a "hardware change", either as a microcode patch or a new processor. That way, the bulk of the expense gets pushed back to AMD.
Just another "Cubible(sic) Joe" 2 17 3061
"there is never any need for self modifying code"
I'm sorry to burst your bubble, but the linux kernel uses self-modifying code to provide the ability to build a kernel that will boot on many machines but can still be tweaked at boot to run faster depending on what the cpu supports.
Actually I believe some of the APUs such as the Brazos platform is done by TSMC. Yes according to this link they inked a deal with TSMC to use their SOI process for Fusion APUs and since i can't find any links saying this deal was later canceled i have to assume that is what they did. Makes sense as TSMC has the experience with ATI GPUs and the whole point of Fusion is wedding the ATI GPU to various AMD CPUs such as Stars (Liano), Bobcat (Brazos) and Bulldozer (FX) and since the overall performance of those chips would depend on how well they could get the GPUs to come out since they can't really bin the GPUs like they normally do without ending up with a bazillion variations it makes sense they went with the one that has more GPU experience.
So does anybody have any REAL info on what's going on? What chips? What sockets? Is it only on server, or is desktop and mobile affected as well? Is it a one in a million bug or an easy to hit bug? Considering CPU bugs can go from the Pentium I "you'll likely never hit it" to the Phenom I quad "Good luck getting above 2.4GHz because the third core (Core 2) is buggy and unstable" there can be a pretty wide variance when it comes to odds. As someone who owns several AMD units and have sold even more some more info would be nice.
ACs don't waste your time replying, your posts are never seen by me.
Intel has had quite a few serious chip bugs too, all in errata. A number of new cpu bugs in both AMD and Intel chips always appears in new generations, but both companies have very large test suites and the number of new bugs goes down in every generation.
Don't forget that Intel had to recall a sandybridge chipset early in the sandybridge cycle, which cost them something like a billion dollars because the related motherboards had to be thrown away and replaced. That was due to internal on-chip circuitry related to a SATA port burning out.
Right at this moment AMD has two issues facing it in order to compete on workstations: (1) Power and (2) Performance. Their initial bulldozer release clearly depends too much on compiler optimizations to make full use of the architecture. They will clearly have to bulk-up some of the simplifications they made that made their cpu cores a little too sensitive to instruction sequences generated by compilers and I hope their next few releases will do better.
On power consumption it comes down to the Fab as much as anything else. Their dependence on the Fab is clearly a problem and they've made a break for it to try to solve it, even though it is costing them dearly. At the same time Intel has made some major advances in their three fabs, to the point where Intel can do their entire production on just two of those three fabs now but they decided to keep the third fab because they think they can 'grow into' it.
So AMD definitely has some work ahead of it, and I am hoping they reserve some of their focus for the high-end and don't concentrate entirely on laptops. I always like to say that I love AMD, but in the stock market I invest in Intel. That's just business. But I got on the AMD bandwagon big-time when they got to 64-bit first and I stuck with them all the way through the Phenom II.
Now, at this moment, Intel's SandyBridge has the best value and AMDs bulldozer is quite far behind, so new purchases for me right now are Intel. That may change in the next year or two and when it does my new purchases will happily be in the AMD camp again. Frankly, AMD only has to get within shouting distance (~8%) of Intel and I will happily use AMD. AMD doesn't have to beat Intel.
I think there are a number of things AMD can do right now to compete better with Intel. One of the biggest is in the mini-server department (albeit clearly with lower volumes than their current focus on laptops & integrated graphics). AMD consumer cpus (aka Phenom II) always had ECC support but very few motherboards actually supported it, which made it difficult to use AMD for mini-servers and avoid the Intel Xeon tax to get ECC. If AMD worked on the mobo vendors to ALWAYS support an ECC option that would allow them to compete against Intel Xeons on price, even if they are unable to compete on performance.
On the opterons AMD clearly has the right idea going with high-core-count cpus, but the memory subsystem is lagging too much to really be able to make use of all those cores. That seems to be low-hanging fruit to me, something which should be readily addressable by AMD. The opterons still have a lot of value and potentially can have a radical improvement in value with Bulldozer, but only if AMD can push the core count and improve the memory subsystem.
On large multi-core boxes AMD also needs to improve CMPXCHG and other atomic instructions in situations where contention is high. Right now multi-chip opteron systems seriously lag Intel on contended latency due to cache coherency inefficiencies. Will Bulldozer fix those latency issues? I don't know.
AMD only needs to get within shouting distance of Intel for me to buy their chips, and work their mobo producers a bit more to get better overall support for their chip's capabilities. They don't have to beat Intel.
-Matt
Um.... gpu's work on floats. I specifically know about the problem because I discovered it using GPU's for something. I only noticed it because I had the same problem ray tracing.
Floats are floats. the IEEE specifies how they behave. GPU's happen to be able to crunch a lot of them compared to a CPU, even when it's actually implementing the floating point specification correctly (early GPU's didn't quite). It's a matter of the capacity to represent decimal numbers in binary. When you only have X bits for mantissa, Y bits for an exponent there's only so much you can do. It's not a matter of a particular brand of hardware having precision, they're all the same, or supposed to be.
And yes, fixed point was the way to go, but for today, floats are probably your best bet performance wise, you just need to be aware that they will have errors because you just can't represent some numbers differently in floating point.
Once in the late 1990's we had a weird bug where FTPing or RCPing a particular file between two offices would often result in a corrupt file on the other end. We kept scratching our heads trying to figure out what could possibly be corrupting the file. FTPing it anywhere else succeeded... no corruption. Everything else between the offices seemed to work ok.
It wound up being a hardware issue with the T3 between the two offices. The hardware would corrupt the bitstream in a manner that tended to PASS the TCP/IP checksum, resulting in corrupted data. It required a particular pattern of 1's and 0's for the bitstream to be corrupted in a manner that passed the checksum, which this particular file happened to have.
These days, of course, I use scp to transfer files whenever possible. SSH will detect that sort of corruption and fail with a protocol error. Encryption has certain uses beyond just encrypting the data, it seems!
-Matt
a hardware issue. When it is developed by someone else, then it is a software issue, at least that is what I tell my boss.
then ran it on an AMD machine and got a different (seemingly less-correct) result
You are mistaken. The floating point bug was in Intel processors, not AMD.
http://en.wikipedia.org/wiki/Pentium_FDIV_bug
If it's in you sig, it's in your post.
No, you are mistaken because you didn't read my post (or any of the posts above it). We're talking about floating point rounding irregularities that are present in ALL modern processors, not the floating point bug you're referring to.
In any case, there is a different floating-point bug that affected some AMD CPU's as well - http://www.reghardware.com/2006/04/28/amd_opteron_fpu_bug/
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
I stand by my original post.
I did not take issue with the floating point irregularities. In fact, I also believe that the issues he experienced were not due to the FDIV problem he believed to be the cause. I probably would have used the fact that the last release of QuickBasic was in about 1989, before the widespread inclusion of FPUs in PCs, and that QuickBasic would almost certainly use software emulation for floating point arithmetic. It therefore would not have triggered a bug with the FDIV instruction.
What I did take issue with was your notion that he would have run on the AMD chip and seen a less accurate result. As I said, the bug he was talking about was the FDIV bug.
The idea that the QuickBasic would trigger an overheating-related bug on a 2006 Opteron is even more laughable than the OP's original troll post. :p
If it's in you sig, it's in your post.
I would argue that if 32 bit (or maybe 64 bit) isn't enough, then you might want to be partitioning up your space anyways. Actually, if you're implementing more than rudimentary physics then it's a good idea to do anyways for optimization's sake.
I read TFA and all I got was this lousy cookie
I never said that he would have seen a less accurate result, I said he would (or may have) have seen a seemingly less accurate result simply due to the fact that different hardware will give slightly different results. In the above example of 4.0 (health) - 4.0 (damage), it's entirely possible that one system would truly calculate 0.0, while another would calculate 0.00000000000000001. The point is, when dealing with floating point numbers if you get 2 different results and are unaware of the complexities of floating point operations, it's a logical conclusion to believe that one may be right and one may be wrong (even though both are technically as right/wrong as each other). I wasn't saying that the AMD system gave an incorrect result, just that it may have appeared to from his perspective. A quick google of "AMD CPU floating point incorrect" would have certainly brought up an article or two detailing a known bug, even though it didn't actually affect him.
However, you raise a point about QuickBasic. If it truly does use software floating point calculations, then the above point is moot. Since it's entirely speculative anyway, it doesn't really matter. All I was doing was demonstrating as to how an inexperienced programmer can come to a certain conclusion through no real fault of their own.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Given the range of clock speeds and devices (a 1.9GHz Opteron and a 3GHz Phenom II), that seems unlikely to me. If I'm not mistaken, they're even in different technology nodes (65nm vs. 45nm). So, an electrical issue seems unlikely to me. It seems more likely to me that it's a return-stack related logic issue, since it affects a deeply recursive function.
Since it happens only when the system is under load, I'm guessing you need a well timed cache miss or TLB miss to make it happen. The NOP that "fixes things" may be forcing some serialization which prevents the code above it from interfering with the function epilog.
Program Intellivision!
TCP's checksum is notoriously weak though. For example, if you send a file filled with 0xFF, 0x00, 0xFF, 0x00.., but that triggered a 1 bit shift framing error so it came out, say, 0xFE, 0x01, 0xFE, 0x01, the TCP checksum would be the same for both. Heck, you can even swap bytes and TCP won't notice, since the TCP checksum is just a 1s complement 16-bit sum.
I'm going to guess that just about any fancier checksum probably would have caught the problem. Even a plain 16-bit CRC.
Program Intellivision!
Anyway, getting back on topic: This isn't the first time an x86 has had a stack-pointer related bug. I remember the 80386s that had the so-called "POPAD bug". That one was a bit easier to hit.
Hopefully, AMD will be able to publish a microcode update or something to work around theirs. That's one thing modern x86s have over their predecessors: A good number of CPU bugs can be patched around with microcode updates. I believe Intel added that with the Pentium Pro, and AMD followed suit. I believe my Phenom is one of the affected parts. I guess I'll have to keep an eye out for such a patch.
I was thinking... how the heck does he remember that flaw.
Then I saw your UID. Good job, carry on sir.
-AI
For me, it is far better to grasp the Universe as it really is than to persist in delusion
The AMD CPU was probably designed in the US and made in Germany.
We're talking about floating point rounding irregularities that are present in ALL modern processors
No, only those that work in binary ;-)