Search the Community
Showing results for tags 'corrupt'.
Found 1 result
-
I'd like to draw attention to an issue I've experienced with Corsair iCUE 5. I recently had a problem where my computer would refuse to boot running everything at stock configuration as iCUE had erroneously written bad data to the SPD chips on all four of my RAM modules (all CMK16GX4M2B3200C16 modules). Here's the relevant thread I posted on the LTT forums, with my solution post at the end explaining the issue in great depth. System specs also posted there. The summary is that I was using iCUE 4 as I had been for a long long time and got an upgrade notification to install iCUE 5, so I did the update and it was all seemingly fine. A couple of days later I then wanted to clear my BIOS settings and install a new BIOS version. I removed the CMOS battery to clear everything and then attempted to reboot my system so I could flash the new BIOS, however my system managed to complete the POST. After much troubleshooting and banging my head on the wall, I noticed one of my modules was showing the JEDEC 2133 MHz profile as being able to run at 1.0 V which is entirely wrong and out-of-spec for desktop DDR4. After several more hours of troubleshooting and finally being able to get into the BIOS once more so I could reapply the XMP profile - which thankfully was not affected - I could get into WIndows and do more investigation. I opened Thaiphoon Burner and it confirmed all four of my modules had CRC errors, all at the exact same offset of 0x0B (11) bytes in their SPD data. After reading the JEDEC DDR4 SPD specification, I determined that the reason for the erroneous 1.0 V being shown on the JEDEC profile is because byte 11 determines the voltage the module supports. I had to fix this manually by hand by going into Linux, disabling all IO memory and ACPI restrictions, loading the I2C & SMBus kernel modules and then individually correcting the corrupted bytes using i2c-tools and then confirming the CRC was good in Thaiphoon Burner and comparing it to their database of known good SPD dumps. Big thanks to Softnology for their software because I wouldn't have been able to solve this without them. The bigger issue here is that iCUE 5 must have an issue with doing dirty writes on the SMBus. Which not only should it not be doing to being with on RAM modules which don't have RGB, but not waiting for the SMBus to be free before performing those write operations. A Corsair software engineer needs to look into this, writing random things to system memory with a kernel level driver isn't the sort of thing you want to be doing on customer's systems if you want them to ever purchase your hardware or use your 1.1 GB software suite for controlling fan speeds and RGB lighting again. I'd used OpenRGB in the past and never had an issues, iCUE 4 - even with all of its shortcomings - didn't have these issues. Please look into this issue as this is a serious problem that a lot of customers won't have the knowledge to debug and will just return their memory as faulty. Slightly more concerning now is that I have to wonder is: where else was iCUE doing writes to memory that it really shouldn't? Can I trust the software not to write garbage data into kernel memory? Motherboard firmware regions? Graphics card memory mapped space? It is deeply concerning and disappointing. Thank you edit: I want to confirm that no other piece of user installed software had access to the SMBus
