CPU/Mobo AMD Bulldozer Discussion Thread

Status
Not open for further replies.
mrcool63 said:
This is from an admin in anandtech... guess you were wrong banik:)

I am sure, I have run more superpi than Anandtech's reviewer or admin. And atleast as far as benching is concerned I am more updated and I am in a team full of best overclockers in US/world, I have never seen and there has been no news that disabling HT improves performance.

For your reference below are two scores, very close clock to clock and the mili second difference can be attributed to hell lot of different things, similary there are hell lot of other scores as well. And I am talking about the extreme high end of overclocking, where this simple step of disabling HT would have been a big news.

Hardware news, Overclocking Competitions, Reviews

Hardware news, Overclocking Competitions, Reviews

Also as Aces said, you have not given any link which justifies the context in which AT admin passed that comment.
 
And now, this
<
Though IMO, it does not affect much, still an errata.

http://www.bit-tech.net/news/hardware/2012/03/06/coder-finds-amd-chip-bug/1?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+bit-tech%2Fall+%28bit-tech.net+feed%29

BSD coder finds AMD processor bug

[font=Arial, Helvetica, sans-serif]

Published on 6th March 2012 by Gareth Halfacree
[/font]
[font=Arial, Helvetica, sans-serif]

article_img.jpg


AMD has admitted that a bug found by BSD coder Matthew Dillon represents a previously unknown erratum in its chips.​
A programmer on the DragonFly BSD project has received confirmation that a bug he'd been chasing for more than a year was the result of a previously unnoticed erratum in AMD's instruction set architecture.

Matthew Dillon had been chasing the bug, which caused a segmentation fault that would crash the system while compiling code, for over a year when he came to the conclusion it resided in hardware. Much of that time was taken up with the rarity of the crash: prior to finding a specific test case for the bug in December last year, Dillon would need to leave a 48-core system running in a loop for up to two days to reproduce the failure.

Dillon's suspicions that the bug came from a hardware issue stemmed from the specificity of the problem: the compiler would reliably crash on a system with an AMD processor, but the exact same compiler working on the exact same code would run forever without issue on an Intel chip.

Having ruled out a software error in the affected section of code - the 'fill_sons_in_loop' segment - Dillon got in touch with AMD with his findings.

'We exchanged a few emails to try to come up with a good test case,' Dillon explains in a posting to the DragonFly project mailing list. 'Owing to the difficulty of reproducing the bug I constructed a fully bootable DFly operating system & test case USB image and verified that the bug was present on my test box using that image. AMD was then able to reproduce the bug using that image on their own machines.'

To Dillon's surprise, AMD confirmed that the flaw stemmed from its processors rather than user error. 'AMD has taken your example and also analysed the segmentation fault and the fill_sons_in_loop code. We confirm that you have found an erratum with some AMD processor families,' the company told Dillon. 'The specific compiled version of the fill_sons_in_loop code, through a very specific sequence of consecutive back-to-back pops and (near) return instructions, can create a condition where the processor incorrectly updates the stack pointer.'

While it's too late to fix the flaw in AMD's current generation of processors, Dillon's work means that the bug will be entered into AMD's official list of errata. As a result, coders can be forewarned as to the issue and work on software-based solutions to work around the problem.

'I'm pretty stoked,' Dillon admits in his post. 'It isn't every day that a guy like me gets to find an honest-to-god hardware bug in a major CPU!'

[/font]

[font=Arial, Helvetica, sans-serif]AMD has yet to release an updated errata sheet for the affected processors.[/font]
 
Status
Not open for further replies.