John_M

There are call traces related to the Tehuti network driver, though you don't seem to be using it. Your static IP address is assigned to a gigabit Intel NIC.

Do you have something else on your network that has the same IP address as your server? That would cause the problem you're seeing. I see it has a static address of 192.168.1.101, if that helps you locate the possible culprit.

That's a very unusual and somewhat humorous error message. Did you try a web search? It crops up several times over nearly 20 years and appears to be related to spurious PCIe interrupts. More information would be needed to investigate further. You could try unplugging all cards and seeing if it goes away, then re-installing them until you find the problem one.

UDMA CRC errors are SATA link errors caused by hardware problems, such as bad cables, connections, backplanes and sometimes power distribution. Less comon causes include bad controllers and bad drive electronics. If just one disk was affected you'd be advised to replace the sata cable and check that the power connector is securely plugged in. Since all your disks are affected it's going to be something common to them all, such as the connecting cable, the enclosure, its power supply or backplane, or the HBA.

You need to test your storage and your network separately. You can test your network performance with iperf3 and you can test your storage with the DiskSpeed application.

If you need help, please describe your actual problem and post your diagnostics.

Yes, the maximum* capacity of any user share is the sum of the capacities of the included disks. The more you include, the greater the capacity. *Note: It's the maximum because very often a given disk is included in more than one user share, though you're free to configure that however you wish.

SMB is a network protocol. It has no knowledge or preferences about the underlying file system.

I'm not sure how to interpret "that didn't work". I never expected it to fix the problem, just to help with the troubleshooting. Do you mean that your results were the same as before you turned the cable round? If so, it means that the cable is working the same in both directions (not necessarily properly, but at least it's symmetrical - remember, it isn't just a bundle of wires but has active components at each end), which is useful diagnostic information and points to a possible problem with one or both cards.

Here's mine for comparison: root@Mandaue:~# cat /etc/ntp.conf # Sample /etc/ntp.conf: Configuration file for ntpd. # # Undisciplined Local Clock. This is a fake driver intended for backup # and when no outside source of synchronized time is available. The # default stratum is usually 3, but in this case we elect to use stratum # 0. Since the server line does not have the prefer keyword, this driver # is never used for synchronization, unless no other other # synchronization source is available. In case the local host is # controlled by some external source, such as an external oscillator or # another protocol, the prefer keyword would cause the local host to # disregard all other synchronization sources, unless the kernel # modifications are in use and declare an unsynchronized condition. # server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 # # NTP server (list one or more) to synchronize with: #server 0.pool.ntp.org iburst #server 1.pool.ntp.org iburst #server 2.pool.ntp.org iburst #server 3.pool.ntp.org iburst # # Full path of a directory where statistics files should be created # statsdir /var/lib/ntp/stats # # Location of an alternate log file to be used instead of the default system syslog(3) facility # #logfile /var/log/ntp # # Drift file. Put this in a directory which the daemon can write to. # No symbolic links allowed, either, since the daemon updates the file # by creating a temporary in the same directory and then rename()'ing # it to the file. # driftfile /var/lib/ntp/drift # # Location of PID file # pidfile /var/run/ntpd.pid # # Uncomment to use a multicast NTP server on the local subnet: #multicastclient 224.0.1.1 # listen on default 224.0.1.1 # Set an optional compensation for broadcast packet delay: #broadcastdelay 0.008 # # Keys file. If you want to diddle your server at run time, make a # keys file (mode 640 owned by root:ntp) and define the key number to # be used for making requests. # PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote # systems might be able to reset your clock at will. # #keysdir /etc #keys /etc/ntp.keys #trustedkey 65535 #requestkey 65535 #controlkey 65535 # # Don't serve time or stats to anyone else by default (more secure) restrict default limited kod nomodify notrap nopeer noquery restrict -6 default limited kod nomodify notrap nopeer noquery # # Use these lines instead if you do want to serve time and stats to # other machines on the network: #restrict default limited kod nomodify notrap nopeer #restrict -6 default limited kod nomodify notrap nopeer # # Trust ourselves. :-) restrict 127.0.0.1 restrict ::1 # Generated entries follow: interface ignore wildcard interface listen br0 server 0.uk.pool.ntp.org iburst server 1.uk.pool.ntp.org iburst server 2.uk.pool.ntp.org iburst server 3.uk.pool.ntp.org iburst I don't notice any significant difference, but I haven't compared the line by line. You could try booting from another USB stick with a temporary licence and default configuration, as I suggested earlier. Don't try to assign any disks or start the array. Just boot, set up your timezone, use the default servers and leave it for a while to see if it syncs the time. That would at least indicate if you have a configuration problem. It would only cost you a USB stick and a few hours to try it and everything would be back as it was when you boot from your original USB.

It isn't something I do, myself, as I don't need the extra speed and I don't want to dedicate a whole SSD to one VM but have you tried entering the OVMF Setup and trying to select it there, as I suggested? I believe any edits you make there will be stored in the emulated nvram associated with the VM. If that doesn't work then you will need to edit your XML. Perhaps this thread will point you in the right direction.

That is the wrong approach and doing it twice doesn't make it work any better. C states in general are a good thing. It's just the very lowest power one that can be problematic with first generation Zen, such as your 1700X and 1900X, which enter a low power state when idle and sometimes fail to come back out of it. Try this and, if it works, you can forget about rebooting by cron and it's associated problems: Remove the command from the go file Re-enable Global C states in the BIOS Find the BIOS setting for Power Supply Idle Control - it can be difficult to locate but you might find it near to the C states control option; if not it will be under the extensive AMD CBS section. Change it from the default value of "Low Current Idle" to "Typical Current Idle". If that is indeed your problem, it will hopefully now be fixed. If it isn't fixed then, quite honestly, I would much rather give the processor some light task (such as leaving your VMs running) to keep it from falling asleep than scheduling a regular reboot.

