Skipdog

I had gone through trying to log something before but received zero respond/reply. I'm not sure it is worth it honestly because how many people are utilizing QNAP enclosures? Probably very few honestly. The workaround is to populate all slots -- or eliminate a set of four via unplugging HBA cable. Either solution works great. I am running the 7.4 beta2 as i was heading down the avenue of replacing the HBA to a 9400. I'm very glad I didn't do this as I would have most likely encountered the same exact problem with the 9400. Thanks! Skip

Quick post-mortem on this issue, because I think I finally isolated what was actually happening. My setup is an LSI/Broadcom 9305-16e (SAS3216, mpt3sas) connected to a QNAP external SATA enclosure. I originally suspected a regression in the 9305-16e / SAS32xx path because the problem appeared on newer Unraid versions and went away when rolling back. After more testing, I no longer think the 9305 itself is the root cause. The key discovery was that every empty drive position in the QNAP enclosure was being exposed to Linux as a ~100 MB device named: ASMT109x- ConfigWith four empty bays, I had four of these pseudo-devices. On the affected Unraid/kernel versions, Linux repeatedly attempted to read from them, including reads around sector 128. Those requests would hang for roughly 30 seconds, get aborted/reset, and then be retried. That caused the very long boot/device-enumeration delays and continued generating I/O errors even after the Unraid GUI was already available. The actual SATA disks connected through the same 9305-16e were enumerating normally. I then physically rearranged drives in the QNAP enclosure and was able to show that the ASMT109x- Config devices followed the empty bay positions. When I moved a real SATA disk into one of those positions, the ASMT pseudo-device disappeared and the real disk appeared at that same logical SAS address. As a final test, I fully populated the QNAP enclosure with real SATA disks. On the next boot: no ASMT109x- Config devices appeared no repeated task abort messages no repeated I/O errors the 9305-16e initialized normally mpt3sas_cm0: port enable: SUCCESS boot time returned to normal So in my case, the apparent 9305 / mpt3sas regression is really triggered by the QNAP exposing empty SATA positions as ASMT109x- Config pseudo-devices. The HBA itself appears to work normally on the same newer Unraid build once those pseudo-devices are no longer present. My current workaround is simply to keep all connected QNAP SATA positions populated with real drives. Another workable approach would be to consolidate real disks onto complete 4-drive cable groups and disconnect the cable serving an entirely empty group. @JorgeB — does this look like something that should be raised with the Unraid developers, or is it more appropriately treated as an upstream Linux SCSI / mpt3sas issue? What makes me wonder if it is worth handling in Unraid is that older Unraid/kernel versions tolerated these ASMT109x- Config endpoints, while the newer versions repeatedly probe/reset them badly enough to cause 20+ minute boot times. There also appears to be an existing Linux/libata quirk for ASMT109x- Config devices in some ATA paths, so I’m wondering whether presenting them through the QNAP + mpt3sas SCSI path bypasses that handling. If useful, I can provide before/after diagnostics showing the four ASMT pseudo-devices and timeout loop versus the fully populated enclosure with the exact same 9305-16e working normally.

@Auggie That is good to know. I'm looking at a 9400-16e-- i need to drive a QNAP enclosure (thus the 16e) -- i'm wondering if there is any difference between the 16i and 16e as far as compatibility. I tried to log linux regression tickets but got zero response (not surprising) I found an intel based 9400-16e on ebay for about 140$ which isn't terrible. I have to think that this bug will get fixed though. Skip

I did send an email to the slackware submission email box... but do you think this needs to go to the linux main kernel team - any ideas which avenue is best to engage? Skip

@JorgeB I attempted 7.3.2 -- but the regression is still present. I am going to attempt to file an inquiry on whether they are aware of the issue.

@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

@andykai Are you running the latest 7.12 or 7.x? My Plex has been doing the same thing now every couple of days and it started with the most recent 7.1 release/patches. Plex appears to be up sometimes but when trying to stream media it doesn't play. Other times the server is actually down (alerted by Plex Dash or Tautulli. My disks have spun down for years so I don't think that is it. I need to find the location of the plex log file to see why it thinks it is crashing.

Thank you! Good to go! Skipdog

Balance completed! I see the space issue looks correct now. New diags attached here. I assume I can do something as you said to collapse the pool to 1? Skip unraid-diagnostics-20250123-1524.zip

Hi JorgeB, Yes for now I want to have a pool with a single NVME drive with the original size of 2TB. Skipdog

JorgeB, Thank you so much that got my cache drive back up and working. I'll definitely perform a backup now of appdata. It looks like when I assigned the single drive and it mounted it returned the pool devices to original 2 slot. Should I invoke mover and get it all back on the array and then wipe the cache and then user mover to reduce cache drive to 1? Also the 2TB is showing half the capacity. New Diags uploaded. Skipdog unraid-diagnostics-20250122-1520.zip