John_M

Have you see this thread? Unless things have changed in the last five years, it hardly seems worth the effort. You might make better use of the time simply copying files sequentially from one disk to another. I personally think it's a non-issue anyway.

The Mover makes sequential writes to the array, not random ones, so the persistent cache should see little use. If the drive can write directly to a shingled band it will do so. SMR disks work rather better in Unraid than in typical RAID applications, which is fortunate because you don't have just one, you have several. Parity 2 is one of them so maybe that's the problem. I don't mind using them as data disks (where there's an advantage to doing so) but I'm less enthusiastic about using them for parity.

That fine, and as perfect English as I could write, and I am English. Don't be so modest, I wish my German was as good.

Maybe in the description (that people don't bother to read!) that appears in Community Apps, where most people go to install it.

Yes, sorry, I'm not saying that the presence of the plugin is incompatible with pass-though. The example I gave had two Nvidia cards with the intention of using one for transcoding and one for a VM. However, both were being bound to the driver so the solution was to stub the pass-through one, which people seem to be forgetting or aren't aware of. One or two users are upgrading from 6.8 to 6.9, seeing the plugin, deciding they need it, installing it and then finding their VMs don't work. If they only have one Nvidia GPU and intend to use it for VMs then they don't need the driver and shouldn't install the plugin.

It doesn't look like it, I'm afraid. The only temperature reported is the GPU edge temp.

Oh, OK. That isn't part of Unraid either, then. Where does it get that information from? Is it the SuperI/O chip, such as Nuvoton or ITE?

What is this thing called "netdata"?

Quite a number of people are installing the driver and then wondering why they can't pass the GPU through to a VM. Perhaps a stronger warning is needed? Here's a recent example:

OK, thanks. It is what it is, then. At least I can point people here when they have problems. Ah, the joys of closed source drivers! Still loving my $50 AMD APU, BTW

It works with the "Cache" pool and multiple pools are just an extension of that idea so I believe it should work, though I don't use it myself. If you haven't started using your new pool try changing it or see here:

No, apparently not.

Thanks for confirming that it's a more universal problem than I thought. So, if the user does not have the GPU Statistics plugin installed the messages don't appear so often in the syslog? That would explain why only some people are affected. I appreciate that the message is harmless in itself but it make reading the syslog difficult and it also causes the log to fill up rapidly, which then triggers other problems. OK, thanks again. I can at least ask people to uninstall it temporarily while troubleshooting and they can decide what to do afterwards. I hope Nvidia suppresses the messages in a future release.

I don't use Nvidia GPUs myself but in the General Support section I'm seeing a lot of other users' diagnostics with this spamming the syslog over and over again, every second or so, eventually filling up the log space, but otherwise seemingly harmless: Apr 1 17:31:32 Tower kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window] Apr 1 17:31:32 Tower kernel: caller _nv000708rm+0x1af/0x200 [nvidia] mapping multiple BARs Apr 1 17:31:33 Tower kernel: resource sanity check: requesting [mem 0x000c0000-0x000fffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000dffff window] Apr 1 17:31:33 Tower kernel: caller _nv000708rm+0x1af/0x200 [nvidia] mapping multiple BARs At first I thought it only affects users with Quadro cards but this particular one has a GT 710. The thing they do have in common though is that the users have AMD motherboards, at least all the ones I've seen so far do. EDIT: It's more universal than that. See the reply, two messages below this. A quick search revealed this report from 2017, which suggests a buggy BIOS (though it isn't clear what hardware the problem affected then) but promised the messages would be suppressed in an update. It looks as though the problem has resurfaced. Perhaps a future driver update will fix it. Maybe someone with the appropriate combination of hardware can help monitor the situation.

It's been there for some time but can be difficult to find. It's in the AGESA under the extensive AMD CBS menu. I'm more familiar with Gigabyte BIOSes than ASRock, but try this: Advanced -> AMD CBS -> Zen Common Options -> Power Supply Idle Control. I can verify that for a different ASRock B450 board, just not a Pro4, but they all have a lot in common. Note that this tweak is only useful for crashes when idle. It specifically addresses the problem where the Zen cores are put into such a low power mode they fail to wake up from it. It won't do anything for crashes when even moderately busy.

I believe the error messages are harmless in themselves, but will fill your log, which is bad. It's a BIOS problem. Normally, I'd say upgrade to the latest version available for your CPU, which would be version 3.50. However, you're using BIOS 4.90 which is not recommended by ASRock for your 1700 processor. Did you buy the board with that version or upgrade it yourself? The best choice for Summit Ridge (Ryzen 1000-series) is 3.50. I don't know if downgrading is possible. If not, maybe version 5.00 is suitable, since ASRock doesn't specifically say it isn't, but equally likely, that's due to an oversight. Maybe ask ASRock for advice. https://www.asrock.com/mb/AMD/B450m Pro4/#BIOS https://forums.developer.nvidia.com/t/nvidia-related-warning-on-booting-linux-4-14/55670 I notice you have IOMMU disabled, so presumably you are not intending to pass it through to VMs - just using it for the server console and maybe for transcoding? Try turning on IOMMU and see if that changes things. If your server locks up when idle, take a look at this tip: The relevant BIOS setting is the one about "Power Supply Idle Control". Change it from the default "Low Current Idle" to "Typical Current Idle". That will prevent your CPU from entering the lowest possible idle state (C6), from which some early 1000-series CPUs can't wake up. Later generations don't suffer the same problem but the BIOS setting isn't harmful. There's a lot of anecdotal stuff on the Internet on this subject, but you don't need to globally disable C-states.

Diagnostics might reveal what the problem is.

I'd let the parity check complete. You don't really want to be running a Time Machine backup at the same time as a parity check, anyway.

If you remove it, you'll find out. MacOS likely needs a higher version. Why did you add it in the first place? Does something else need it?

That doesn't work from the command line. Do you mean that it has to be set as a kernel parameter?

You'd probably get a better response by asking in the support thread for your particular container (Plex is a popular application and there are several to choose from). Some containers have a permissions mask that can be changed but still ought to work with the default settings unless you have some unexpected customisation. Running a permissions repair regularly would fix the symptoms but leave the actual problem unresolved, so isn't a good solution.

Go to Tools -> Diagnostics and post the zip file.

Did xfs_repair find any file system corruption? I see no evidence of it in your diagnostics but I do see a lot of this: Mar 19 17:30:36 Truffle kernel: EDAC sbridge: Seeking for: PCI ID 8086:0e79 Mar 19 17:30:36 Truffle kernel: EDAC sbridge: Seeking for: PCI ID 8086:0e6a Mar 19 17:30:36 Truffle kernel: EDAC sbridge: Seeking for: PCI ID 8086:0e6b I don't know if it's bad or benign (either way, it's verbose) and a quick search didn't reveal much. I know that EDAC is usually associated with ECC RAM but this seems to be scanning the PCI bus. The 8086 manufacturer IDs suggest Intel but the unit IDs don't match anything in your lspci.txt. Maybe someone else can shed some light.

If the server fails to shut down cleanly it should leave a log on the boot flash device, in the logs directory (i.e. /boot/logs from the Unraid command line).

Maybe try toggling away from protocol 4, Apply, then back to protocol 4, Apply.