Subject: General Tech | April 11, 2019 - 12:25 PM | Jeremy Hellstrom
Tagged: WPA3, wireless, security, bug, dragonblood, sae
WPA3 is a year old and it seems it has a few flaws which still need to be ironed out, though it can still offer better protection than WPA2. The Inquirer describes this flaw in Simultaneous Authentication of Equals (SAE) handshake, dubbed Dragonblood, in this recent article. It is not a theoretical architectural flaw, indeed the researchers that discovered it could make use of it to brute-forcing an eight-character lowercase password with about $125 in Amazon EC2 instances; not good for a protocol which was intended to prevent all dictionary attacks.
The good news is that a change in the SAE algorithm could mitigate this specific flaw and as WPA3 is not yet widely adopted that is something which could be done before it does start to become mainstream.
"Launched in January 2018, WPA3 uses the Advanced Encryption Standard (AES) protocol to improve WiFi network security. However, a new research paper published by Mathy Vanhoef and Eyal Ronen shows that the protocol may not be as safe as previously thought."
Here is some more Tech News from around the web:
- Implementing Qi Inductive Charging Yourself @ Hackaday
- Orders from Huawei, AMD key to driving TSMC growth in 2Q19 @ DigiTimes
- Intel brings Optane and QLC NAND to a single M.2 memory chip @ The Inquirer
- Windows Subsystem for Linux distro gets a preening, updated version waddles into Microsoft's app store @ The Register
- Amazon Workers Are Listening To What You Tell Alexa @ Slashdot
- China responsible for just, oh, 20% of global semiconductor revenue in 2018, no biggie @ The Register
- The Witness Is FREE For A Limited Time! Get It Now! @ TechARP
Retesting the 2990WX
Earlier today, NVIDIA released version 399.24 of their GeForce drivers for Windows, citing Game Ready support for some newly released games including Shadow of the Tomb Raider, The Call of Duty: Black Ops 4 Blackout Beta, and Assetto Corsa Competizione early access.
While this in and of itself is a normal event, we shortly started to get some tips from readers about an interesting bug fix found in NVIDIA's release notes for this specific driver revision.
Specifically addressing performance differences between 16-core/32-thread processors and 32-core/64-thread processors, this patched issue immediately rang true of our experiences benchmarking the AMD Ryzen Threadripper 2990WX back in August, where we saw some games resulting in frames rates around 50% slower than the 16-core Threadripper 2950X.
This particular patch note lead us to update out Ryzen Threadripper 2990WX test platform to this latest NVIDIA driver release and see if there were any noticeable changes in performance.
The full testbed configuration is listed below:
|Test System Setup|
AMD Ryzen Threadripper 2990WX
|Motherboard||ASUS ROG Zenith Extreme - BIOS 1304|
16GB Corsair Vengeance DDR4-3200
Operating at DDR4-2933
|Storage||Corsair Neutron XTi 480 SSD|
|Graphics Card||NVIDIA GeForce GTX 1080 Ti 11GB|
|Graphics Drivers||NVIDIA 398.26 and 399.24|
|Power Supply||Corsair RM1000x|
|Operating System||Windows 10 Pro x64 RS4 (17134.165)|
Included at the end of this article are the full results from our entire suite of game benchmarks from our CPU testbed, but first, let's take a look at some of the games that provided particularly bad issues with the 2990WX previously.
The interesting data points for this testing are the 2990WX scores across both the driver revision we tested across every CPU, 398.26, as well as the results from the 1/4 core compatibility mode, and the Ryzen Threadripper 2950X. From the wording of the patch notes, we would expect gaming performance between the 16-core 2950X and the 32-core 2990WX to be very similar.
Grand Theft Auto V
GTA V was previously one of the worst offenders in our original 2990WX testing, with the frame rate almost halving compared to the 2950X.
However, with the newest GeForce driver update, we see this gap shrinking to around a 20% difference.
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).