Anybody planning a Ryzen build?

[snazz]

5 hours ago, Greygoose said:

I just did it

 

GPU 1 running Windows 10 VM

GPU 2 running windows 10 VM

 

Both running 3 core, 8gb ram, and independent keyboard and mouse.

 

What I have noticed tho, is the XML file drops out the VBIOS command and I have to reenter. This happens randomly so hopefully, someone can explain why it does this.

 

EDIT: When i say randomly, it appears to happen when i stop VMs and change other settings within the VM.  Maybe the XML is reloaded back to default config (most likely) when editing the VM config under the VM EDIT function

 

Awesome!  Are you gaming with these VMs by chance?  If so, how's the performance?

[Greygoose]

1 minute ago, snazz said:

Awesome!  Are you gaming with these VMs by chance?  If so, how's the performance?

 

No gaming, just office work on 1 and the other is general use and tinkering. I am looking to get hackintosh on one of the VM's but thats a plan for a spare day.

[ufopinball]

On 1/19/2018 at 5:07 PM, killeriq said:

seems like this is new... on Asus x370pro 3404, dont recall seeing it on 3402,can someone confirm?

also what is it for?thanks

 

Yes, it's new for 3204.  The 3202 BIOS didn't have an Advanced Tab --> PCI Subsystem Settings menu option.

 

On the page for 3204, the only option at present is "SR-IOV Support".  At the bottom of the screen it reads: "If the system has SR-IOV capable PCIe Devices, this option Enables or Disables Single Root IO Virtualization Support."  The only options for the menu setting are Enabled or Disabled, with Disabled being the default value.

 

Google offers many links about SR-IOV, here's an example:

 

Single Root I/O Virtualization (SR-IOV) is a standard developed by the PCI-SIG that works in conjunction with system chipset support for virtualization technologies. SR-IOV enables network traffic to bypass the software switch layer of the Hyper-V virtualization stack to allow SR-IOV capable devices to be assigned directly to a virtual machine. It does this by providing remapping of interrupts and DMA.

 

Link:  http://techgenix.com/single-root-io-virtualization/

 

Not entirely sure what that means in terms of my build, so far the existing feature set meets my needs.  I'll have to research SR-IOV in greater detail later.

Edited January 22, 2018 by ufopinball

[killeriq]

19 hours ago, ufopinball said:

 

Yes, it's new for 3204.  The 3202 BIOS didn't have an Advanced Tab --> PCI Subsystem Settings menu option.

 

On the page for 3204, the only option at present is "SR-IOV Support".  At the bottom of the screen it reads: "If the system has SR-IOV capable PCIe Devices, this option Enables or Disables Single Root IO Virtualization Support."  The only options for the menu setting are Enabled or Disabled, with Disabled being the default value.

 

Google offers many links about SR-IOV, here's an example:

 

Single Root I/O Virtualization (SR-IOV) is a standard developed by the PCI-SIG that works in conjunction with system chipset support for virtualization technologies. SR-IOV enables network traffic to bypass the software switch layer of the Hyper-V virtualization stack to allow SR-IOV capable devices to be assigned directly to a virtual machine. It does this by providing remapping of interrupts and DMA.

 

Link:  http://techgenix.com/single-root-io-virtualization/

 

Not entirely sure what that means in terms of my build, so far the existing feature set meets my needs.  I'll have to research SR-IOV in greater detail later.

 

yeah update us, if u find what is it for  thx

 

BTW i left C6 States on AUTO and Unraid is stable - not sure if is enabled or not

[ufopinball]

3 hours ago, killeriq said:

 

yeah update us, if u find what is it for  thx

 

BTW i left C6 States on AUTO and Unraid is stable - not sure if is enabled or not

 

Did you add anything to the 'go' file?  I'm basically on stock 'go' and my C6 setting is on default (Auto?)  My system crashes regularly on 6.4.0 and BIOS 3404, unless I keep my Windows 10 VM running.  This is how I've had it, so for the moment I left it as-is.  Should probably research the proper way to do this, though.

 

Also, are the system crashes specific to Ryzen?  Does it affect Threadripper at all?

[m0therbrAin]

@Greygoose My shopping cart gets filled for my Ryzen build  and i want to thank you for publishing your experience here!!!

Can you please provide a detailed parts list or the memory you are running?

 

THX Thomas

[17thspartan]

Apologies if this has already been posted, but I skimmed through the last couple of pages and looks like most of the discussion was related to ryzen chips/boards.

 

For Threadripper folks, it looks like there might finally be a fix for PCI reset bug:

 

 

https://patchwork.kernel.org/patch/10181903/

 

 

With that resolved, I think the major issues stopping GPU virtualization (with good performance, ie NPT) should be fixed now, right?

[coppit]

8 hours ago, 17thspartan said:

For Threadripper folks, it looks like there might finally be a fix for PCI reset bug:

 

With that resolved, I think the major issues stopping GPU virtualization (with good performance, ie NPT) should be fixed now, right?

 

