I'm seeing the errors below when pressing the "Spin Up" button in array operation. It does not happen every time but I'd like to know if it's something I need to be concerned about.

 

Aug  9 10:03:51 Tower emhttpd: spinning up /dev/sdm
Aug  9 10:03:51 Tower emhttpd: spinning up /dev/sdj
Aug  9 10:03:51 Tower emhttpd: spinning up /dev/sdh
Aug  9 10:03:51 Tower emhttpd: spinning up /dev/sdn
Aug  9 10:03:51 Tower emhttpd: spinning up /dev/sdo
Aug  9 10:04:06 Tower kernel: sd 8:0:3:0: attempting task abort!scmd(0x0000000005360bfc), outstanding for 15189 ms & timeout 15000 ms
Aug  9 10:04:06 Tower kernel: sd 8:0:3:0: [sdo] tag#154 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e3 00
Aug  9 10:04:06 Tower kernel: scsi target8:0:3: handle(0x000a), sas_address(0x4433221102000000), phy(2)
Aug  9 10:04:06 Tower kernel: scsi target8:0:3: enclosure logical id(0x500605b00154ee80), slot(1) 
Aug  9 10:04:06 Tower kernel: sd 1:0:4:0: attempting task abort!scmd(0x000000006154ea74), outstanding for 15187 ms & timeout 15000 ms
Aug  9 10:04:06 Tower kernel: sd 1:0:4:0: [sdh] tag#141 CDB: opcode=0x85 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e3 00
Aug  9 10:04:06 Tower kernel: scsi target1:0:4: handle(0x000b), sas_address(0x4433221104000000), phy(4)
Aug  9 10:04:06 Tower kernel: scsi target1:0:4: enclosure logical id(0x500605b001550580), slot(7) 
Aug  9 10:04:07 Tower emhttpd: sdspin /dev/sdh up: 22
Aug  9 10:04:07 Tower kernel: sd 1:0:4:0: task abort: SUCCESS scmd(0x000000006154ea74)
Aug  9 10:04:07 Tower kernel: sd 8:0:3:0: task abort: SUCCESS scmd(0x0000000005360bfc)
Aug  9 10:04:07 Tower emhttpd: sdspin /dev/sdo up: 22
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdm
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdj
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdk
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdh
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdg
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdd
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sde
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdb
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdf
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdc
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdn
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdo
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdl
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdi
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sdp
Aug  9 10:04:07 Tower kernel: sd 8:0:3:0: Power-on or device reset occurred
Aug  9 10:04:07 Tower emhttpd: read SMART /dev/sda
Aug  9 10:04:30 Tower kernel: sd 8:0:3:0: Power-on or device reset occurred
Aug  9 10:05:39 Tower kernel: sd 1:0:4:0: Power-on or device reset occurred

 

On a separate note but also spin related, my daily status notifications always show my parity disks (sdp, sdg) as active although the web interface shows them as spun down.

tower-diagnostics-20240809-1005.zip

Some Seagate disks have issues with spin up on LSI controllers, see here for more info:

 

 

 

I did what was advised in the post and I disabled EPC and low power spinup on the 2 disks that were having the issue. I completely powered down and restarted. At the moment I don't see the issue on sdo but still see it on sdh. I did verify that the settings applied before the shutdown and rechecked that they were still active now before posting. In case it means something if I click the spindown button (green ball) on the individual disk it will briefly show the rotating arrows but no spindown takes place. To be clear other disks spin down as expected. I can see the request is being sent by the browser in dev tools but I also don't see an entry in the unraid log showing that a spindown was sent to the disk. Any ideas?

tower-diagnostics-20240809-1805.zip

If after doing that they still show errorws I would recommend disabling spin down for those disks, or connect them to a different controller, like the onboard SATA for example.

One more question, I've had the same LSI controllers and the two affected drives for many years. This behavior seems to be very recent, is it tied to the unraid version? The other topic you had linked seems to make it a problem between the controller and the disc but if that were the case I should have seen this a long time ago. To be fair it's not like I watch the unraid log for errors I typically only look if something else points me in that direction. But the affected disc doesn't spin down anymore based on the unraid rules, that I would have noticed. The spin down problem just started happening recently. I guess my question is could this be caused by anything else? Could I have any bad hardware? Is it worth replacing the disc? Thank you so much for all of your help.

19 hours ago, WizADSL said:

is it tied to the unraid version?

Likely tied to kernel and/or LSI driver versions.

I've been keeping an eye on the log and so far the error only seems to happen if a manual spin up is performed. If the drive spins up due to a data read it does not happen and I haven't seen it happen when a spin down takes place. I may have noticed it because I usually do a manual "spin up all" when bringing down the array and due to the disk errors I've had recently (in another thread) I've been doing that a lot more than usual. I'm going to keep watching it for a while to see if the behavior holds.