Tuesday, March 7th 2023

Installing 24GB DDR5 Modules on AMD Ryzen 7000 Platform Springs Mixed Results—POSTs but Doesn't Boot

Over the past month, memory manufacturers started releasing DDR5 memory modules of 24 GB and 48 GB densities, which make up 48 GB (2x 24 GB), 96 GB (2x 48 GB or 4x 24 GB) and even 192 GB (4x 48 GB) capacities. There's only one catch—these modules only work with 12th Gen Core "Alder Lake" and 13th Gen Core "Raptor Lake" processors, as their memory controllers support a maximum of 192 GB of memory, and 24/48/96 GB DIMM densities. MEGAsizeGPU decided to find out what happens when one of these kits is installed on an AMD Ryzen 7000 "Zen 4" platform.

A Corsair Vengeance DDR5-5600 48 GB (2x 24 GB) memory kit was installed on a machine consisting of an AMD Ryzen 5 7600X processor, and an ASUS ROG Strix B650E-E Gaming motherboard (BIOS version 1222). It turns out that the machine POSTs, and is able to start the UEFI setup program. Here, the program is able to display the correct 48 GB memory amount, and the memory density of each of the two modules. The trouble is, Windows would not boot, and does not go past the Boot Manager. It halts with an error message that indicates a hardware problem.
AMD Ryzen 7000 series processors technically have a 128 GB maximum memory size limit. Until a couple of months ago, so did 13th Gen and 12th Gen Intel Core processors, which means that this may not be a hard limit, even for AMD, and the company could work with motherboard manufacturers on firmware-level updates to enable support for 24 GB and 48 GB memory modules to at least operate under the 128 GB limit (think 2x 24 GB, 4x 24 GB, or 2x 48 GB). The introduction of 24 GB memory modules improves choices for PC enthusiasts, as it's now possible to have 48 GB of memory using faster single-rank DIMMs (2x 24 GB). It also strikes a middle-ground between 32 GB (2x 16 GB) and 64 GB (2x 32 GB).
Source: MEGAsizeGPU (Twitter)
Add your own comment

39 Comments on Installing 24GB DDR5 Modules on AMD Ryzen 7000 Platform Springs Mixed Results—POSTs but Doesn't Boot

#26
Redwoodz
stimpy88Think BIOS level, not OS...
Except the user reported it boots into Windows... think less.

Everytime there is a problem with new AMD hardware, it inevitably ends up being poor Windows employement, which then later gets fixed after AMD gets blasted in the media. Every time. This is no coincidence. This is corruption.
Posted on Reply
#27
Dr. Dro
RedwoodzExcept the user reported it boots into Windows... think less.

Everytime there is a problem with new AMD hardware, it inevitably ends up being poor Windows employement, which then later gets fixed after AMD gets blasted in the media. Every time. This is no coincidence. This is corruption.
I'm in partial agreement. AMD's platforms are quite unorthodox for x86 system architecture - just look at Ryzen 9 X3D series. To compound the problem, AGESA, which is the lowest level firmware code in an AMD system and responsible for resource management, memory training, emulation of certain instructions etc. tends to be exceptionally buggy, often taking years for a platform to reach maturity. AM4 just recently got here. Then you have the need for certain custom drivers for chipset and scheduling, both of which also contain bugs. So yes, AMD has some blame in this situation.

On the other side, Windows is at a crossroads. Its commitment to backwards compatibility causes it to be bogged down by a LOT of legacy code making it exceptionally unwieldy, and to make things even worse, contains a very significant amount of third party licensed code that Microsoft can't touch.

Does Microsoft face the wrath of losing a lot of compatibility with older Windows software and clean up their act, or are we going to receive Windows 8 reskins forever from now on? Time will tell.
Posted on Reply
#29
Mussels
Freshwater Moderator
RedwoodzExcept the user reported it boots into Windows... think less.

Everytime there is a problem with new AMD hardware, it inevitably ends up being poor Windows employement, which then later gets fixed after AMD gets blasted in the media. Every time. This is no coincidence. This is corruption.
It's certainly something, when Intel have support for their E-cores at launch yet AMD require their own chipset drivers with custom power plans and prefer-X core features in their software, yet intels stuff is seamless added in earlier


