half

Hi, just wanted to give a quick update on the sas spindown issue i had with the SAS Controller i reported earlier. So it doesnt matter what sas drive i spin down, the reason its not waking up again is the controller believes that a bus error occurred. Here the dmesg output after a sdspin down of a seagate drive: [303126.462121] sas: Enter sas_scsi_recover_host busy: 1 failed: 1 [303126.462123] sas: trying to find task 0x00000000a2a13202 [303126.462124] sas: sas_scsi_find_task: aborting task 0x00000000a2a13202 [303126.462274] pm80xx0:: mpi_ssp_completion 1932:sas IO status 0x1 [303126.462276] pm80xx0:: mpi_ssp_completion 1944:SAS Address of IO Failure Drive:5000c500a61b9e91 [303126.462277] pm80xx0:: mpi_ssp_completion 2158:task 0x00000000a2a13202 done with io_status 0x1 resp 0x0 stat 0x8d but aborted by upper layer! [303126.462282] sas: sas_scsi_find_task: task 0x00000000a2a13202 is done [303126.462283] sas: sas_eh_handle_sas_errors: task 0x00000000a2a13202 is done [303126.462289] sas: ata7: end_device-7:4: dev error handler [303126.462291] sas: ata8: end_device-7:5: dev error handler [303126.462293] sas: ata9: end_device-7:6: dev error handler [303126.462295] sas: ata10: end_device-7:7: dev error handler [303126.462296] sas: ata11: end_device-7:8: dev error handler [303126.462297] sas: ata12: end_device-7:9: dev error handler [303126.462303] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 1 tries: 1 I can fix it by basically unplugging and replugging the drive. That way the controller recovers from the sas_scsi_recovery_host error. So the disk tested was this time a : ST4000NM0025 Connected to a : supermicro aoc-s8076l-l16e That is basically an adaptec sas controller. Driver is pm80xx0 , The funny thing is the 6 sata drives connected to the same controller spin down fine and come back up. So i assume a deeper issue with libsas and the pm80xx driver. Just wanted to let you know if you want to put that combo into your blacklist. Regards,

i wouldnt assume the effect to be different because -r only does ReadOnly. So not sure, as i just went trough crash 3 resets and some soft reboots will try again tomorrow. But i fear there is something weird with the Controller HDD combo. As a simple IO to the device should actually start it up again imho

Hi, sure thing: lspci -k : 01:00.0 Serial Attached SCSI controller: Adaptec Device 8076 (rev 06) Subsystem: Super Micro Computer Inc Device 1600 Kernel driver in use: pm80xx Kernel modules: pm80xx sg_start -rp3 /dev/sdf sdparm -C sense /dev/sdf /dev/sdf: HGST HUH721010AL5200 A21D Additional sense: Standby condition activated by command sg_start -rs .... long wait nothing happens while I/O errors in dmesg [18525.321658] sd 1:0:1:0: [sdf] tag#663 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08 cmd_age=0s [18525.321660] sd 1:0:1:0: [sdf] tag#663 Sense Key : 0x2 [current] [descriptor] [18525.321661] sd 1:0:1:0: [sdf] tag#663 ASC=0x4 ASCQ=0x11 [18525.321662] sd 1:0:1:0: [sdf] tag#663 CDB: opcode=0x88 88 00 00 00 00 04 8c 3f ff 00 00 00 00 08 00 00 [18525.321663] blk_update_request: I/O error, dev sdf, sector 19532873472 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0 [18525.321870] Buffer I/O error on dev sdf1, logical block 19532871424, async page read [18525.321965] Buffer I/O error on dev sdf1, logical block 19532871425, async page read And then kernel panic a moment after that.....

Hi, i am currently using a Supermicro HBA with 15 Drives connected to it. 8 of them are SAS. My problem is not that the drives don't spin down. Currently they never come back up. Causing Unraid to belive that there is an IO Error. It also doesnt matter what command you throw at the spun down drive. Nothing gets them back, not even an hard reset of the server btw. A power cycle reactivates them and they show up back fine after the power cycle. Controller: 01:00.0 Serial Attached SCSI controller: Adaptec Device 8076 (rev 06) Dmesg: [ 17.223324] pm80xx 0000:01:00.0: pm80xx: driver version 0.1.40 [ 17.224929] :: pm8001_pci_alloc 523:Setting link rate to default value [ 18.243882] scsi host1: pm80xx SAS Spindown Utility (v20210201.01) sdf | HUH721010AL5200 | 9005:8076:15d9:1600 | n/a | sde | HUH721010AL5200 | 9005:8076:15d9:1600 | n/a | sdg | HUH721010AL5200 | 9005:8076:15d9:1600 | n/a | sdh | HUH721010AL5200 | 9005:8076:15d9:1600 | n/a | sdo | ST4000NM0025 | 9005:8076:15d9:1600 | n/a | sdp | ST4000NM0025 | 9005:8076:15d9:1600 | n/a | sdq | ST4000NM0025 | 9005:8076:15d9:1600 | n/a | sdr | ST4000NM0025 | 9005:8076:15d9:1600 | n/a | I also tryed the default method with the Idle Timer and sgutils . They spin down fine but never back up ..... Unraid is 6.9.0-rc2 Unfortnuatly the HBA is weird is hell, because Supermicro is not offering any documentation. You can find something about it here: https://www.supermicro.com/wdl/driver/SAS/Microsemi/8076/B11419 Official product number: SMC AOC-S8076-L16E Any ideas would be really appreciated. Regards, sas-util-out

Hi, I wanted to give some info as well. I have seen this issue starting with 6.3.x and a BTRFS Cache pool. What i can tell you that the cause is based on the kernel in the system. An easy way to test the behaviour is to use dd command to simulate the write operations. "dd bs=1M count=8096 if=/dev/zero of=test conv=fdatasync; rm test" This command creates an 8GB Test file and will delete it afterwards. You can execute the command in /mnt/cache/ on the system. You will see high IO waits and Load going up. So far nothing weird.This will also work on mounted SSD´s from unassigned devices or on any other disk btw. If you use a program like netdata. ( you can find an easy to use docker to start it on your unraid server) you should watch for three things. Interrupts Network Memory->Kernel (especially the dirty pages). On a "good" (4.9.10 Unraid 6.3.2 ) kernel, you will see that Interrupts & Network are still flowing along while you perform the DD on the SSD. On a "bad" (4.12.12 Unraid 6.4rc9f) kernel, you will see that interrupts & networking break down while the DD is running. Especially interesting is that in this case, Dirty Pages on the Memory tab are either going together well with writeback OR there will be a gap and the writeback is delayed. IMHO: I believe that the behaviour has to do with the amount of available memory in your system and the kernel's handling of dirty pages and writebacks. Why certain kernels are going in this blocking behaviour and other not so much or not at all I cannot explain easily. I believe that BTRFS raid 0/1 modify some of the behaviours that is why I switched to an XFS based single Cache drive. I do not have any lockings since i moved to XFS. My system: Model: Custom M/B: Supermicro - X9SRE/X9SRE-3F/X9SRi/X9SRi-3F CPU: Intel® Xeon® CPU E5-2650 0 @ 2.00GHz HVM: Enabled IOMMU: Enabled Cache: 512 kB, 2048 kB, 20480 kB Memory: 96 GB (max. installable capacity 512 GB)