The Stilt

A working F2A85X-UP4 does not display anything in the segment display if there is no APU installed. Take a bare board (with nothing attached) an measure the resistance between one of the OS-CON capacitors located between the inductors (CPU loop, six inductors located on the left from the socket). The resistance should be around 1.6k (climbs for a while). The resistance for the NB loop (two inductors located above the socket) should be between 2.5 - 2.6k.

When the CPU dies it usually shorts (either VDDCR or VDDNB). Unless the VRM CC protections acts fast enough usually the VRM burns too. In case of a UP4, the VRM CC protection is fast and usually saves the board. If you put a broken APU in the socket and try to start it, the Port 80 segment display flashes briefly and then turns black. Depending on how the APU is damaged, the board turns off immediately or continues running (segment still blank). The most common reasons for a APU to burn is a voltage spike (e.g a large voltage swing from low to high voltage) or simply too high voltage. This is the reason you want to have a smallest possible delta between the cool down (Slowmode) an the running voltage. It will hurt you temperatures, but it will save your APU. In case the VRM fails it usually kills the CPU in about 90% of cases too. And a broken APU can definitely kill a working board too. To check if the CPU core part of the APU (FM2 or FM2r2) is fine: Measure the resistance between the two pins (VDDCR & VSS). Anything under 25 ohms means the APU is burned.

Nice to see that the manufacturers put some interest on AMD platforms too. I guess this is kind of a "avalanche" effect. Hopefully Asus and MSI will arrange (sponsor) their own competitions now too after Gigabyte and ASRock have done theirs.

I've done this for nearly 13 years now and still it is not getting me anywhere. Nowdays it does not matter what you know or how good you are at it, the only thing that matters is who you know. I need to find something that I can get living out from, whatever it might be. Leaving all of this behind is definitely not something I would like to do, but it appears to be the only way to survive. Simple as that. When? Before new year, at latest.

It doesn't do any wonders, the cores will not oscillate (rOSC) any higher than 8.25GHz. I might throw in something better before I am gone for good, thou.

It's the first retail chip I've ever tested. The old ones were early samples (the same ones which were sent to the press).

Streamroller? Whats that? SR stands for Standart Russky.

18/07/2013 update as attachment.

You'll decide. I have not deleted it, the link just seem to have changed(?). http://imageshack.us/a/img823/86/lhdi.jpg

Some of the errata can be only patched by the microcode. Most of the fixes can be done with AGESA but not all. That's why it is necessary to have both of them up to date. The change logs do exist but they are not public.

OrochiPI V1.5.0.5 is the most recent version at the moment. The microcode versions are still up to date (06000822 / 0600063D - Vishera / Zambezi).

The fix should definitely be allowed in HWBot rankings, as at the moment it seems that it is here to stay

A 5.0GHz Vishera with 2750MHz NCLK and DDR-2666 MEMCLK scores around 14min 20 seconds after the BDC R1.02.

No.

A small update: Bulldozer Conditioner R1.02B Original package checksum (MD5): BCC929498EF1B01B7F99B8F2DA805F46 Bulldozer Conditioner R1.02B Mirror: http://downloads.hwbot.org/downloads/tools/BDC_R1.02B.zip Changes: - Enhanced the NRAC fix - Added a UAC prompt (admin rights) for Windows Vista / 7 & 8. - Updated the AGESA version info The enhanced fix included in BDC R1.02B is around 10 seconds faster in SuperPI 32M than the one in R1.00 / R1.01 versions

I might try it at some point. 8-8.2GHz (SuperPI 32M) shouldn't be much of a issue with a proper specimen.

Running SuperPI on LHe is pretty damn expensive. Yes, helium.

The actual technical background is under investigation currently. Until then, I can only speculate and assume: By default a x87 FP instruction is blocked / partially blocked. When the "blockade" is removed (BDC "NRAC": Enabled to Disabled), SuperPI which heavily utilizes this instruction receives a massive boost. It is not a post tape-out workaround. Neither AGESA or µCode control this feature, all of the post tape-out workarounds (errata) are controlled by these two. If it was something that was actually broken, it would have been fixed in Piledriver and beyond. A software doesn't go much more unofficial than BDC does. It should be used for testing purposes ONLY. Obviously it shouldn't be used in systems which can be considered 'critical'.