It could be as simple as intel send hardware samples to intel along with lots of money to get shit working earlier, or it could be something more nefarious - but without any evidence, conspiracies are just imagination
Posted on Reply
#30
Sora
Dr. DroI'm in partial agreement. AMD's platforms are quite unorthodox for x86 system architecture - just look at Ryzen 9 X3D series. To compound the problem, AGESA, which is the lowest level firmware code in an AMD system and responsible for resource management, memory training, emulation of certain instructions etc. tends to be exceptionally buggy, often taking years for a platform to reach maturity. AM4 just recently got here. Then you have the need for certain custom drivers for chipset and scheduling, both of which also contain bugs. So yes, AMD has some blame in this situation.

On the other side, Windows is at a crossroads. Its commitment to backwards compatibility causes it to be bogged down by a LOT of legacy code making it exceptionally unwieldy, and to make things even worse, contains a very significant amount of third party licensed code that Microsoft can't touch.

Does Microsoft face the wrath of losing a lot of compatibility with older Windows software and clean up their act, or are we going to receive Windows 8 reskins forever from now on? Time will tell.
It doesn't boot into windows, it hits critical process died on the the second phase of boot, which is usually poor timings corrupting the security descriptor.

Honestly, we're at a point where there is no guarantee of stability because the RAM is always pushed too hard and the mainboard bios isn't tuned enough to mitigate it.
Posted on Reply
#31
Dr. Dro
SoraIt doesn't boot into windows, it hits critical process died on the the second phase of boot, which is usually poor timings corrupting the security descriptor.

Honestly, we're at a point where there is no guarantee of stability because the RAM is always pushed too hard and the mainboard bios isn't tuned enough to mitigate it.
The only way I can think of to mitigate this problem is by using relaxed timings and low frequencies... but it might not be enough.
Posted on Reply
#33
Dr. Dro
SoraRaja has 192GB running on a ASUS ROG STRIX X670-E

Wew, that is some slow DDR5, though! I wonder how long until 96 GB kits make it to current high-performance segment (6600+) tier of performance. I don't think 192 GB kits will ever quite catch up, and in the event they do it definitely won't be on current generation platforms.
Posted on Reply
#34
Mussels
Freshwater Moderator
Dr. DroWew, that is some slow DDR5, though! I wonder how long until 96 GB kits make it to current high-performance segment (6600+) tier of performance. I don't think 192 GB kits will ever quite catch up, and in the event they do it definitely won't be on current generation platforms.
More ram = lower speed
It's a law of the universe these days

Although i question why you think it's "slow" when the comments on the thread are excited about how fast it is given the RAM amount
Posted on Reply
#35
Dr. Dro
MusselsMore ram = lower speed
It's a law of the universe these days

Although i question why you think it's "slow" when the comments on the thread are excited about how fast it is given the RAM amount
Yeah, but I mean, in the frequency ladders DDR5-5200 C40 is equivalent to DDR4-2400 or -2666, it's only a hair above JEDEC base and that already took a binned kit to achieve at this capacity.
Posted on Reply
#36
unwind-protect
All these hacks, and just because unbuffered RAM has been kept in a crippled state. Per module capacity should have been doubled with the switch to DDR5, in the original spec. Instead we get 1.5x which might work somewhere sometime.
Posted on Reply
#37
Sora
MusselsMore ram = lower speed
higher timings, not necessarily lower speeds.
Posted on Reply
#38
Dr. Dro
Sorahigher timings, not necessarily lower speeds.
Well, both are true, it all depends on the capacity. When filling all ranks and banks, maximum attainable frequency will be reduced due to the strain on the CPU's memory controller. Lately with DDR5 this is of extreme importance, mind you, with differences between fully populated vs. single-rank per channel in the 2000 to 3000 MT/s range.
Posted on Reply
#39
Mussels
Freshwater Moderator
Sorahigher timings, not necessarily lower speeds.
No, IMC's force you to use lower MHz/MTs as you add more ranks.
Posted on Reply
Add your own comment
Jul 18th, 2025 10:18 CDT change timezone

New Forum Posts

Popular Reviews

TPU on YouTube

Controversial News Posts