Unraid works best if you have a parity disk. It makes replacing data disks much easier and offers some protection against disk failure. If you don't have a parity disk you can add one but it can not be smaller than your largest data disk. So, if your largest data disk is 4 TB, you can add a parity disk of 4 TB or more. You don't need to try to find a 25 TB disk! If you want to replace a data disk with a bigger one and have a parity disk, the new disk can not be bigger than the parity disk. So, choose your parity disk carefully. If you want to replace a data disk with a bigger one but have no parity disk, you must copy all the files from the old disk to the new one manually. You can use the command line or mc (Midnight Commander, which is built in to Unraid) or a docker container, such as Krusader to access the disk instead of the share. The best solution would be to add a parity disk first. Then replace your data disk.

Since you don't have a primary vDisk specified, did you configure a boot disk anywhere? I'm not sure whether you need to enter the OVMF Setup and select the NVMe device as the boot disk or specify it in the XML, but it needs to be configured somewhere.

Not partitioning, but you could make a user share called, say, small_drive and include only that one 100 GB disk, like this: and you'd want to exclude it from other shares. It would have the advantage of being protected by parity, along with the rest of the array disks.

Your iperf tests are consistent with the transfer speeds you're seeing, which indicates that the problem is with your network, not with your storage. Maybe you have a bad cable in one direction - you could try turning it round to see if the speed discrepancy is reversed. Are there any error messages logged by the driver?

In case it helps, mine have non-zero values: root@Mandaue:~# cat /boot/config/drift 12.801 root@Mandaue:~# cat /var/lib/ntp/drift 13.768

That is explicitly referring to the second M.2 socket (hence M2_2). The first M.2 socket (M2_1) has four lanes direct from the AM4 socket. Oh, please!

It's a 3600, according to the diagnostics, so 24 PCIe ver. 4 lanes, though the motherboard is only qualified for ver. 3. 4 lanes to the X470, 4 to the NVMe, 8 to the primary slot, 8 via a switch chip which can feed either the secondary slot or the remainder of the primary slot. @xnerdist Since you want to pass through the RX 580, you could try putting it in the primary GPU slot and if the P2000 won't work in the secondary slot (physically x16, electrically x8), where it should ideally go, you could put it in the bottom long slot, which is physically x16 but wired for four PCIe ver. 2 lanes, but loses some if you populate the lower x1 slots. That will work if the BIOS allows you to select that one as the primary GPU. It isn't ideal but should be quite usable as your main purpose for it is not to generate complex graphics but to transcode video, where a much lower PCIe bandwidth is required. Nevertheless, it ought to work properly as you had it and I'm still of the belief that it's a motherboard/BIOS problem. Consumer and gaming motherboards are only tested with Windows and each one works around the bugs in the other so "it works with Windows" is no guarantee that it will work with any other operating system.

Good luck, then.

Do you mean something like this or this?

Now you've got that off your chest do you actually want some help? If so, post your diagnostics.

I'm not entirely sure what you mean - a screenshot would help - but it sounds like you've changed the Dynamix Color Theme in Settings -> Display Settings. The Azure and Gray themes look like your description; the White and Black ones have the traditional look. Click on the fourth icon from the top (it looks like meshed gears) and choose Display Settings in the User Preferences section. Then scroll down to Dynamix Color Theme and choose either White or Black.

No, I haven't made any changes. All I ever did was set my timezone and update the list of time servers. The only file present in the /var/lib/ntp directory is also called drift. There is no stats file. root@Mandaue:~# ls -l /boot/config/drift -rw------- 1 root root 7 Apr 7 22:45 /boot/config/drift root@Mandaue:~# ls -l /var/lib/ntp/ total 4 -rw-r--r-- 1 ntp ntp 7 May 10 11:06 drift root@Mandaue:~# It seems that the /var/lib/ntp/drift file is updated as necessary. I don't know for sure but I would expect that it is copied to /boot/config/drift when the ntp service is shut down and loaded from the same file when the service is started. That would be a customisation set up by the developers of Unraid. One thing you could try is to create a new temporary USB flash boot device using a trial licence and use that to boot your server. Don't try to start the array or configure any storage but set up your timezone and time servers and then leave it for a few hours to see if that works. If it doesn't then there's something strange about your hardware. If it does then the problem is with your configuration.

The two screenshots suggest that both GPUs are being given the same PCIe address - 27:00.0 - which is why they can't co-exist. Can you confirm that you didn't swap the cards round between the two screenshots? X470 ATX-sized motherboards generally support bifurcation of the 16 PCIe lanes normally allocated for GPU use but you might have to enable it in the BIOS. (Sorry, I'm not as familiar with MSI motherboards as I am with Gigabyte ones.) That would mean setting it to On, rather than Auto. I would expect, when bifurcation is working properly, for eight of the lanes to be routed to the primary x16 slot and eight to the secondary one, and for each device to receive a unique address and be in a different IOMMU group. That doesn't seem to be the case with this motherboard. Maybe a different BIOS would fix it. Eight PCIe gen 3 lanes are more than sufficient for each of your cards and the use case you give in your OP is a perfectly valid one. I'm leaning towards the problem being a buggy BIOS.