Skipdog

@Kboogie Thanks for the detailed data point. Looks identical to my issue. I did look at another post where another user replaced his card with a 94xx series but they are expensive and i quickly ditched that idea. Hope they are able to fix the regression. 7.3.0 works great.

@paolobosco Good to know my scenario isn't a result of some strange configuration on my side. I can validate that going to 16.00.12.00 does not fix this problem so you can skip that!! @JorgeB I can mark your response to wait for a potential fix via Kernel update as the solution.

@JorgeB Thanks for the input. That being the case it must be something different with the 9305-16e (my card) vs the internal variant -- SATA timings, expander negotiation, etc. I'll stay on the working version for now!

@JorgeB What is the best way forward-- is there an avenue to log the bug report (regression) with Slackware, etc?

@rerror Which UNRAID version are you running?

OK some new data- Upgraded to 16.00.12.00 and rebooted into the same 7.3.0 version to make sure everything worked good (it did) Upgraded to 7.3.1 and rebooted and confirmed the timeout/resets are still happening (they are) Tried to add pci_aspm=off to boot statement -- did not fix. The AI wants a couple more tests on the boot statement like: /bzimage initrd=/bzroot pcie_aspm=off pci=noaer and nomodeset pci=noaer pcie_aspm=off and... pcie_port_pm=off pci=noaer At this point I think i will revert it back to 7.3.0 and wait to see what can be done. Otherwise will need to change out the card to advance in UNRAID versions. Skip

@JorgeB Before taking the plunge - the AI assistant is recommending trying to append "pcie_aspm=off" to the boot statement - do you think this is worth a try in lieu of flashing first?

@jynxsee I wasn't following the answer "Same firmware" -- same firmware as what? Are you running 16.00.11.00 or 16.00.12.00 ? @JorgeB I'm very hesitant to even try the firmware upgrade as it is the only card I have to drive the external enclosure and these cards have doubled in price now.. Definitely don't want to render my system unusable. I would love to find out if anyone else having this issue is already on 16.00.12...

@JorgeB I could be wrong but for the 9305-16e it appears it is maxed out stable at: IT_Nexus mode - fw: 16.00.11.00, nvdata: 10.00.91.xx: Channel_9305-16e_IT_Nexus.bin Abort Task Set - fw: 16.00.11.00, nvdata: 10.00.92.xx: Channel_9305-16e_ATS.bin I don't believe there is anything newer but definitely could be wrong. Skip

Just one more note- OpenAI analysis spit out: Diagnostics show repeated 30-second I/O timeouts resulting in task aborts and device resets on host0 (LSISAS3216 / SAS9305-16e running FW 16.00.11.00). No corresponding aborts are seen on host1 (LSISAS2308 running FW 20.00.07.00). Rolling back from Unraid 7.3.1 to 7.3.0 immediately resolves the issue. Controller remains operational and does not enter IOC fault state; failures appear to be command timeout related rather than HBA crashes. I'm wondering would BIOS/Firmware update be worth it ? My feeling is no it would not help. Skip

For me it looks like the bios/firmware is: LSISAS3216: FWVersion(16.00.11.00)

Perhaps 7.3.1 as Jorge mentioned might have a regression for LSI 3xxx cards? I had to revert to 7.3.0 to fix my install as well. Ref: https://forums.unraid.net/topic/199098-unraid-730-731-array-startperformance-related-issues/ Skip

@JorgeB Fair enough. I didn't dive into the diagnostic- could you tell if the problem was actually coming from the 3216 or the 2308? I can check firmwares but i was pretty sure these old cards did not have updates. Thanks, Skip

System: Supermicro CS836 chassis with a QNAP enclosure added via LSI SAS3216 Mobo: MSI Pro Z790-P WI-FI with 12700K Drives: 22 mostly WDC SATA in BTRFS Upgrade went smoothly. Rebooted and immediately noticed that UNRAID CLI was reporting the following repeatedly when tyring to scan the hard drives: May 28 09:21:55 BigBoi kernel: I/O error, dev sdh, sector 128 op 0x0:(READ) flags 0x80700 phys_seg 48 prio class 2 May 28 09:21:55 BigBoi kernel: sd 0:0:10:0: attempting task abort!scmd(0x00000000fcba39fa), outstanding for 30463 ms & timeout 30000 ms May 28 09:21:55 BigBoi kernel: sd 0:0:10:0: [sdk] tag#5615 CDB: opcode=0x28 28 00 00 00 00 80 00 01 80 00 May 28 09:21:55 BigBoi kernel: scsi target0:0:10: handle(0x0018), sas_address(0x300062b202aed2ce), phy(14) May 28 09:21:55 BigBoi kernel: scsi target0:0:10: enclosure logical id(0x500062b202aed2c0), slot(4) May 28 09:21:55 BigBoi kernel: scsi target0:0:10: enclosure level(0x0000), connector name( ) May 28 09:21:55 BigBoi kernel: sd 0:0:7:0: Power-on or device reset occurred This happened over and over -- eventually the server booted (30-40 mins) and then allowed me to login where it struggled for another 30 mins to start the array (It eventually did) I was able to grab snippets and diags prior to rolling back to 7.3.0. Roll back successful and everything is running perfect on 7.3.0. Happy to provide more information. Skip bigboi-diagnostics-20260528-0934.zip

I'm running 7.1.2 and running the binhex-plex docker as well. In the last week plex hasn't crashed and i noticed i've updated the docker a couple of times. Hopefully just a fluke. Did you review this thread for spin/up/down ? I let my drives sleep because a few of the drives in the center of my 3U Supermicro cause a lot of heat and the spin down helps my overall temps quite a bit. I've always done this and never have had a problem. Sometimes if someone tries to access media on the drives that are spun down it will take plex a bit to start to stream. As a side note the biggest performance i've gotten was installing a new MSI z790 board and then installing a gen4/5 NVME and making sure appdata was running from that. Skip