Skipdog

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)