DragonFlyBSD Gets Fix To Be Able To Boot AMD Zen 2 Processors

[phoronix]

Phoronix: DragonFlyBSD Gets Fix To Be Able To Boot AMD Zen 2 Processors

Separate from the Linux boot issue affecting AMD Ryzen 3000 (Zen 2) processors that has been attributed to RdRand, DragonFlyBSD is the first BSD at least we've seen getting a separate fix to be able to boot these new AMD processors...

http://www.phoronix.com/scan.php?pag...x=DragonFlyBSD

[dillon]

I'm doing a burn-in test of the 3900X as we speak, running a bulk package build with synth (usually takes around 30 hours on a dual-socket xeon system if all source distfiles are already on the system). We'll see how the 3900X does on it. Right now its keeping pace with my dual-socket Xeon system. I also got two 3600X's for more pedestrian work. All the new Zen 2 processors are simply insane, including the 3600[X]'s... not just in performance and IPC, but particularly in terms of power consumption.

For the kinds of workloads we use them for... mostly compile workloads (so they tend not to be AVX2 heavy), the 3600X at 140W and two fewer cores is actually beating my 2700X at 200W. If you want insane efficiency, I'm running the 3900X with a 140W power envelope at the wall (instead of the 200W stock configuration) and its still almost twice as fast as my 2700X was at 200W. I only lost 10% on the 3900X going from 200W to 140W.

The only major limitation of using the AM4 socket with these new chips, particularly the 3900X (and later the 3950X) is memory bandwidth. AM4 only has two channels. However, I noticed that it seems to do significantly better on motherboards with 4 DDR4 slots verses 2 DDR4 slots. It would be interesting to test for that.

Care needs to be taken with these early BIOSes. They are all over-volting the CPU VCORE a bit too much and I do not recommend that anyone use the auto-overclock features for another few months. Manual OC and XMP (memory OC) is fine, though. Just don't go above 1.245V VCORE for the all-cores boost. Or you can try using a -50mV or -100mV offset (but there is no guarantee that these early BIOSes will actually apply it).

So far I've been able to test three older motherboards. An ASRock B350 and B450, and an Asus X370-PRO. I don't particularly need PCIe-v4 (yet) and the older mobos burn a lot less power, so... no point buying a new mobo for no reason. The B450 and X370-PRO were upgraded to a new BIOS and took the new Zen 2 chips without any issues. But I am having problems with the B350 Mobo... ASRock has just released a BIOS for it and it is having a hard time even POSTing with a 3600X in it. I expect ASRock will fix that issue relatively soon. Once I was able to get it to post (sometimes took 15 tries), the OS was rock solid. All the boards had no trouble running 3000MHz memory and ECC memory (which I have in the X370-PRO) appears to work just as it did on Zen+.

The DragonFlyBSD bug was just a simple stupid oversight. For AP STARTUP (during early kernel boot), the Zen, Zen+, and all Intel chips initialize the %fs selector. Our AP startup code didn't bother to load the selector again. However, on Zen 2, the %fs selector is not initialized (apparently) and that caused wrmsr() opertions in MSR_FSBASE to get wonky. Initializing the selector fixed the problem. It was a bad initial assumption on my part.

The Linux RDRAND issue is more related to its userland conditionalizing the use of the instruction and then behaving badly when it didn't work as expected. This is more an issue with over-optimization by Linux. No libraries or applications should be using those extensions directly from userland, but the Linux devs sometimes throw caution to the wind in order to make things go faster. It is better to let the kernel abstract the RNG out so the kernel can combine multiple source of entropy together and provide something reliable. Trusting any single source is a bad idea, and trying to roll your own (like BIND famously did a decade or two ago) is also a bad idea. In anycase... it is what it is.

-Matt

[[email protected]]

dillon , thank you for this insightful comment.
I now run a 2700X, and do not see myself switching it for a new CPU anytime soon (though I would have considered it if the new CPUs could have driven the motherboard's display connectors).

Where do you go to find these nominal voltage values? I care more about longevity than a few percent perf difference.

Hmm, I might play around with undervolting it a bit, I heard similar things with AMD GPUs as well.

[dillon]

@[email protected], the voltages are specific to the node the chip is fabbed on. I don't have the numbers for Zen+ on 12nm handy but you should be able to google them. I do have the numbers for Zen 2 on 7nm. Generally speaking the safe voltage runs a range depending on the load, with higher voltages only safe under low-load situations (i.e. single-core boost), and lower voltages required for high-load situations (i.e. all-cores boost). For Zen 2 the range is 1.245V (all-cores) to 1.45V (single-core). For Zen+ ... I don't have the numbers handy, sorry. But I have a better solution for you.

You can definitely underclock the chips. The easiest way to do it for your 2700X is to simply put a cap on CPU socket power to a lower-than-stock value. If your BIOS makes those options available, they are usually in the PBO or XFR sub-menu somewhere. Sometimes it is under the CBS/NBIO sub-menu. If the BIOS supports it you may be able to put the PBO or XFR2 stuff in 'manual' mode which allows you to specify your own values for PPT (max socket power, usually in watts), TDC, and EDC (amperage limits for the VRMs). Using PPT is generally a better way to underclock/overclock than trying to set the all-cores clock frequency.

If you can find those settings you can underclock the 2700X by setting PPT to a lower-than-normal value. Typically something like '65' (if the field is in watts. Sometimes the field is in milliwatts which would be 65000 instead of 65). I usually set the TDC/EDC current limits to 100A just to get them out of the way and control the system with the PPT setting.

If you do this you absolutely need to buy a little watt meter to make sure the parameters you set are being configured properly. Look for 'Kill a Watt' on amazon. Something like the P3 P4400 Kill A Watt meter, around $20. Plug it into the wall, plug the computer into it. Click on the 'watts' button to reads watts instead of voltage. Then mess with the BIOS and put the machine under heavy load to see if the power is capping properly. The whole-machine power consumption is usually around 30-40W higher than the socket power so e.g. if you set the socket limit to 60W you will probably see a whole-machine power consumption of 100W, assuming no GPU. The GPU will add another 10-15W when idle.

You can severely underclock systems this way in terms of all-cores power consumption, but still leave the single-core boosts intact. It makes for a very nice home server setup to stuff one of these mini-itx or micro-atx boards into a 2U rack mount with a low-profile air cooler, put a low cap on the PPT, and forget about it. Also helps the UPS keep the system going for longer if there's a power failure :-).

-Matt

[MaxToTheMax]

If you're going to underclock like that, there's no reason to buy a 3600X over a 3600, because they're not binned differently. GamersNexus also didn't find much difference in performance between an overclocked 3600 and a 3600X, so unless you want to run totally stock the 3600X isn't worth it.