Linux OS hangs at boot time with 64GB RAM and Nvidia (nonfree) drivers

My hardware:

  • AMD R7 3700x
  • Asus Crosshair VII Hero (x470) bios 3004 (Agesa with patch b)
  • Asus 2060 RTX DUAL
    2x or 4x Ripjaws V (Samsung B die) (F4-3200C14-32GVK)

I experience an issue with 4x ram sticks 64GB ram installed and using the Nvidia proprietary drivers.
The same setup with only 2x ram sticks (32GB) works fine. (currently running manjaro KDE 18.1.5, with kernel 5.5)

The usb-live sessions boot, but when running any live-CD with the proprietary drivers active the whole computers hangs. This means, all fans spin full speed black screen, reboot button not functioning, power-off not functioning, I have to physically remove mains to shutdown the PC in this situation.
I’ve tested with Pop! OS, OpenSuse, Manjaro XFCE / Gnome / KDE, Fedora. (all hang with 64GB installed)
So I don’t know what is going on (nvidia driver blob issue? / kernel panic? / Motherboard AGESA panic? / CPU ram controller hardware error?.)

Booting the mentioned distros using the Nouveau / opensource drivers works fine with 64GB installed, only with the proprietary drivers the computer hangs.

With “only” 32GB installed everything works fine.


  • Is there a way to retrieve some debug information?
    • Helping pin point the issue, to be more specific?
  • Where to report this issue? (Nvidia dev forum / AMD Agesa issue?)
  • Any one have this issue with AMD based GFx cards? (long shot)

To enable some boot messages that might give you more context /debug info;

If you can boot into grub, strike the “e” key at the list of kernels you can pick. Go down to the line where you see “linux16” and go to the end of that line, remove the “quiet” at the end of that line and then hit ctrl+x to boot.

Have you tried a lower memory clock on the RAM? It may be that board doesn’t support 64GB at 3200.

Is it the same RAM order every time? Have you tested each stick independently via memtest? You may have a faulty stick.

Are you on latest BIOS? Don’t have that board so I assume yes.

Worth testing the hardware systematically before ruling out a faulty component or Mobo.

I assume your PSU is beefy enough for the combination but if you have a spare PSU it may be an unrelated power issue. I had that once with a server board, fine on single stick but couldn’t hack full load out.

Does it have this behaviour with /nomodeset as a grub option?

Awesome, thanks for the responses :slight_smile:

I’ve tried, with different ram speeds. (2933Mhz C16 and even overclocked 3600Mhz C16, Windows 10 works fine, Linux with opensource drivers works fine)
Booted memtest, 4 cycles (12 tests) completed without errors, takes forever…

I will try the removing “quiet” option again this weekend when I have time.
I think, I tried that with the manjaro XFCE image but directly went to a black screen after F10 / ctrl+x.
Also will check the “/nomodeset” suggestion.