JorgeB

It's on top of the log, line 10 or so.

Based on that looks like a disk problem, but difficult to say more without full diags.

Macvlan call traces are usually the result of having dockers with a custom IP address, more info below. 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/ Also this means you need to run a filesystem check on this device, this is likely the result of the unclean shutdowns.

Should be fixed.

Yes, just remember that docker and VM services must be disable first, mover won't move open files.

Fix filesystem on disk1: https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui Run it without -n or nothing will be done.

Unlike a clear a parity sync is CPU intensive, so it could be why it didn't crash now.

Same or different controller? It's failing to initialize, currently it's on the Intel SCU controller, these are known to not be as rock solid as the standard SATA controller, if not yet done try swapping with a disk on the Intel SATA controller, if the same happens there it could be a power or disk problem.

LT is already working on v6.10 which should be out soon™, don't expect any more v6.9 releases unless there's some serious data or security related issue found.

There are some known issues with v6.9.2 and spin down, for now you can downgrade to v6.9.1, it should help.

Syslog after a reboot won't be much help, ideally you grab the diags (tools -> diagnostics) before rebooting, but post them now so we can at least see the SMART reports.

Then not much more we can say for now unless you have some controller that's is known to have issues, you can run an extended SMART test on the disable disk and if it passes rebuild on top, before doing that you can also replace/swap cables to rule them out if it happens again to the same disk.

SMART looks mostly OK, but you should post the complete diags, hopefully you didn't reboot yet, much more info there.

Fist thing would should do is updating the LSI firmware, if still issues after that see if disabling spin down helps.

I'm referring to HBAs, never got or seen someone get more than about 3000MB/s with a x8 PCIe 2.0 HBA and 6000MB/s with a PCIe x8 3.0 HBA, won't say it's not possible, just not typical, and we are talking about a HBA here. AFAIK it's not part of the SAS3 spec, LSI has Databold, PMC mentions "SAS and SATA edge-buffering preserves customers' investment by improving performance with existing 3G and 6G drives", but in any case the wide link is never 12G native, so some performance degradation would be normal, I expect that if I used SAS3 devices with the 9300-8i and the expander I would get closer to the 6400MB/s typical speed announced.

If there's nothing being logged when the server crashes it's most likely a hardware issue.

Yes.

SMART test failed, disk should be replaced.

If it happens again post the diagnostics before rebooting.

There are two invalid disks with single parity, so the disable disk can't be emulated, disk itself looks healthy so you can try doing a new config and re-sync parity, probably good idea to replace/swap cables/slots on disk6 to rule that out.

Please post the diagnostics: Tools -> Diagnostics

Nope.

This is known to be a problem, that's why I mentioned it, though not sure why it wasn't before or what changed.

On second though not sure these can use the x16 link with just two ports, might be just like two x8 controllers in one, product brief is not very clear:

Yes. Not if you always use disk shares to do that.