Building a new PC

The SSD is sitting in an enclosure and working just fine.
But it also ran just fine installed in the PC for 5 days too. So does it really run just fine in the enclosure, or has it just not acted up - yet?

Handy with a multimeter to see what your voltages are with the system under load?

Acceptable Tolerances:

12VDC ±5% = 11.4 to 12.6VDC
5VDC ±5% = 4.75 to 5.25VDC
3.3VDC ±5% = 3.14 to 3.47VDC​

The problem is, it seems intermittent problems always see you coming and don't misbehave when testing. :r1:

What does HWiNFO64 show for your voltages? While software based monitors depend on low-tech sensors, they at least get their readings from the motherboard (after the voltage dividers/regulators) and not the PSU itself.
 
The SSD is sitting in an enclosure and working just fine.
But it also ran just fine installed in the PC for 5 days too. So does it really run just fine in the enclosure, or has it just not acted up - yet?
Difficult to say for sure. I put the SSD back in the system and connected it to SATA 5. I'll try SATA 3 next since that has seemed reliable with my secondary SSD. If those fail, I will install on a reliable HDD and put the SSD in an enclosure to see how it behaves in the enclosure and how the HDD behaves with the motherboard.

Handy with a multimeter to see what your voltages are with the system under load?
12VDC : 12.168 V
5VDC : 5.010 V
3.3VDC : 3.284 V


What does HWiNFO64 show for your voltages? While software based monitors depend on low-tech sensors, they at least get their readings from the motherboard (after the voltage dividers/regulators) and not the PSU itself.
I am not seeing any readings for voltages through HWiNFO64 outside of the CPU voltage.
 
Well, nothing wrong with those - at least not at this moment. Granted, I am fishing. :huh:
 
I'll test the SATA ports. If the problem remains, I'll test with an HDD. If the problem still remains, I'll probably RMA the motherboard. I suspect the motherboard above the PSU at this point since the SSD tends to disappear when the system is under very light load to medium load.

I have a strong suspicion right now that this SSD and this motherboard do not get along.
 
Last edited:
Interesting. My motherboard has a BIOS update for an Intel HT issue. I did a bit of research and found the following:

Major flaw found in Intel CPUs and HT, needs BIOS fix
Hyper-Threading flaw in Intel Skylake and Kaby Lake CPUs requires BIOS microcode fix

TweakTown
If Intel wasn't already in enough trouble with AMD's constant onslaught of products with Ryzen and now Ryzen ThreadRipper, the company is now going to have a huge storm surrounding it over a newly-discovered flaw in Intel's Skylake and Kaby Lake architectures with Hyper-Threading.
The HT-enabled processors with critical flaws were discovered on the Debian Linux user list, and sent out without a warning notification - but these issues extend to Windows, and other operating systems
The problems surrounds Intel errata documentation, explained as:
Errata: SKZ7/SKW144/SKL150/SKX150/SKZ7/KBL095/KBW095
"Short Loops Which Use AH/BH/CH/DH Registers May Cause Unpredictable System Behavior."
Problem: "Under complex micro-architectural conditions, short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) may cause unpredictable system behavior. This can only happen when both logical processors on the same physical processor are active."
Implication: "Due to this erratum, the system may experience unpredictable system behavior."
The report from Debian recommends disabling Hyper-Threading until it gets fixed, which is where the fixed microcode and BIOS/UEFI updates. Motherboard vendors will be issuing new BIOS/UEFI updates in the near future if they haven't already, with HH reporting that users "should look for a BIOS/UEFI update which fixes "Intel erratum SKW144, SKL150, SKX150, SKZ7" for both Skylake and Kaby Lake processors".
Kaby Lake is a little bit of a mixed bag, with Intel's latest April 2017 microcode update now a few months old, but has revisions 0x5d/0x5e that might fix these issues for Kaby Lake CPUs with signatures of 0x806e9 and 0x906e9. But, as HH points out, the "safest course of action is to disable HyperThreading for now".
 
