ADAMPOKE111

No problem, man! I'm glad this managed to help someone else! I also complained about the issue on Corsair's forums and they're now aware of the issue and have pulled iCUE 5 for the time being until it's fixed. Apparently the final release of iCUE 4 and the two versions of iCUE 5 were affected. Only once iCUE 5.1 was released did they enable the update notification for people. Here's my thread from the Corsair forum and a temporary fix I posted in another thread there. They also made an announcement on their reddit too. The good news is that they are honouring warranty claims for this - so I'd definitely recommend putting in an RMA and mentioning you have this issue. You should be able to get your modules replaced! Unfortunately I've lost my original proof-of-purchase receipts so I'm not sure I'm gonna be able to do anything, but we'll see. My manual fix using Linux did work as far as I can tell, but I don't know if the issue goes further than that. If you can get into the BIOS and configure the memory to run at a static 1.2 V @ 2133 MHz, or apply an XMP profile: you may be able to put all of your modules in and it should run fine. The SPD data is still corrupted, though, and will either have to be modified into a state where its the same as factory again or replaced under warranty. I'm super happy this helped someone else! Hopefully one day if I go to visit Australia I can claim my free beers hahaha! Always wanted to go there because I reckon I'd do an alright job keeping up with you guys on a night out, being from the UK.

I've solved my issue in the end. It really did spiral out of the scope of what I was initially expecting. For anyone experiencing the same issue (system not completing POST, memory showing wrong voltages, wrong timings, wrong frequencies, etc.) and coming from a search engine, read this! It might help! What initially threw me off is my motherboard was telling me the JEDEC 2133 MHz profile for my modules spec'd them to operate at 1.0 V. Clearly something was wrong there. I didn't count the GIGABYTE UEFI firmware out just yet as being terrible and buggy because they misspelled the word "Profile" as "Proflie" right next to it. I managed to apply the XMP profile which was showing the correct timings and voltages and got into Windows, opened Thaiphoon Burner and ALL four of my modules had a CRC error. Corrupted RAM SPD data. I used their SPD browser to check what the values should be for my modules and sure enough at location 0x0B (11) in each of my modules, there was a corrupted byte. Showing as 00 (hex) for all of them when it should've been 03 (hex). I couldn't manage to actually purchase Thaiphoon Burner so I could repair the byte within Windows as they've suspended regular payments and only accept cryptocurrency now. I read a copy of the JEDEC DDR4 SPD spec. which I downloaded from Thaiphoon's website. Sure enough byte 11 determines voltage. It's actually more complicated than that, each bit of the byte means something. I did some more digging and found someone's blog post about writing to a RAM modules' SPD chip. https://blog.zakkemble.net/modifying-ram-spd-data/ Here they use an Arduino to communicate over I2C (very similar to SMBus which is what the computer uses to talk to it) and modify the contents. I don't have an Arduino on me right now, nor any equipment to probe the tiny pins of the chip, but further down in the post they mention having some luck modifying it on Debian Linux using i2c-tools. I thought I'd give this a try before buying £80 worth of memory to replace mine. I don't know much about I2C and SMBus right now, as I haven't had time to explore it much. I did some reading on OpenRGB's documentation and Arch Wiki's article on I2C and learned I had to load the i2c_dev, i2c_piix4 (on AMD platforms) and i2c_smbus kernel modules at boot, which luckily seem to be included in the kernel shipped by both Arch and Ubuntu from my testing. You can modify /etc/modules-load.d/00-i2c-modules.conf or add the module names to your kernel parameters to load them at boot. I had no success loading them once the system was fully booted. I also had to use the kernel parameter acpi_enforce_resources=lax, and I threw iomem=relaxed in there too for good luck because I had to use that before to update my laptop's UEFI BIOS. Once the system is booted you can use i2cdetect -l to list I2C buses present on the system. I had three SMBuses on mine. Per the blog post, apparently the memory SPD is usually mapped on bus 0 at addresses 0x50 through 0x53 for four memory slot systems. Using i2cget I then checked byte 0x0B on all of my modules as well as some data around it ensure I wasn't about to overwrite something completely incorrect and sure enough - it was here! I then used i2cset in much the same way to set byte 0x0B on each of the modules to 0x03 as they should be and rebooted my system. And sure enough once back in the BIOS the correct voltage was being reported again. I rebooted into Windows and opened Thaiphoon Burner, and I had a green "CRC OK" message in the bottom left corner! Issue fixed! Now, I still don't know what actually caused this initially. I have some confidence in saying it was either OpenRGB or Corsair iCUE (recently updated to version 5) which were doing some dirty writes on the SMBus to places they shouldn't. I have read anecdotes online of people experiencing these programs causing issues like this. I'm slightly concerned where else they might have written things to now! I could go ahead and test OpenRGB and Corsair iCUE again and test to see which one corrupted my RAM's SPD - but I think I'll play it safe so I don't have to go through this hassle again. Hope this helps someone in the future

As it so turns out, the issue has gone a lot deeper than I expected. One of my memory modules is showing the JEDEC 2133 MT/s speed as supposed to be running at 1.0 V, way out of spec. for desktop DDR4. I've popped open Thaiphoon Burner and can confirm there's at least a corrupted byte in there - if not multiple. I don't think this is a BIOS issue, I think this is an issue with RGB software doing dirty writes on the SMBus to memory that it shouldn't... Only Corsair iCUE and OpenRGB can be to blame here... I installed Corsair iCUE 5 recently, I bet it's something to do with that. edit, more detail: For anyone searching the internet and finding this from Google and may also be experiencing one of their modules reporting incorrect timings or voltages - check if your RAM's SPD EEPROM data is corrupted! My stick is corrupted on byte 11 (0Bh) which is the one which determines voltage. It should be 03h, but mine is set to 01h or 05h or something. Unfortunately, I can't write the SPD data without paying for Thaiphoon Burner and I can't even get to the checkout page...

