X570 Aorus Master: Random Crashes/Freezes

I’ve reached a dead end trying to troubleshoot random freezes/crashes on my X570 Aorus Master. I’ve even RMA’d the board (Gigabyte claims they “fixed it” but won’t tell me which part they tested/repaired) and the problems persist.

What I Have:

  • program crashes / freezes
  • whole system crashes / freezes
  • i/o (mouse/keyboard) freezes
  • system freezes but mouse still moves
  • not obviously related to any particular program
  • not related to system load (happens at idle, normal usage, heavy usage)
  • happens on multiple linux distros (debian, ubuntu, fedora); sometimes within days, sometimes within an hour of boot
  • happens on windows (though windows is far less frequent)
  • has never happened in bios
  • I sometimes see crash reports and entries in journalctl, but I am not convinced these are causal - often don’t seem related, and usually there’s nothing.

What I’ve Tried:

  • multiple bios updates, from F11 ip to current (F31)
  • multiple kernel updates, from 5.4 up to 5.10.6 (.7 breaks my video)
  • memtest86 (no errors)
  • stress-ng (no errors/no crashes provoked)
  • swapping out literally all other hardware:
    • CPUs: 3600, 3900X
    • RAM: patriot viper 32GB DDR4-3600 (x1,x2), Crucial Sport 16GB DDR4-3000 (x1,x2,x3,x4), Corsair Vengeance 8GB DDR4-3200 (x1,x2), random OEM 8GB DDR-4 2666 (x1,x2)
    • VGA: RTX 2080 Super, GTX 1080, GTX 1060 3GB, RX 480 8GB, FirePro X2100
    • Install media: Samsung 970 Evo, Samsung 960 Evo, AData XPG SX8200, Samsung 860 Pro, various other SSDs
    • PSU: Seasonic Platinum 1200, EVGA 850 G3, Corsair RM1000X
    • Motherboard: Asus Prime X570 Pro. ALL components above work flawlessly on this board.

I’m now nagging Gigabyte for a replacement, but they have ignored me so far. At a loss of what to look at next. Anything is appreciated!

Only crashes I’ve had with the same board have been related to using their XMP profile, I set the voltages manually, and it’s been stable ever since.

I’ve done XMP profiles on the Patriot and Ballistix kits. Since I started trying to troubleshoot, I’ve left all kits at stock.

Not sure how to decide best voltages…?

This would be a good place to start https://download.gigabyte.com/FileList/Memory/mb_memory_x570-aorus-master_matisse_190812.pdf

1 Like

I’d be interested in learning more about what voltages you set for stability.

I have 2 x 16gb Gskill F4-3600C17-16GTZR for 32gb in total on my x570 Auros Master with a 3900x, but my Arch install crashes (powers off) in under a minute if I boot with the XMP profile enabled.

Windows is fine. Live boot environments also seem to work fine.

F31b bios has been most stable for me overall.

I set the memory multiplier to 36.66, and have 1.35v, although I’m not sure if dmidecode is reporting it correctly.

Memory Device
	Array Handle: 0x000A
	Error Information Handle: 0x0018
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 32 GB
	Form Factor: DIMM
	Set: None
	Locator: DIMM 1
	Bank Locator: P0 CHANNEL B
	Type: DDR4
	Type Detail: Synchronous Unbuffered (Unregistered)
	Speed: 3666 MT/s
	Manufacturer: Unknown
	Serial Number: 00000000
	Asset Tag: Not Specified
	Part Number: F4-3600C18-32GVK
	Rank: 2
	Configured Memory Speed: 3666 MT/s
	Minimum Voltage: 1.2 V
	Maximum Voltage: 1.2 V
	Configured Voltage: 1.2 V
	Memory Technology: DRAM
	Memory Operating Mode Capability: Volatile memory
	Firmware Version: Unknown
	Module Manufacturer ID: Bank 5, Hex 0xCD
	Module Product ID: Unknown
	Memory Subsystem Controller Manufacturer ID: Unknown
	Memory Subsystem Controller Product ID: Unknown
	Non-Volatile Size: None
	Volatile Size: 32 GB
	Cache Size: None
	Logical Size: None

Or if Arch is setting it back to 1.2

So thanks to @robbbot and a random L1T video I happened to re-watch, I discovered the “Power Supply Idle Control” setting in bios and set it to “typical.” Things looked good for a few days after that, but just had another hang, so turns out it wasn’t the answer in the end. :frowning:

Also found out which part Gigabyte replaced when I RMA’d the board: https://www.i-components.com/components/Nuvoton-Technology-Corporation-America/NCT3103S-TR.html

So seems I was right to suspect memory (circuitry).

amusingly, the thing I did ~20 minutes before the crash was brag on IRC about possibly solving the problem

$ uptime > 17:46:26 up 3 days, 22:24

Can you attach the log if you can after the crash may help narrow it down something like journalctl --since=today.

Next time it happens, sure. I’m kinda focusing on getting Gigabyte to exchange it ATM.

In the past, there’s been nothing out of the ordinary in journalctl.

This topic was automatically closed 273 days after the last reply. New replies are no longer allowed.