Crucial advisor tool says: http://www.crucial.com/usa/en/compatible-upgrade-for/GIGABYTE/ga-z270mx-gaming-5
Your MB QVL says:
  1. SSD: SSD122 Crucial SATA3 MX300 CT2050MX300SSD1 / 2050GB 2050GB
  2. M.2:
    • M2S09 Crucial SATA3 N/A 2280 SATA B / M 500 CT120M500SSD4 128GB V N/A
    • M2S22 Crucial SATA3 N/A 2280 SATA B / M M550 128GB CT128M550SSD4 128GB V N/A
    • M2S31 Crucial SATA3 N/A 2280 SATA B / M MX200 CT250MX200SSD4 250GB V N/A
  3. U.2: no crucial
 
Last edited:
Crucial advisor tool says: http://www.crucial.com/usa/en/compatible-upgrade-for/GIGABYTE/ga-z270mx-gaming-5
Your MB QVL says:
  1. SSD: SSD122 Crucial SATA3 MX300 CT2050MX300SSD1 / 2050GB 2050GB
  2. M.2:
    • M2S09 Crucial SATA3 N/A 2280 SATA B / M CT120M500SSD4 128GB V N/A
    • M2S22 Crucial SATA3 N/A 2280 SATA B / M M550 128GB CT128M550SSD4 128GB V N/A
    • M2S31 Crucial SATA3 N/A 2280 SATA B / M MX200 CT250MX200SSD4 250GB V N/A
  3. U.2: no crucial

Huh, I had no idea they listed SSDs in the QVL. That was enlightening and may explain the issue. Thanks!

The Crucial drive I have wouldn't be listed as a compatible option through Crucial because it was discontinued. It is not on the motherboard QVL, though, so maybe?
 
Last edited:
It seems like gygabyte has tried only one model of these series: M500, M550, MX200, MX300.
Then they assumed other models could work.
The MX100 series doesn't appear at all.
Could it be they didn't even try one model of that series?
The MX300 series consists of 7 models and crucial says all of them can work with your MB, but only one of these models is present in your MB QVL.
Differences found on their pdf datasheets (i.e., "on the paper"):
MX100
• Native Write Acceleration
• Exclusive Data Defense
• Power Loss Protection
• Error Correction Code (ECC)

MX300
• Dynamic Write Acceleration
• Multistep Data Integrity Algorithm
• Power Loss Protection 4
• Device Sleep Support
 
Have you tried disabling HT to test?

I updated the BIOS. I think I am going to move to an M.2 drive that's in the QVL and be done with the SSD issues. I'll use this SSD as an external drive and see how it behaves. It was fine in my previous system, so I suspect this to be some compatibility issue over an issue with my motherboard or SSD. My other SATA devices work fine with the motherboard, and my SSD seems to work fine when not connected to the motherboard.
 
Any suggestions on stress testing to find out?
Sorry, but no.

I don't know why SSDs are listed in QVLs - other than for the interface they use.

My other two SATA devices function fine with the motherboard. The SSD seems to function fine when it is not connected to the motherboard. I do suspect the QVL may be worthwhile for SSDs based on this experience. My gut has been telling me this is a compatibility issue pretty much from the start. Worst case, I end up RMAing the board somewhere down the line but have a better SSD through the M.2 interface for my debugging logs' read/write speeds. That wouldn't be a horrible outcome, but I am fairly sure an RMA won't be necessary.
 
Last edited:
I've now officially ruled out the motherboard for the SSD disappearing. It happened again today with the drive in my laptop. The drive itself is having issues. Crucial wants me to use the default Microsoft SATA driver instead of the Intel version to see if the Intel driver is causing the drive to power off due to the power loss protection in the SSD.
 
I'd gave no qualms about using the MS SATA driver, it works fine W7>10, maybe a tad slower than some OEM drivers, it allows TRIM and it's already running alongside the IRST ones anyway. I use them in preference to the Intel/WU Intel drivers - 4 fewer 3rd party drivers running is fine by me ;)
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top