That's news to me! Awesome! There's a kernel build, and some reports that the Java workaround is working. I was going to dust off my equipment and rebuild my server. This fix sounds like a more "proper" fix.

[limetech]

10 hours ago, coppit said:

 

That's news to me! Awesome! There's a kernel build, and some reports that the Java workaround is working. I was going to dust off my equipment and rebuild my server. This fix sounds like a more "proper" fix.

 

We confirmed it works, testing now that it doesn't break non-TR builds.  If all goes well should be in next point release.

[methanoid]

So this will be the final piece of the puzzle? The NPT issues on Ryzen and TR fixed. The PCIE passthrough on Ryzen fixed and now about to be fixed on TR... Finally. Now its worth me splurging for a 16C TR :-)

 

[Tybio]

2 hours ago, methanoid said:

So this will be the final piece of the puzzle? The NPT issues on Ryzen and TR fixed. The PCIE passthrough on Ryzen fixed and now about to be fixed on TR... Finally. Now its worth me splurging for a 16C TR :-)

 

 

I'm thinking about doing the same thing, but I think I'll start slowly and build out my new chassis and disk caddies and wait for the point release to come out and have the community test it for me before I buy the MB/CPU/RAM.

[Jcloud]

This thread is huge, and I haven't been following it, but to go full circle @coppit brought the latest proposed PCI patch (linux kernel folks)  for Threadripper  to my attention on another post. For those folks, who would be interested in testing it, in 6.4.0-unRAID, have a look here -- it's been compiled.

[pwm]

On 3/17/2017 at 7:46 PM, Pauven said:

The difference between idle Vcore (0.18v) and peak Vcore (0.62v) is 0.44v.  In Win10 + CPU-Z, the observed difference between idle (~0.35v) and peak (~1.38v) is more than 1 volt.  I was hoping this was simply an offset, and maybe I could add 0.75v to both values, but that doesn't work right unless the idle Vcore isn't dropping below 0.93v (0.18v idle + 0.75 offset = 0.93v)

I know this is an old thread and you might already have figured out how to get good voltages, but the sensors data is normally based on voltage dividers - which means if the sensors app computes based on the wrong resistor divider the error will be multiplicative and not additive. There are a few exceptions where there may be also an offset but less common.

That's why the sensors configuration file may contain correction formulas like below to translate measured value into the correct value. One of the formulas is forward conversion and the following is for reverse-conversion.

    compute in0       (@ * 2), (@ / 2)
    compute in2       (@ * 2), (@ / 2)
    compute in3       (@ * 2), (@ / 2)
    compute in4       (@ * 5.25), (@ / 5.25)
    compute in5       (@ * 12.83), (@ / 12.83)
    compute in6       (@ * 5.25), (@ / 5.25)
    compute in7       (@ * 2), (@ / 2)
    compute in8       (@ * 2), (@ / 2)

 

[ufopinball]

Last week ASUS released BIOS 3803 for the Prime X370-PRO motherboards.  This includes AGESA 1.0.0.0a and support for newer (Raven Ridge) processors.

 

The IOMMU groups are still good (see previous post about BIOS 3402) although a few things seem to have been renamed:

 

BIOS 3402:

IOMMU group 0
[1022:1452] 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Device 1452

BIOS 3803:

IOMMU group 0:
[1022:1452] 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge

One big change is that SVM now defaults to "Enabled" instead of "Disabled".  This setting is required to do proper virtualization.

 

This BIOS does not fix the Ryzen "hang" issue.  Some have reported better memory timings/speeds, though.

 

I upgraded 2+ days ago and am not seeing any issues.

[Bedey]

So it's a good idea move my unraid sistem from g3900 to ryzen? I have already the motherboard, ram, ecc.. , I'm just waiting for the new apus

[killeriq]

3 hours ago, Bedey said:

So it's a good idea move my unraid sistem from g3900 to ryzen? I have already the motherboard, ram, ecc.. , I'm just waiting for the new apus

yes,, there is no issue of changing HW

[Bedey]

32 minutes ago, killeriq said:

yes,, there is no issue of changing HW

So the problems of instability are resolved? The Asus I own get updated like 4 days ago with the new agesa 1000a, so the last bios avaliable, I just want to upgrade without any sort of problems 

[limetech]

37 minutes ago, Bedey said:

So the problems of instability are resolved?

 

Who knows?  AMD is not saying anything.  Reports of freezing seem to be dying out though.  Either people are giving up or bios updates are making their way through the user base.

[ufopinball]

23 hours ago, limetech said:

 

Who knows?  AMD is not saying anything.  Reports of freezing seem to be dying out though.  Either people are giving up or bios updates are making their way through the user base.

 

I'm only on unRAID 6.4.0, but I downloaded the latest BIOS 3803 for the ASUS Prime X370-PRO and my system will still hang, given the proper conditions.

 