That result will be demolished in no time. A bit higher MEMCLK and thats it.

Back again. Some of the users have been asking why the "Errata Fix" feature doesn't work (i.e. "Fix required" stated even after the Fix button has been pressed). The feature itself is working fine, however I forgot to add a check in the GUI. Also some claims that the software is wrong when it states that the microcode is outdated has emerged. So: A small update: Bulldozer Conditioner R1.01B Original package checksum (MD5): C3C4E3492B3FBFE1079AE5D57C25172B Changes: - Added a hardware flag to indicate that the errata has been fixed. - Changed the way how the software is accessing the cores, the tasks are completed quicker than before - An APU specific bug fixed - Added information about the most recent microcode and AGESA versions under Info menu. - Some small changes to the GUI

So, it is friday today isn't it Bulldozer Conditioner R1.00B The checksum (MD5) for the zip file is: 418522A93F241CF14EB1D775839AB083 If the checksum does not match the package has been tampered with = delete and re-download from another location. The checksum can be calculated online if you don't have a suitable software on your computer. http://onlinemd5.com/ There is not a single bit of malicious code either in the driver or the software itself. If you are unsure, please check the contents with https://www.virustotal.com Supported OS: Windows XP / Windows Vista / Windows 7 / Windows 8* (32 & 64-bit) * Not tested The x86 version works in both 32 & 64-bit operating systems, while the x64 version is 64-bit only. The functionality itself is identical between the versions. Known limitations: Up to 16 CUs (32 cores) supported at the moment. Support for 32CUs (64 cores) will be added in the next version. Also the R1.00B (Beta) version does not contain the feature to patch the microcode block as I could not make it work stable enough. The "Errata Fix" button will fix the major errata which can be patched without updating the microcode. This feature should not be used as a permanent solution, the bios update should still be used as a primary method (updated AGESA + microcode). Note: Enabling "Zambezi Stack Special (PD)" feature might cause undefined behavior, however each user should test it's functionality on their own. Some applications might indicate a minor r.e.t.a.r.d.a.tion (god damn "specialbunnyaction") in performance, however SuperPI for example receives a nice boost. Note: "x87 instruction (NRAC) block" -> Enabled means that the instruction is blocked (default on all 15h family APU/CPU/NPUs). Disabling it make the SuperPI "a bit" faster. There are most certainly some bugs, so in case you come across one, please report them to this thread. The experiences are very welcome also. No it is time for the midsummer parties so I might be away for a day or two. Depending on how epic the headache shall be

Hopefully you didn't steal that plasticine from a child.

I'm not sure if the difference is still there after the new AGESA & µCode versions. If it is, < 9 seconds will happen in no time. In any case < 9 seconds will be easy on Vishera too. The part I was using yesterday was an ultra low leak / ultra high aq specimen, which maxes out at ~ 1.97V on LN2. During the 9.547 second run on the video, the voltage was around 1.89V during the PI. 1.50000V VID + 0.4V offset, loadline set to 0.525mOhm ("Ultra High"). The newer (packed >= 44/12) FX-8 -series parts should be able to do SuperPI 1M at 8GHz - 8.2GHz, if you have a good specimen of course. My clocks were ~ 7900MHz (31.5 * 250.8) in the 9.547s run. Also disabling the "slave" cores on Zambesi should still help in SuperPI as the remaining "master" core will have a full L2 cache and L3 partition for it's private disposal. For Trinity and Richland there is no difference any more between the masters and the slaves. Not sure about Vishera as its been a while since I tested it. At some point I will see what happens when you have a 4MB L3 cache per CU instead of the normal 2MB. This naturally requires downcoring as only 8MB of L3 physically exists. The same configuration is used in some of the Opterons, FX-4350 and partially in FX-6 series (1x 4MB, 2x 2MB). Of course you could set 4MB for the executing CU, 2MB for the seconds CU and 1MB for the remaining two

If I wasn't so tired currently I would have thrown the setup from the balcony. The motherboard failed.

Yeah. PSCheck for configuration, "Sub-Zero Special" tweak + a physical key to pull the PROCHOT to high / low.