* power status after ac power loss * SATA ahci mode enabled * DDR speed * advanced ram timings * enables NICs * cpu overvoltage enabled * iommu enabled status

And others I’m forgetting.

X399 IOMMU support is completely broken, as well as ASPM. These options must be disabled to even successfully install Windows 10.

The X399 Taichi bios shows me tons of options for hardware/controllers that aren’t even physically present.

These motherboards cannot run RAM at the rates speeds due to the infinity fabric design. Look at the compatibility list AsRock published. They cannot achieve 2666MHz without jumping up to ram rates for 3200MHz, if I recall correctly. That’s because X399 is built as two separate sockets that happen to share a heatspreader and lga connection, and the interconnect operates at the same speed as the ddr bus; it just can’t keep up with tight timings.

After updating to Firmware v2, 4/5 Times the bios says “no connection” when trying to check for online updates (despite the wired connection in both ports plus a 10gbe pcie card), and a full power cycle is needed to try again.

This is the first chipset I’ve seen that won’t let me run a stick of ram at a slower speed (but it let me run other ram at slower speeds, so I’m not sure why) and fails to post if I set my ram to less than the XMP 2 setting manually.

The bios is built for gamers and overclockers. The options to enable OC are “auto” or “manual” and there is no “stock” or “disabled” option.

This wasn’t a platform built for stability. Motherboard manufacturers are treating ThreadRipper as if it were Ryzen, as if we were all gamers and this wasn’t a workstation chipset.

Intel lets you run Core i7 on its server boards. AMD won’t let me use a motherboard sold for Epyc with my ThreadRipper CPU. Nor should they have to.. except my current options are all crap.

My biggest problem of all is that X399 (not just the Taichi) randomly stops recognizing certain PCI-E cards. My PCI-E 10gbe x520-da2 NIC worked ok for a couple of weeks hen suddenly wasn’t seen any more. I thought it was the card and bought a new one. Same problem. I thought it was the os so I installed another. Same problem. I thought it was the bios so I reset it. Same problem. I manually toggled each option pertaining to PCI in the bios and rebooted to test between each one. Same problem.

Took a look on NewEgg. All the x399 boards have 3 star reviews at best, and are filled with similar PCI-E complaints and “worked for a month then stopped working” across all the manufacturers and models. Which isn’t saying much, since there are only a dozen or so, really.

It happened, when the 2nd gen TR arrived. It used the same mainboards, so all the manufacturers issued BIOS updates.

Unfortunately, these updates claimed to support SEV (Secure Encrypted Virtualization). Linux of course tried to initialize it at boot/module load time and the entire thing went hanging, because TR CPUs do not support SEV, only EPYCs do.

So there were the following fixes:

1) downgrade BIOS back to pre-TR2 version,

2) blacklist the ccp module; which would make kvm_amd non-functional,

3) wait for a fix in Linux kernel, which initializes SEV with a timeout.

So it wasn't that tragic issue, if you had first gen TR.

What solved the problem for me completely was blacklisting the nouveau module for nvidia(about two weeks without a single freeze). In my case it was an option because I use an AMD gpu for linux and a nvidia for passthrough, so I have no need for the nouveau module to be loaded. BTW this is where I got the hint: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085

What I got from this is that it is not an nouveau driver bug, but rather a hardware bug that has a greater chance of being triggered if the module is loaded. The same thread suggests that disabling ASLR is also a valid workaround.

I've already gone through one CPU, about 4 months after I built it. Now the whole machine is just dead with no signs of life. I bought a new board assuming the board was bad but maybe I need to test the CPU now...

Agreed though, one of the worst boards I've ever bought and seriously rethinking all Asus purchases in the future.

After a BIOS update, an option for power supply idle control appeared, and selecting the "typical" over "low" option resolved the hangups. No C-state or C'n'Q changes required.

I did have to RMA the CPU initially when it wouldn't post with DIMMs in 2/4 slots, but later revisions seem to have quickly overcome the memory controller issues.

I have an old VIA-based 32-bit x86 machine (VIA Eden Esther 1 GHz from 2006), and it hangs in different times, but I managed to create a reproducer which hangs the system not so long after the boot. About 1 in 20 boots are unsuccessful.

I noticed that verbose booting reduces the chance of hanging compared to quiet boot, but does not eliminate it completely.

The similar issue was present even on Dell servers back in 2008-2009, which are based on more recent x86_64 VIA CPUs, here's an attempt to bisect the issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507845#84 The CPU seem to enter endless loop, as the machine becomes quite hot as if it's running full-speed.

All these years I believed this is a hardware implementation issue, related either to context switch or to SSE/SSE2 blocks, as running pentium-mmx-compiled OS seem to work fine, given that no other x86 system hangs the way VIA does.

However after this post and all LKML discussions, ticks/jiffies/HZ mentions, and how is it less an issue on Intel, I'm not so sure: the issue mentioned is related to time and printk, I also associate my problem with how chatty the kernel log is (at least partially), and the person in Debian bug tracker above also bisected the code related to printf, although in libc. It could be another software bug in the kernel. If that's the case, it is present since at least 2.6 times.

I would appreciate any suggestions to try, any workarounds to apply, any advice on debugging. If anyone have spare time and interest, I can setup the dedicated machine over SSH for testing. I have a bunch of VIA hardware which is reused for my new non-commercial project and I struggle to run these machines 100% stable.