JorgeB

Strange, if you're booting v6.9.2 try v6.10.0 or vice-versa.

Sorry, can't really help with that, better to make a new post in the appropriate section.

Still worth a try. Difficult to say.

And the CPU is identified correctly in the board BIOS?

Doesn't look like the typical mcvlan issue, looks more like a NIC problem, do you have an add-on NIC you could test with?

OK, assuming the data is the same if you do a new config and keep old disk1 intact you won't lose any data, of course the array will be unprotected until the sync is done, also disk1 won't be parity protected initially, then if no more sync errors you could do another new config this time including disk1 and re-sync parity again.

Where do you see that? You might need a BIOS update.

Changed Priority to Other

Changed Priority to Other

If that's from a syslog server then please attach the complete file.

First please confirm if the actual disk1 has the same data as the emulated disk1, from what I understood it has, correct?

Looks like the docker image ran out of space, the system share exists on both disk1 and cache, if the docker image is on disk1 the disk is completely full, if that's the case I would recommend deleting that one and recreating the image on cache.

Yes, but the emulated disk1 should have the same data as the actual disk1, assuming the parity check was correct and there's no new data added/changed since you unassigned it. Alternatively, and if you have one, rebuild to a spare, then do a couple of parity checks to look for sync errors.

You can use the Samsung Magician utility with Windows, not sure if it's available for other OSes

Start by running memtest, lots of different apps crashing in the log.

Main suspect is usually the RAM, but it can also be a disk, from your description looks like all corrupt files you found were on disk1? If that's correct I would start by doing a new config without it, then sync parity and run a couple of parity checks, of course if there's any new data on the emulated disk1 vs the actual disk you need to copy that first, if there are no errors do another new config with disk1 back and re-sync parity, if errors return you found the problem. Once a disk gets disabled it must be rebuilt, but if you do the above it's not needed for now.

It's false positive, you can ignore it, and hopefully Samsung will release a firmware update to fix that.

Enable the syslog server and post that after a crash together with the diagnostics.

Start by running an iperf test, it will confirm if it's network related or not.

Your post is not very clear to me, after moving all the data you want post a screenshot of the GUI main page to see current array status.

AFAIK it's only the Microserver Gen8, many people running a Xeon with VT-d enable, including multiple models myself without issues, pretty sure I've also seen other users with different model HP servers running it without problems, of course can't guarantee there's won't be other models affected but seems unlikely, can also add that the issues start immediately after updating, since at least -rc4, so anyone affected would notice after a couple of hours or so, and if it was a more general issue we would have seen a lot of forum posts about it.

It's a device issue:

Problem yes, but not necessarily a disk problem.

Those numbers look fine, please post new diags during parity sync.

I updated the post above but to make it more visible, the ones I found so far were all using Xeon CPUs with Intel VT-D (IOMMU) enable, I have a suspicion the problem is related to this, it's causing some kind of kernel memory corruption, so anyone running one of these with a Pentium or i3 CPU (or a Xeon with VT-D disable) might be OK, hopefully someone can confirm that.