For reference, my original Ryzen 1800X was marked 1707SUT and I put it through RMA in August to receive a later-date 1730SUS.  Still hangs, but doesn't segfault.  In case you're unfamiliar, "1707" means manufactured during the 7th week of 2017.  I'm not familiar with the letter codes.

 

I think the 3803 BIOS may be better than previous?  My system lasted an hour or more w/o crashing, so I thought things were looking good.  The longer test was overnight, and it was frozen by morning.

 

I leave my C-states as default in the BIOS, and I haven't added anything to the unRAID configuration that is Ryzen specific.  My system survives because I have a Windows 10 VM running all the time, and I guess it's enough to keep the processor busy.  This is my intended configuration, but if I had to shut down the VM to run a backup on the vDisk, I could run into a freeze.  For the moment, I'm happy to leave things as-is and wait to see if/when the issue is properly resolved.  I think the ultimate solution would be to have unRAID run with a more or less out-of-the-box configuration, and not see hanging issues on Ryzen.  Dunno what it will take to get there.

 

I also have my eye on a Threadripper, and I don't know if the problem persists there?  I don't think I've heard of anyone mentioning it.  Once I make the switch over, I can run additional tests on the Ryzen to the degree that it is interesting to the investigation.

[luisv]

Similar setup, but I disable C-State and the system is rock solid.  

[Tuftuf]

I've just updated my bios to F20, the IOMMU groups have changed again.

 

IOMMU group 0:	[1022:1452] 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge
IOMMU group 1:	[1022:1453] 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge
IOMMU group 2:	[1022:1452] 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge
IOMMU group 3:	[1022:1452] 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge
IOMMU group 4:	[1022:1453] 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge
IOMMU group 5:	[1022:1452] 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge
IOMMU group 6:	[1022:1452] 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge
IOMMU group 7:	[1022:1454] 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B
IOMMU group 8:	[1022:1452] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge
IOMMU group 9:	[1022:1454] 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Internal PCIe GPP Bridge 0 to Bus B
IOMMU group 10:	[1022:790b] 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 59)
[1022:790e] 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
IOMMU group 11:	[1022:1460] 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 0
[1022:1461] 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 1
[1022:1462] 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 2
[1022:1463] 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 3
[1022:1464] 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 4
[1022:1465] 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 5
[1022:1466] 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric Device 18h Function 6
[1022:1467] 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Data Fabric: Device 18h; Function 7
IOMMU group 12:	[1022:43b9] 01:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] Device 43b9 (rev 02)
[1022:43b5] 01:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] Device 43b5 (rev 02)
[1022:43b0] 01:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Device 43b0 (rev 02)
[1022:43b4] 02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02)
[1022:43b4] 02:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02)
[1022:43b4] 02:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02)
[1022:43b4] 02:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02)
[1b21:1343] 03:00.0 USB controller: ASMedia Technology Inc. Device 1343
[8086:1539] 04:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03)
[1969:e0b1] 05:00.0 Ethernet controller: Qualcomm Atheros Killer E2500 Gigabit Ethernet Controller (rev 10)
IOMMU group 13:	[10de:1189] 07:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 670] (rev a1)
[10de:0e0a] 07:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1)
IOMMU group 14:	[1022:145a] 08:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 145a
IOMMU group 15:	[1022:1456] 08:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) Platform Security Processor
IOMMU group 16:	[1022:145c] 08:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) USB 3.0 Host Controller
IOMMU group 17:	[1022:1455] 09:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Device 1455
IOMMU group 18:	[1022:7901] 09:00.2 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51)
IOMMU group 19:	[1022:1457] 09:00.3 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) HD Audio Controller

 

[killeriq]

4 hours ago, luisv said:

Similar setup, but I disable C-State and the system is rock solid.  

ive put BIOS 3803 for the ASUS Prime X370-PRO and 6.4.1 today - set C-States to Enabled *from auto....10h stable so far, even BIOS before with 6.4.0 was asl so issues,couple of days

[luisv]

2 minutes ago, killeriq said:

ive put BIOS 3803 for the ASUS Prime X370-PRO and 6.4.1 today - set C-States to Enabled *from auto....10h stable so far, even BIOS before with 6.4.0 was asl so issues,couple of days

 

Great, please keep us posted as this would be good news under the latest BIOS and 6.4.1 for other Asus Prime X370-Pro owners.    I'm at 6hrs 44mins with it disabled.   Previous to 6.4.1 longest uptime I got was 30 - 32 days, restarted due to a BIOS / unRAID updates. 

Edited February 4, 2018 by luisv

[mikeyosm]

Guys, what's the state with temperature monitoring with Ryzen/UNRAID? I'm still using the modprobe it87 force_id=0x8620 method to have UNRAID show fan speed and temps.

I would have though latest KVM kernel would have fully supported Asus X370 boards by now?

[luisv]

Same here, forcing it87.   After each RC and the last releases I check, but no joy.  @limetech would need to weigh in if something is pending or on the horizon.