In a word? No, unless you don't mind running an older distro like Ubuntu 18.04.2 LTS or Debian 9.9 and carefully upgrading from there.
Linux, surprisingly, is a bit rough on the new CPUs and with Navi; you're going to need to wait a few weeks unless you're an adventurous user. We are working on it, and there is a thread on the Level1 Forum if you pickup a Ryzen 3000 CPU and want to help out. More details there and some interesting observations I've made.
Ubuntu 18.04.2 works, as does Debian 9.9. I was working with AMD on the press-kit they supplied (thanks AMD!) to try to troubleshoot why many distros that use a newer kernel (such as Fedora 30 based around Kernel 5.0.9) would error on boot. We know from the E3 slides that there are many changes around the microarchitecture, but I'm not sure what might cause this type of regression.
It gets weirder.
My setup is running Windows 10 1903 with VirtualBox installed. Of course, AMD hardware virtualization extensions, SVM, were enabled. I booted the Fedora 30 ISO and, to my surprise, the Fedora 30 VM crashed under VirtualBox in exactly the same way as it does on bare metal.
I installed Debian 9.9 in a VM (which went fine) and installed Kernel 5.1. That worked fine. I installed Kernel 5.0.9 in Debian, that also worked fine. Later I shut down, came back the next day, and booted directly into Kernel 5.0.9. VirtualBox crashed with an invalid instruction type crash, which was pretty interesting. Why does it work depending on what you've booted previously? Can you actually load real microcode through a VM? I am having trouble imagining a scenario where this makes sense.
I also tried Pop!_OS 19.04, but it died in a similar way. I tried using boot parameters to disable/re-jigger ACPI parameters, disabled the microcode loader and a number of boot-time black-magic incantations, but I didn't have a lot of time to dig deep into this issue. The error above about offline CPUs is what you get when you try to use the init line to boot directly into a bash shell from the Pop!_OS installer on Ryzen 3000.
Pop!_OS Is pretty easy to debug – you can hit E to alter the Linux line and add all sorts of params. I experimented with a lot of common ones -- trying to load the Windows ACPI table (okay, admittedly old school, but hey, worth a try?), disabling rdrand, setting maxcpus to 1... all the usual tricks. I didn't make much progress. I was able to poke around a bit from the initial ram fs, but I am not sure if this is a kernel bug, a hardware bug or what. It "feels" a bit like the SVM debacle where an immovable object (kernel dev team) met an unstopable force (AMD). This issue was ultimately resolved, but I'm not 100% clear on if it was a kernel patch or firmware update. I thought it was a firmware update, which is what I suspect is needed here, but I can't be sure.
If Ryzen 3000, and by extension Rome CPUs, sell as well as I think they're going to then AMD is going to have all the money it needs to have as many people as they need working on these types of issues.
I was able to install Kernel 5.1 manually on Ubuntu (even copying the running kernel config from Fedora 30 – I thought I was being so clever), but the 3900X SystemD reported that my last 4 CPUs were offline.
Echoing 1 into 'online' under /sys brought them... back online? But otherwise it booted without panicing.
So... yeah, I'm not sure. I'm hoping this is just an ACPI table with silly defaults somewhere, and that the Fedora 30 panic is fixed in short order, without having to modify the kernel.
I will be incredibly surprised if this is a legit bug in the Linux kernel, unless it is one introduced somehow by other patches or microcode for older AMD CPUs.
In terms of raw performance, checkout our other articles, videos or guide. These CPUs are the real deal in terms of performance. I can't believe the 12 core Ryzen 9 3900X works as well as it does on an AM4 socket.
This platform brings PCIe 4.0 speeds and, as far as I can tell, nothing special is needed there on Linux.
Radeon RX 5700 and RX 5700 XT also just launched; watch this space for a full review on the Linux side of things in a few weeks (hopefully). They show a lot of promise but a few issues will have to be addressed over the next week or two (again, hopefully).
IOMMU, Virtualization, oh my!
If you're thinking about this platform for hardware passthrough of graphics, you're in luck. You should wait till the full motherboard reviews, but the X570 is going to be worth the premium cost to enthusiasts and users of VFIO. It depends somewhat on the UEFI version – certainly I have used some unfavorable UEFI versions where the entire system only had about 3 IOMMU groups – but in general the newer UEFIs are offering some really killer options.
The CPU-connected NVMe slot is generally its own group; both x8 groupings are their own IOMMU group and the PCIe4 lanes provided by the X570 chipset are also split into their own groups.
It truly is just about a best-case-scenario.
The "downstream" peripherals from the chipset – slower IO, some of the USB ports, etc., are however all grouped together.
Some motherboards group networking into a single group, as well. Check out the individual motherboard reviews for full coverage, but there are some preliminary screenshots of IOMMU setups in the Linux review video on the Level1 Linux channel. Be sure to check that out.
Also, Zen2 has a lot of enhancements for virtualization. They say it's built for the enterprise and I believe it, based on my experience so far.
USB seems generally improved over the old ASMedia controllers (though a device dump shows some ASMedia controllers still present in the system). Next generation USB controllers seem faster and more stable than 2000 series Ryzen.
Warning
I have found a few situations where there is a loss of CPU fan control in Linux. The work around is to enable a higher minimum fan speed your motherboard's UEFI or, curiously, to use a fan header other than the CPU fan header. I will cover this in more detail if it is still an issue as I review motherboards. Watch the Level1 forum for updates.
Keep an eye on your CPU temps if you are an early adopter. If you don't plan to overclock, or plan to only do mild overclocking, the bundled Wraith Prism cooler is all the CPU cooler you need for a nice Linux workstation.
Conclusion
The Ryzen 9 3900X will probably go down in history like the i7 2600k – a legendary CPU because it was so good, and so long-lived. For the first time in a long time it feels like a computing experience with a decade of advancement behind it. I wish the launch was a bit smoother, but I'm confident AMD will iron out these issues one way or the other. Hopefully we aren't looking at another marginilzation type bug that was present on some 1st gen Ryzen silicon. Watch this space intently -- I will provide an update the moment I know something. And, in a pinch, a long-term support distro like Debian will hold me over till then.
