JorgeB

Jun 2 12:01:08 CicioneServer kernel: macvlan_broadcast+0x116/0x144 [macvlan] Jun 2 12:01:08 CicioneServer kernel: macvlan_process_broadcast+0xc7/0x110 [macvlan] Macvlan call traces are usually the result of having dockers with a custom IP address, switching to ipvlan should fix it (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enable, top right)), or see below for more info. https://forums.unraid.net/topic/70529-650-call-traces-when-assigning-ip-address-to-docker-containers/ See also here: https://forums.unraid.net/bug-reports/stable-releases/690691-kernel-panic-due-to-netfilter-nf_nat_setup_info-docker-static-ip-macvlan-r1356/

It should return normal results once the disk has being fully written at least once, after that actual used capacity used should not be important.

It's possible with WD SMR disks that haven't been fully written, when the disks knows there's no data there it returns zeros from the controller, doesn't read the disk surface, hence the higher speeds, once the disk has been fully written you should see normal results.

Lets see if @bonienlcan help, but he will likely need the diags from v6.10.2

Strange, not seeing an attempt to start docker after the rebuild started, once the rebuild finishes reboot and post new diags if it still doesn't start.

Yes, it will list them in the syslog.

Yes, you should be fine after unblacklisting the NIC, no evidence so far of this issue with any Dell server.

Yes, also remembered there's already a thread about those drives with lots of actual data:

Could still be, if for example you're suing a controller or other hardware that has known issues.

This means the folder already exists, you can reboot, remove that one or create a different named folder.

You can try with a a new clean flash drive, don't even need a key to test.

Yes. No need if it's already a booting flash, but it will never hurt.

I suspect something was already wrong with the pool pre-update, like it was only one of the devices.

This is a BIOS problem, look for an update, though it's safe to ignore As for the ATA error, swap disk5 cables with a another disk and see if the error follows or stays with disk.

Pool looks OK now, and syslog is normal, as for the VM it's not my specialty and can't really help with that, I would suggest making a new post in the KVM section.

You can try recreating the flash drive, manually or using the USB tool, before doing it backup the config folder, then restore it. If that doesn't help and you want to go back to v6.9.2 just copy the all the bz* files from the v6.9.2 download overwriting existing files on flash.

There are some recommended models on the first post:

Enable the syslog server and post that after the next time it happens.

Second device is not being decrypted, like if it's not encrypted, I assume both were part of the pool? If yes post the output of: cryptsetup luksOpen /dev/nvme0n1p1 nvme0n1p1

Everything looks good so far, log spam is gone and the rebuild is going without errors.

RAM would still be my #1 suspect, run memtest for a few more passes.

Just replace all the bz* files on the flash drive and reboot.

Not totally clear for now, but I would guess local transfers are also at risk.

Most I saw have the same. Unlikely, especially if the same exact issue occurs with Ubuntu and zfs. Pass-through also appears to not be a factor, most of the users affected had vt-d enabled because it is by default, but some didn't even had any VMs.

Thank you both, unfortunately doesn't make things any clearer, trying to focus mostly on the Microserver gen8 since it's by far the most affected model but can't find anything in common why some are not affected: -jkpe's BIOS matches a lot of the affected models, quack75 has a different date but since the other matches it doesn't really matter. -some of the affected users have a bare stock server, without any extra card/controllers, others have an extra NIC, controller, NVMe device, etc -affected models all have Xeon CPUs, which is required for vt-d on these servers, and both Sandybridge and Ivybridge can be affected