Hey,

 

I'm usually getting these log entries during disk spin up:

 

kernel: sd 14:0:3:0: attempting task abort!scmd(0x00000000155105fb), outstanding for 15511 ms & timeout 15000 ms
kernel: sd 14:0:3:0: [sdg] tag#4740 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00
kernel: scsi target14:0:3: handle(0x000b), sas_address(0x4433221104000000), phy(4)
kernel: scsi target14:0:3: enclosure logical id(0x500605b00a071021), slot(7) 
kernel: scsi target14:0:3: enclosure level(0x0000), connector name(     )
kernel: sd 14:0:3:0: task abort: SUCCESS scmd(0x00000000155105fb)

 

If there is an immediate read or write attempt I also get a disk read or write error.

I'm using seagate iron wolf drives. These drives apparently have an average spin up time of 20+ seconds. So I'm assuming the 15 second timeout is the problem here not giving the disks enough time to spin up. Is that timeout coming from the controller or unraid? If it is unraid where can this value be set?

 

So far I have replaced all SAS cables, and the controller card. I also have moved the disks around in the drive cages. Behavior is exactly the same, nothing changed. So increasing the timeout is probably the next logical step.

 

Thanks in advance.

 

 

Edited January 24, 20224 yr by Ariyala

Check this:

https://forums.unraid.net/topic/103938-69x-lsi-controllers-ironwolf-disks-disabling-summary-fix/?do=getNewComment

 

Thank you for linking this thread, I will look into the firmware.

However is anyone working on UNRAID looking into this? The features suggested to disable seem like something a NAS would benefit from. Especially low current spin up when you have many drives.

I understand the thread suggests this is a Seagate / LSI problem, but if UNRAID is the only system running into issues with that hardware configuration it seems unlikely.

Is there any way to increase the 15second timeout for spin up? Low current spin up takes longer, so just giving the drives more time might solve it without having to disable beneficial drive features.

Edited January 27, 20224 yr by Ariyala

4 hours ago, Ariyala said:

but if UNRAID is the only system running into issues with that hardware configuration it seems unlikely.

It will affect any Linux based system, not just Unraid.

I have disabled EPC and low current spin up in the drive firmware and so far the timeout has not appeared in the log again.

Unfortunate that these two drive features are not usable, but better than rebuilding the array every few days.

 

If anyone has any idea where to increase the drive timeout I would still be happy to get that information and try out if at least low current spin up is usable.

 

Thank you @JorgeB for linking the other thread, as far as I can tell it is a good workaround for my issue.

Edited February 2, 20224 yr by Ariyala

I faced the same issue and disabling EPC and low current spin up did not make this timeout go away.
I also tried increasing /sys/block/sd*/device/eh_timeout and /sys/block/sd*/device/timeout but that also did not help.

I think I finally narrowed down the issue to SCT ERC (Error Recovery Control).
View the current value of the drive SCT ERC with smartctl -l scterc /dev/sd* make sure to replace the * with your drive's letter.
Mine was all at 7s. This means when the drive is spinning up and can't respond within 7 seconds, it returns an error, which then triggers the SCSI abort.

So I setup a user script to increase it for all my drives:

```
# Increase SCT ERC timeout for all drives to handle spin-up

for dev in /dev/sd?; do

smartctl -l scterc,150,150 "$dev" 2>/dev/null

done
```

This increase it to 15 seconds for all my drives and so far I have not seen any new timeout errors in the log.

Edit: it has been 15 hours and the error has appeared again in the log. I guess my problem is not from this. No clue what to do now except disabling spin-down entirely and just leave array spinning all the time.
If anyone has any clue what to try next, do let me know.

Edited December 7, 2025Dec 7 by Sak