In theory they should both meet the exact same spec - but if you're right do you mean to, for example, put the Samsung C-die modules in Channel A & B slot 1? Then populate the rest? Or put the respective die modules in the same channel: Samsung C-die in channel A1 & 2 and Hynix M-die in channel B1 & 2. My motherboard manual (section 1-4) makes no mention of which slot is primary. I'd assume A1 & B1 are primary, though.

I think something a little funky might be going on with the GIGABYTE BIOS because I put one stick in, set XMP, disabled power down mode, bumped SOC voltage to 1.05 V and the machine booted fine, so I put another stick in and it also works! I then reverted all of those settings again and it still boots! I really really have no idea how that makes any sense. I would love someone to enlighten me.

Ah, my bad. Sorry for the confusion. I meant that I took the battery out prior to doing the update to reset everything to bone stock configuration so there'd been no instability from XMP or PBO or Curve Optimiser or anything. The irony! I can try leaving the memory training going, but I've left it for 10-15 minutes previously and it never seems to get anywhere. 2x 8 GB sticks complete POST in under 5 seconds. 4x 8 GB and it never seems to finish!

Hello all, I have an AM4 X570 system with the following configuraton: CPU: AMD Ryzen 7 5800X Motherboard: GIGABYTE X570 AORUS Elite Memory: 4x 8 GB Corsair DDR4 3200 MHz GPU: AMD Radeon RX 6700 XT I wanted to update my BIOS from F38a to F38b, I removed the CMOS battery from the board, waited for it to clear and put it back in so I could go into Q-Flash and flash the new BIOS, on stock settings. However, upon trying to power up the system, it never seemed to complete the POST. Fans spin, motherboard LEDs turn on, CPU & GPU were getting warm - but even after waiting 5-10 minutes the system never got to the UEFI BIOS. I was banging my head against the wall trying to work out what the issue was, swapping memory modules around, reseating the GPU, etc. This is rather difficult as board vendors like to not include PC BIOS speakers in the box these days... However, through some trial and error I found my system boots with 1 or 2 sticks of memory - but not any more. I can't populate 3 or 4 slots any more. This is odd as I've been running these memory modules at their XMP profile speed of 3200 MHz for over a year with no issue. I tried an individual stick in each one of the slots to ensure the slot or channel wasn't dead - and sure enough they all still work. It is also important to note at this point that even though all of these modules are CMK16GX4M2B3200, they're two separate kits. They all have the same SPD data when read out. Same JEDEC standard speeds, same exact XMP profile on both. Same voltages. Same everything, except for the fact two sticks are version 4.32 (supposedly Samsung C-die memory) and the other two are version 5.39 (supposedly Hynix M-die). What's confusing to me is that this setup was working fine for almost 2 years with no issue at all, but one clear-of-the-BIOS-settings later and it doesn't even boot. I'm at a total loss. I was reading online about increasing memory voltage or SOC voltage or IO die voltage but I've never touched those settings and don't know what the safe ranges are or what's recommended. I hadn't needed to before as it was working fine on Auto everything and XMP enabled. The system works with 1 stick or 2 stick in any configuration - but NOT if I mix the 4.32 and 5.39 sticks. Any help or potential solutions are much much appreciated. Thank you.

I have enabled DSR in the Nvidia Control Panel and I have the option to change to my DSR setting in the control panel and in Windows' settings and it works fine at first - I can switch to it and just use 4K on my 1080p monitor on the desktop like I want to. However, the issue arises when I open CS:GO (in 3840x1606, 2.39:1 windowed mode using launch options). It works initially - CS:GO opens just fine in that resolution and in windowed mode - but if I click on anything else, such as the taskbar, desktop, Google Chrome, Mumble, Discord, etc. then it changes back to 1080p immediately. I'm not sure what is wrong, why it could be happening or how to fix it. I never had this problem with VSR on my AMD card so I'm thoroughly confused why it isn't working on my Nvidia card. PC Specs: CPU: AMD Ryzen 5 1600 GPU: NVIDIA GEFORCE GTX 1050 Ti RAM: Corsair Vengeance LPX DDR4 3000 MHz 8 GB Motherboard: GIGABYTE AB350-GAMING 3 PSU: Corsair RM 550x Storage: WD Blue 250 GB NVME M.2 SSD, 2x WD Blue 1 TB HDD

I somewhat doubt that this is what is causing it to turn on - I think it must be some sort of feature where you can turn the computer just by moving the mouse or pressing a key on the keyboard. Aside from that, I'd check the power switch headers on the motherboard aren't being shorted.

Do you have a hard drive? I've experience this before with a dying hard drive - replacing the drive and reinstalling Windows fixed it.

As a first-things-first kind of measure: is the 24-pin motherboard connector, CPU power and your case's power switch connected correctly? I've had a problem with plugging my case's power switch cables into the wrong headers on the board before. Also make sure your power supply is plugged in and switched on.

I was thinking about this too, but what got me was the fact that in Linus’ video you can see anything behind the screen when it’s off, however, it’s all slightly clouded and hazy - and I assumed any light coming towards the camera module would also become all hazy and clouded in that same vein.

I believe TeraCopy allows you to do this.

I would honestly try removing the CMOS again, leave it for at least a minute so it can fully cycle all the power out. If you want to be doubly sure you could short the CMOS reset pin on your motherboard as it’s booting - the vast majority of boards have one of those.

Try your computer with the stick of RAM which came preonstalled - presumably it doesn’t blue screen, then try the computer with just the new stick of RAM in - if it still blue screens then I would suggest returning it because obviously there must be something funky going on with the compatibility.