Lesson from the tale: Avoid purchasing from Asus. Issues with data integrity and 12900K.
Lesson from the tale: Avoid purchasing from Asus. Issues with data integrity and 12900K.
Has anyone else faced data loss because of the 12900K/Z690 setup in Linux? I’m still running CentOS 7.7.1908 with the 3.10.1127 kernel (the newer versions trigger a panic due to conflicts with my Infiniband ConnectX-4 card/system/kernel modules). Recently, I’ve been seeing inconsistent page frame numbers, though not always at the same time. Previously, the r8125 module caused complaints, but I’ve turned it off and switched to an Intel Desktop gigabit NIC, yet kernel warnings about bad frame numbers persist. Now I’ve noticed a new problem: while working with my data using pixz, archive checks reveal corrupt or problematic tarball files (this isn’t happening with my AMD Ryzen 9 5950X). Both systems use the same type of RAM—Crucial DDR4-3200, unbuffered and non-ECC. I’m curious if others are experiencing similar issues on Linux. Thanks. *updates* I recently switched to Windows 10 20H2 and upgraded to 21H2 just to test running as a Windows OS instead of Linux. My goal was to see if the virtualization workload would handle it better, especially with my 8-10 VMs. When trying to import OVA files, they kept failing, reporting corrupted source images despite being verified before. I ran memtest86 on those four sticks—about 25 minutes in, already seeing over 700 errors. Next step: swap the same four Crucial 32GB DDR4-3200 sticks into my AMD Ryzen 9 5950X and rerun memtest86. If the errors persist, it points to a CPU issue; if not, it’s likely memory-related. I’m also considering using a different RAM setup to isolate the problem. This could definitely be a challenging week for me.
Yep. I had been adding more info to the post when you asked. I already ran memtest86 three times: first on the 12900K with the original four DIMMS, which gave these results, then I tested it on my AMD Ryzen 9 5950X setup (four Crucial 32 GB DDR4-3200 sticks), which produced this output, and finally I swapped the four DIMMs into the 12900K system, resulting in that.
That setup in the video completely stopped during the memtest. On my machine everything functions properly as long as I adjust the DRAM CURRENT CAPABILITY to 120% in BIOS from the standard 100%. My configuration uses a R9 3900x with Crosshair VIII Hero x570 and 4x16GB Crucial Ballistix 3200CL16 RAM. It only works with 2 sticks, but there might be other problems on your system. It could also be an issue with the memory controller on the i9 12900k or the XMP profile not syncing correctly with your motherboard settings, requiring manual BIOS changes.
It's interesting that Intel issued a refund, but that responsibility lies with the retailer, not the manufacturer. This doesn't mean ASUS offers a warranty in the U.S., though it might be available elsewhere. It seems the issue likely involves the motherboard rather than the CPU.
The system rebooted itself unexpectedly during the initial testing phase. Your observation about current performance is accurate: originally, the four DIMMs installed managed to complete the test, allowing memtest86 to terminate after over 10,000 errors. However, once those sticks were replaced with the same four units from my 5950X motherboard—both using Crucial 32 GB DDR4-3200 memory without ECC—the spontaneous reset happened. Interestingly, the four sticks from the 5950X passed memtest86 on their own system, but only after being transferred to the 12900K/Asus Z690 Prime-P D4 board did the same issue occur. It seems the combination of the 12900K and the Z690 Prime-P is problematic.
I presented the images and video you mentioned. If I had stayed within the 30-day refund period, this would have been handled by the retailer. It’s been three months since the device was installed (3MIS). It’s difficult to pinpoint whether the problem lies with the motherboard, CPU, or both. My conclusion comes from the fact that the memory controller is built into the chipset, on the CPU itself. If a memory controller issue is affecting over 10,000 errors detected by memtest86, it points to a CPU-related concern (and possibly a specific on-chip memory controller fault). Regarding the motherboard, the ability to complete several test cycles in about ten hours and fifty-two minutes suggests it can indeed verify memory health. However, when I swapped the RAM from my 5950X to the 12900K/Asus Z690 Prime-P D4 system, the system reset itself within ninety seconds—clearly indicating a motherboard fault as well. In either case, I won’t repeatedly test this on my money or burden the delivery service company that handles my shipments. I’m choosing not to keep trying endlessly and hope for a more reliable product from Intel and Asus. I believe Asus should offer a full refund for a motherboard only three months old, especially since the failure seems severe. It feels like Asus isn’t prioritizing their customers or their products enough. The inability to run memtest86 for more than ninety seconds is a strong sign of a serious motherboard problem. If I were managing an Asus product, I’d definitely request a refund to replace it and investigate further. memtest86 isn’t as daunting as launching an operating system, but if it fails that much, it’s clear there’s a bigger issue.
It's rare to find businesses offering refunds beyond the initial 30 days, typically handled by the retailer. Stick to trusted sellers for better chances of receiving a refund if needed.
Maybe a more engaging question should be considered: why do we accept companies that refuse refunds, especially within the first year of use? I believe if you can't boot into memtest86 and remain unresponsive for over 90 seconds, you deserve a refund. If not, then why are consumers in this industry so tolerant of products that fail after just three months? The industry's reluctance to support customers clearly reflects poorly on the companies, their offerings, and the sector as a whole.