JorgeB

Yes, firmware is the same as the 9207-8i, you have both the IT and IR firmware on Broadcom's site

Sorry posted the wrong link: https://forums.unraid.net/bug-reports/stable-releases/6100-vnc-no-longer-connects-r1902/?do=findComment&comment=19127

Yes, at least most the ones I've used have, e.g.: [2:0:22:0] enclosu HP HP SAS EXP Card 2.08 - /dev/sg34 [23:0:28:0] enclosu HPE 12G SAS Exp Card 4.21 - /dev/sg41 [1:0:18:0] enclosu Intel RES2SV240 0d00 - /dev/sg19 [1:0:12:0] enclosu INTEL RES3TV360 B057 - /dev/sg26 But it can be a little cryptic, for example the Intel RES2SV240 uses hexadecimal in the device, in the download page you see firmware is v13 and that corresponds to 0d00, v12 to 0c00, v11 to 0b00, etc.

Try this.

Yes, check/replace power cable also, and check that all errors were corrected by the scrub.

With the array stopped set pool slots to 0, that will delete that pool.

Issue could be power related, also look for an update for the LSI firmware, or try connecting the SSDs to the onboard SATA.

It is.

You could look for a firmware update for the expander, but likely it would require a supported HP RAID controller to update it.

Reboot and try updating again.

Sep 17 02:42:32 Tower kernel: ata4.00: status: { DRDY } Sep 17 02:42:32 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Sep 17 02:42:32 Tower kernel: ata4.00: cmd 60/08:e0:f8:ff:ff/00:00:7f:04:00/40 tag 28 ncq dma 4096 in Sep 17 02:42:32 Tower kernel: res 40/00:00:60:81:01/00:00:00:06:00/40 Emask 0x50 (ATA bus error) Sep 17 02:42:32 Tower kernel: ata4.00: status: { DRDY } Sep 17 02:42:32 Tower kernel: ata4.00: failed command: READ FPDMA QUEUED Sep 17 02:42:32 Tower kernel: ata4.00: cmd 60/08:e8:f0:ff:ff/00:00:ff:04:00/40 tag 29 ncq dma 4096 in Sep 17 02:42:32 Tower kernel: res 40/00:00:60:81:01/00:00:00:06:00/40 Emask 0x50 (ATA bus error) Sep 17 02:42:32 Tower kernel: ata4.00: status: { DRDY } Sep 17 02:42:32 Tower kernel: ata4: hard resetting link Sep 17 02:42:38 Tower kernel: ata4: link is slow to respond, please be patient (ready=0) Sep 17 02:42:42 Tower kernel: ata4: COMRESET failed (errno=-16) Sep 17 02:42:42 Tower kernel: ata4: hard resetting link Sep 17 02:42:43 Tower kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Disk looks healthy, the above suggests a power/connection problem, swap cables (both power and SATA) with a different disk and if you see similar errors see if they followed the disk or not.

The GPU is not being detect on a hardware level, not much you can do on the Unraid side.

Top right:

If the drives are not detected in the HBA BIOS most likely it's not connecting correctly with expander/devices, do you know the expander model? Are you connecting to it with one or two cables? P.S. if/when this is fixed upgrade the LSI to 20.00.07.00, all other 20.xx.xx releases have known issues.

We highly encourage to use MTU 1500 for the main NIC, eth0, you can then use 9000 for the 10GbE NICs, I for example always have a gigabit NIC with MTU 1500 as eth0 and then my 10GbE LAN with MTU 9000, if you want to keep using that make sure everything in the LAN supports that and is correctly configured. You should upgrade back to v6.10.3, delete/rename /boot/network.cfg and reboot to see if both NICs get detected. Also switch to ipvlan (Settings -> Docker Settings -> Docker custom network type -> ipvlan (advanced view must be enabled, top right)), I see some call traces in the log related to that. After that post new diags after you see the problem.

Sep 16 21:39:46 Anton kernel: BTRFS info (device nvme0n1p1): bdev /dev/nvme0n1p1 errs: wr 80548, rd 0, flush 79403, corrupt 25, gen 0 This shows that nvme01n1 device dropped offline in the past, start with a scrub and post the output, also run a scrub on the other pool since there's corruption found and see here for better pool monitoring,

Cache2 dropped offline: Sep 14 04:40:02 Tower kernel: sd 2:0:0:0: [sdk] tag#22 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=DRIVER_OK cmd_age=0s Sep 14 04:40:02 Tower kernel: sd 2:0:0:0: [sdk] tag#22 CDB: opcode=0x2a 2a 00 00 00 08 80 00 00 08 00 Sep 14 04:40:02 Tower kernel: blk_update_request: I/O error, dev sdk, sector 2176 op 0x1:(WRITE) flags 0x3800 phys_seg 1 prio class 0 ### [PREVIOUS LINE REPEATED 1 TIMES] ### Sep 14 04:40:02 Tower kernel: BTRFS warning (device sdj1): lost page write due to IO error on /dev/sdk1 (-5) Check/replace cables and also see here for better pool monitoring.

Please post the diagnostics.

Hmm?

If you cannot get at least one of the missing drives working a new config is the only option.

shfs crashed, it happens sometimes, especially when moving files around, rebooting will fix it.

This is the expected way, root with a password should never work for SMB shares, root without password works if the shares are exported to public.

Syslog starts over after a reboot, if it happens again enable the syslog server, then post that after a crash, it might catch the problem.

Stop shaking reboot and the shares will come back.

Hmm, maybe still missing a module, let see what I can find out.