Subject: Processors | March 15, 2017 - 05:51 PM | Josh Walrath
Tagged: ryzen, Infinity Fabric, hwbot, FMA3, Control Fabric, bug, amd, AM4
Last week a thread was started at the HWBOT forum and discussed a certain workload that resulted in a hard lock every time it was run. This was tested with a variety of motherboards and Ryzen processors from the 1700 to the 1800X. In no circumstance at default power and clock settings did the processor not lock from the samples that they have worked on, as well as products that contributors have been able to test themselves.
This is quite reminiscent of the Coppermine based Pentium III 1133 MHz processor from Intel which failed in one specific workload (compiling). Intel had shipped a limited number of these CPUs at that time, and it was Kyle from HardOCP and Tom from Tom’s Hardware that were the first to show this behavior in a repeatable environment. Intel stopped shipping these models and had to wait til the Tualatin version of the Pentium III to be released to achieve that speed (and above) and be stable in all workloads.
The interesting thing about this FMA3 finding is that it is seen to not be present in some overclocked Ryzen chips. To me this indicates that it could be a power delivery issue with the chip. A particular workload that heavily leans upon the FPU could require more power than the chip’s Control Fabric can deliver, therefore causing a hard lock. Several tested overclocked chips with much more power being pushed to them seems as though enough power is being applied to the specific area of the chip to allow the operation to be completed successfully.
This particular fact implies to me that AMD does not necessarily have a bug such as what Intel had with the infamous F-Div issue with the original Pentium, or AMD’s issue with the B2 stepping of Phenom. AMD has a very complex voltage control system that is controlled by the Control Fabric portion of the Infinity Fabric. With a potential firmware or microcode update this could be a fixable problem. If this is the case, then AMD would simply increase power being supplied to the FPU/SIMD/SSE portion of the Ryzen cores. This may come at a cost through lower burst speeds to keep TDP within their stated envelope.
A source at AMD has confirmed this issue and that a fix will be provided via motherboard firmware update. More than likely this comes in the form of an updated AGESA protocol.
Subject: Motherboards | January 28, 2016 - 05:55 PM | Jeremy Hellstrom
Tagged: update, Skylake, gigabyte, bug
Gigabyte has released UEFI updates today which will resolve the freezing issues on Skylake seen in certain circumstances of Prime95 and GIMPS processing. Just head over to their download site and enter in your motherboards model and download the new UEFI, or BIOS if you prefer the old terminology.
As a bonus you may receive the ability to use higher clocked RAM, see any stability issues fixed or better performance from integrated components such as LAN or SATA. Their update process is easy with none of the stress that once accompanied updates via floppy disjs or masks and UV light. We can neither confirm nor deny these updates will also resolve unwanted ear hair growth.
Subject: General Tech | January 11, 2016 - 03:00 PM | Jeremy Hellstrom
Tagged: Intel, Skylake, bug
You may remember the infamous Pentium FDIV bug, which could cause the wrong decimal results to be given in an answer to complex mathematical calculations which caused much consternation among scientists in the early 90's. Now there is a new bug to remember, found on Skylake processors, which can cause the processor to freeze during complex calculations such as you would do in Prime95 or if you contribute to the Great Internet Mersenne Prime Search project. The issue has been replicated on both Windows and Linux systems and on different motherboards, signifying that the issue does indeed come from the CPU. While having a freeze is certainly better than getting an incorrect result, it is still inconvenient and we hope that Intel's BIOS update will arrive soon. You can follow the detection and investigation of the bug and what is being done over at The Register.
"The good news is that the bug's triggered by complex workloads. It was turned up by prime number experts the Great Internet Mersenne Prime Search (GIMPS), who use Intel machines to identify and test new large prime numbers."
Here is some more Tech News from around the web:
- New AMDGPU Details & Looking Forward To Major Radeon Linux Improvements In 2016 @ Phoronix
- HTC Vive VR headset will be available to pre-order from 29 February @ The Inquirer
- Linux 4.4 kernel emerges with better support for Intel Skylake and Raspberry Pi @ The Inquirer
- Nvidia GPUs Can Leak Data From Google Chrome's Incognito Mode @ Slashdot
- Flat Camera Uses No Lens @ Hack a Day
- AVM FRITZ!Box 3490 AC1750 Gigabit Modem Router Review @ NikKTech
Subject: General Tech | December 30, 2015 - 01:35 PM | Jeremy Hellstrom
Tagged: fallout 4, bug, gaming
The Fallout series has never been pacifistic, the isometric originals could allow you to become a drug addicted slave trader however they did not used to be so linear as Fallout 4 seems to be. An inventive gamer decided to try to play the new Fallout without killing a soul and has accomplished that goal after much effort and a few bugs. While it is certainly a blast to roam the wastelands slaughtering all those who get in your way, this article at Kotaku illustrates the problems you can face when playing a game differently than the developers expected you to. The usual, and sadly inevitable game bugs aside, there are quite a few new ones that arise when you get creative with your playthrough. As any DM worth their salt knows, you can never account for everything your players will do and flexibility is a must. One hopes that devs at Bethesda read through this article and expand their creativity as a result.
"Fallout 4 expects you to commit murder. While you can occasionally avoid killing others, the wasteland is ruthless and demands violence. That’s how Bethesda intended the game to be played, anyway—but clever players are finding ways around it."
Here is some more Tech News from around the web:
- Assassin's Creed Syndicate Review @ OCC
- Post-Apocalyptic Isometric RPGing: UnderRail Released @ Rock, Paper, SHOTGUN
- Dark Souls III System Requirements Confirmed @ Rock, Paper, SHOTGUN
- Played Quake Lately? @ [H]ard|OCP
- Have You Played… MS-DOS? @ Rock, Paper, SHOTGUN
- Just Cause 3 Review @ OCC
- Does job vacancy posting point to Elite: Dangerous Linux version? @ HEXUS
- Surprise Homeworld Prequel Attack! @ Rock, Paper, SHOTGUN
Subject: General Tech | May 21, 2015 - 12:40 PM | Jeremy Hellstrom
Tagged: linux, EXT4, raid, bug
On Tuesday a bug was discovered to have been introduced to Linux 4.0 kernel when a fix was added to deal with RAIDs where the chunksize not a power of 2, a problem present since Linux 3.14-rc1. This fix has been causing corruption on RAIDs and the file system on that RAID, making many an unhappy Arch Linux user. Only users of rolling release flavours will be effected, distros with scheduled updates like RHEL or Ubuntu are not effected at this time. The good news is that as of today there is a fix available if you wish to apply it, as well as defining the fix which caused the issue. Check out both at Phoronix.
"A few days ago we reported on an EXT4 file-system corruption issue being discovered within the stable Linux 4.0 kernel series. The good news is the issue has been uncovered and a patch is available, but it could still be a few days before it starts getting sent out in stable updates."
Here is some more Tech News from around the web:
- Boffins have devised TERMINATOR style LIQUID METAL – for an antenna @ The Register
- Build A 1000W LED Flashlight @ Hack a Day
- Qualcomm to step out of TSMC top-5 client list in 2H15 @ DigiTimes
- Take Our Survey: Best Linux Hacker SBCs for Under $200 @ Linux.com
- 'Millions' of routers open to absurdly outdated NetUSB hijack @ The Register
- Google Fiber has taken on a piracy policing role @ The Inquirer
Investigating the issue
** Edit ** (24 Sep)
We have updated this story with temperature effects on the read speed of old data. Additional info on page 3.
** End edit **
** Edit 2 ** (26 Sep)
New quote from Samsung:
"We acknowledge the recent issue associated with the Samsung 840 EVO SSDs and are qualifying a firmware update to address the issue. While this issue only affects a small subset of all 840 EVO users, we regret any inconvenience experienced by our customers. A firmware update that resolves the issue will be available on the Samsung SSD website soon. We appreciate our customer’s support and patience as we work diligently to resolve this issue."
** End edit 2 **
** Edit 3 **
The firmware update and performance restoration tool has been tested. Results are found here.
** End edit 3 **
Over the past week or two, there have been growing rumblings from owners of Samsung 840 and 840 EVO SSDs. A few reports scattered across internet forums gradually snowballed into lengthy threads as more and more people took a longer look at their own TLC-based Samsung SSD's performance. I've spent the past week following these threads, and the past few days evaluating this issue on the 840 and 840 EVO samples we have here at PC Perspective. This post is meant to inform you of our current 'best guess' as to just what is happening with these drives, and just what you should do about it.
The issue at hand is an apparent slow down in the reading of 'stale' data on TLC-based Samsung SSDs. Allow me to demonstrate:
You might have seen what looks like similar issues before, but after much research and testing, I can say with some confidence that this is a completely different and unique issue. The old X25-M bug was the result of random writes to the drive over time, but the above result is from a drive that only ever saw a single large file write to a clean drive. The above drive was the very same 500GB 840 EVO sample used in our prior review. It did just fine in that review, and at afterwards I needed a quick temporary place to put a HDD image file and just happened to grab that EVO. The file was written to the drive in December of 2013, and if it wasn't already apparent from the above HDTach pass, it was 442GB in size. This brings on some questions:
- If random writes (i.e. flash fragmentation) are not causing the slow down, then what is?
- How long does it take for this slow down to manifest after a file is written?
SandForce finally patches elusive 2200 series SSD controller bug. OCZ issues firmware, others soon to follow.
Subject: Storage | October 18, 2011 - 12:25 AM | Allyn Malventano
Tagged: ssd, sandforce, ocz, firmware, bug, BSOD
Over the past few months, we had noted a seemingly disproportionate surge of negative reports from users of SandForce-2200 based SSD's. These include OCZ's Vertex and Agility 3, Corsair's Force 3 and GT, Patriot's Pyro and Wildfire, along with many others. The complete list is available in our handy SSD Decoder.
The issue at hand was random BSOD's, with the possibility of an eventual complete failure of the SSD, rendering it unrecognizeable to the BIOS or Operating System. More details (and the fix) after the break:
I witnessed this personally, as the SF-2281 pictured above suffered the same fate when we attempted to use it a few weeks ago.
Today (hopefully) marks the answer to everyone's prayers. SandForce issued base firmware 3.3.2 for SF-2000 series controllers.
OCZ's Toolbox software V 2.40.02 can patch OCZ's line of SF-2200 SSD's with the new fix.
The release notes follow (and seem to lack mention of the aforementioned bugfix):
OCZ Toolbox version 2.40.02
- Modified Identity data display
- Fixed Smart data display for power fail backup attributes
- Added BIOS update for Hybrid drive
- Update Firmware feature prohibited for primary drives with 1500 & 2000 controllers
- Intel RST Driver 10.1.0.1008 prohibits SSD detection
OCZ's press tidbit for the new firmware(s):
OCZ is pleased to announce that the cause of a BSOD issue experienced by some SF-2000-based drive owners has been identified by OCZ and SandForce. A new firmware update which directly addresses this BSOD occurrence related to SF-2000 based SSDs is available here. All newly manufactured OCZ SF-2000 based SSDs will feature the new 2.15 firmware revision (which is based on SandForce firmware version 3.3.2.) We highly recommend that any customers that have experienced the BSOD issue update their firmware to 2.15.We sincerely appreciate the support from our customers, and if any customers have any questions or require additional support please do not hesitate to contact a customer service representative and we will be happy to address any questions or concerns.
If you own any of the affected SSD's, I highly recommend updating as soon as possible. Until then, I also recommend you back up any data present on these drives, as the above statements confirm the presence of an issue that can potentially brick your SandForce SSD at any moment.
Remember, patch only applies to the 2200 Series controller (i.e. SandForce SSD's capable of SATA 6Gb/sec).