Read more.Affects unknown families of processors under heavy load in rare test case.
Read more.Affects unknown families of processors under heavy load in rare test case.
Well, not as bad as Intels FDIV bug at least!
Main PC: Asus Rampage IV Extreme / 3960X@4.5GHz / Antec H1200 Pro / 32GB DDR3-1866 Quad Channel / Sapphire Fury X / Areca 1680 / 850W EVGA SuperNOVA Gold 2 / Corsair 600T / 2x Dell 3007 / 4 x 250GB SSD + 2 x 80GB SSD / 4 x 1TB HDD (RAID 10) / Windows 10 Pro, Yosemite & Ubuntu
HTPC: AsRock Z77 Pro 4 / 3770K@4.2GHz / 24GB / GTX 1080 / SST-LC20 / Antec TP-550 / Hisense 65k5510 4K TV / HTC Vive / 2 x 240GB SSD + 12TB HDD Space / Race Seat / Logitech G29 / Win 10 Pro
HTPC2: Asus AM1I-A / 5150 / 4GB / Corsair Force 3 240GB / Silverstone SST-ML05B + ST30SF / Samsung UE60H6200 TV / Windows 10 Pro
Spare/Loaner: Gigabyte EX58-UD5 / i950 / 12GB / HD7870 / Corsair 300R / Silverpower 700W modular
NAS 1: HP N40L / 12GB ECC RAM / 2 x 3TB Arrays || NAS 2: Dell PowerEdge T110 II / 24GB ECC RAM / 2 x 3TB Hybrid arrays || Network:Buffalo WZR-1166DHP w/DD-WRT + HP ProCurve 1800-24G
Laptop: Dell Precision 5510 Printer: HP CP1515n || Phone: Huawei P30 || Other: Samsung Galaxy Tab 4 Pro 10.1 CM14 / Playstation 4 + G29 + 2TB Hybrid drive
"Matt himself stated that the bug was so difficult"
Yawn!! So just another example of errata then?? All Intel and AMD CPU families have errata lists.
The tech press seems more like a load of tabloids.
Last edited by CAT-THE-FIFTH; 06-03-2012 at 11:32 AM.
http://download.intel.com/design/pro...pdt/322166.pdf
errata ist for Intel i5 ^^ notice how many have ` No Fix` attached.
I have to agree this is just a normal errata class bug. This should not have any impact on AMD sales or reputation.
Perhaps just the way it was discovered is interesting and news worthy!
interesting to see that real world use of BD , users are actually happy....
Indeed, it's rare for an end-user to discover a CPU hardware bug! As a programmer it's something you don't want to consider and from what I gather it took the chap over a year to track down.
But also it's PR in that, it had been reported before HEXUS picked it up and not in-depth, if you're not as knowledgeable of CPUs, what would you think?
As requested: http://thread.gmane.org/gmane.os.dra...d.kernel/14471
CAT-THE-FIFTH (06-03-2012)
Indeed, but I wonder if, with enough work, one could get a better idea of how the stack pointer corruption occurs and engineer a situation in which a jump to a specified memory location could be achieved.At the very least, the bug results in a crash as opposed to the CPU presenting incorrect data to a program
I'm going to suggest something potentially dumb (in which case take pity on me) but if it's "a very specific sequence" that's required to cause this to happen, then surely it'd be possible to put in a compiler fix to ensure that it doesn't ever generate this sequence? Assuming that this issue is a big deal, and not one of those "1 in a billion operations" type events.the bug was reproduced by creating a test-case that, "through a very specific sequence of consecutive back-to-back pops and (near) return instructions, can create a condition where the process incorrectly updates the stack pointer," leading to a segmentation fault.
That's exactly what you do, crossy. The irony of course was that it was code in a compiler that actually caused the crash... so the compiler needs recompiling.
That doesn't stop somebody writing assembly code to create the same bug, however... but as long as there's no security issue surrounding this bug (see my previous post), that's not a problem.
No, it is a bug in the processor. However, the compiler was the only thing so far that's been shown to run the sequence of instructions that cause the bug
So it's easy enough to work around.
crossy (07-03-2012)
There are currently 1 users browsing this thread. (0 members and 1 guests)