deanpelton

I am having this exact green issue after swapping from a 3060 ti over to a 9070 xt. It's driving my nuts, I had it on 7.1.4, and even after upgrading 7.3.0. I have tried binding to VFIO on start (which doesn't work because the GPU gets stuck in D3), i've tried leaving it unbound and running the script below. It displays an output before the AMD drivers are installed, also displays an output when turning on (Unraid Splash screen), then immedately this. I'm fully out of ideas, not sure where it's going wrong and have tried everything in here to fix it. Any ideas? #!/bin/bash GPU="0000:03:00.0" GPU_AUDIO="0000:03:00.1" BAR_INDEX=8 # 8 = 256MB, 3 = 8MB log() { echo "[gpu-prep $(date '+%H:%M:%S')] $*"; } unbind() { local dev="$1" local drvlink="/sys/bus/pci/devices/$dev/driver" if [ -L "$drvlink" ]; then local drv drv=$(basename "$(readlink "$drvlink")") log "Unbinding $dev from $drv" echo "$dev" > "$drvlink/unbind" else log "$dev already unbound" fi } log "Starting" log "Available reset methods: $(cat /sys/bus/pci/devices/$GPU/reset_method)" # Unbind both functions from whatever currently has them unbind "$GPU" unbind "$GPU_AUDIO" sleep 2 # Bus reset to clear any leftover state from amdgpu / framebuffer log "Triggering bus reset on $GPU" if echo 1 > "/sys/bus/pci/devices/$GPU/reset" 2>/dev/null; then log " reset succeeded" else log " reset failed (check dmesg)" fi sleep 2 # Resize BAR2 (only meaningful with CAM/ReBAR enabled in BIOS) log "Resizing BAR2 (index $BAR_INDEX = 256MB)" if echo "$BAR_INDEX" > "/sys/bus/pci/devices/$GPU/resource2_resize" 2>/dev/null; then log " BAR2 resize accepted" else log " BAR2 resize failed (check dmesg)" fi sleep 2 # Force vfio-pci as the only driver allowed to bind to these devices log "Setting driver_override to vfio-pci" echo "vfio-pci" > "/sys/bus/pci/devices/$GPU/driver_override" echo "vfio-pci" > "/sys/bus/pci/devices/$GPU_AUDIO/driver_override" log "Verification:" log " $GPU driver: $(basename "$(readlink /sys/bus/pci/devices/$GPU/driver 2>/dev/null)" 2>/dev/null || echo none)" log " $GPU_AUDIO driver: $(basename "$(readlink /sys/bus/pci/devices/$GPU_AUDIO/driver 2>/dev/null)" 2>/dev/null || echo none)" log "Done. libvirt managed='yes' will bind to vfio-pci when the VM starts." adam-htpc-diagnostics-20260516-2251.zip

It's back to summer here and I was getting constant temp notifications for SAS drive that should be spun down, looking into it the drive letters had changed causing telegraf to persist waking them up again like last time. Just a reminder for anyone with issues with this plugin it's because reading the smart data from the drive (like with telegraf) will spin it up again for sas drives. The only fix i've ever found is excluding them in the conf for telegraf.

Have you tried this command? Note this can put the drives into a standby state that could require a power cycle to bring them back up. You would need to find the number of the drive (sgX instead of shX). sg_start -S /dev/sgX I have no success with the command the script uses which is --pc=3 flag instead of -S, however scrolling back through this thread you will see that there are people whose drives this disabled due to it powering down. So best to test this with the array off and do a reboot after.

Are you running any apps that would poll these drives for status? E.g. Autofan or Telegraf? When you spin the drives down can you hear them spin down and back up again? You might just be unlucky, but I managed to get mine working by putting exclusions in telegraf and Autofan.

Okay I managed to figure this out for my drive as it was a couple of issues by moving the drives into Unassigned Drives. First issue: drive won't stay spun down. Even with everything perfect, issuing --readonly --pc=3 to the drive would not consistently keep it spun down, it would spin down then back up again almost immediately. I swapped from using that to using the line below: sg_start -S /dev/sgX This resulted in MUCH more consistent spin down for my Seagate x16 drives. Is there a reason pc=3 is preferable to -S? Second issue: spinning back up again. When using sg_start --readonly --pc=3 when I spun down my drives, the log would look like this: Mar 8 22:00:07 Adam-HTPC emhttpd: spinning down /dev/sde Mar 8 22:00:07 Adam-HTPC SAS Assist v2022.08.02: Spinning down device /dev/sde Mar 8 22:00:26 Adam-HTPC emhttpd: read SMART /dev/sde The timing was never consistent either, it would be anywhere from 5 - 30 seconds, and then it would spin up again. Thus I assumed something was accessing it that doesn't spin up SATA drives, at this moment I suspect it's Telegraf, which I run for logging. Pausing / Stopping this appears to fix my issue entirely! I suspect the smart_ctl that Telegraf is using appears to spin up the sas drives like it used to with sata drives, and because they take so long to spin down it appears to the user like they never spun down at all. I also suspect that because the Seagate drives take SO long to spin down, that the standby setting is not yet set in SmartCtl, so when Telegraf pings them every 3 seconds, mid-spindown, it spins the drive back up again.

Okay so I've been playing with this for a few days now and moved the Seagate SAS drive to UD. The drive is not mounted and has no data or filesystem on it. I can confirm also that the below command DOES spin the drive down, I hear the platter stop and the head park, and can feel the drive is no longer spinning. sdparm --command=sense /dev/sde sg_start -rp3 /dev/sdx I also run this to confirm it's down sdparm --command=sense /dev/sg4 /dev/sg4: SEAGATE ST10000NM002G E004 Additional sense: Standby condition activated by command The issue is... it spins back up! And continues to click and move the head like it's doing something perpetually. I've turned off BMS (self scan), and confirmed it's not actually scanning using smartctl -x. Really stuck as to what the hell the drive is doing, File Activiy shows nothing, I'm not running system fan. Open to idea's as to where to look, but I very much would like to fill my server with these but not if they are going to waste power.

So I upgarded to a SAS 2308 controller (from the Dell H310), and also got a couple more SAS drives. It appears to work intermittetly with the HUH721010AL5200 (WD Ultrastar DC HC510), but not at all with the Seagate x16's I have. Has anyone have Seagate x16's they have managed to spin down?

So I ran the command, the status on the Unraid page did not change. Running the status command immedately after gave the following: /dev/sdf: SEAGATE ST10000NM002G E003 Unsure what this means.

The drive is a parity drive and all other drives are spun down during my attempts. I am running Unraid 6.11.5. I suspected this so I spin it down, then quickly refresh the page on another webpage to see if it goes grey, however it doesn't. Is there another way to test?

Hi, I'm running ST10000NM002G with a Dell H310 and this plugin appears not to work. I get the following in my log: Feb 21 12:50:00 Adam-HTPC emhttpd: spinning down /dev/sdf Feb 21 12:50:00 Adam-HTPC SAS Assist v2022.08.02: Spinning down device /dev/sdf Feb 21 12:50:19 Adam-HTPC emhttpd: read SMART /dev/sdf However the drive does not appear to spin down. I read through the entire thread and I can't see anyone comming on my specific combo, wondering if anyone else is running Seagate X16 SAS drive OR a Dell H310 and has it working?

Hi All, I know this is a stupid question, however search and youtube has found me no satisfying answers, so here I am posting. I have just purchases an ex mining SAS drive for Unraid Exos 10tb (around 4k hours, good deal!). I run a Dell H310, with 7 connected SATA HDD's using standard breakout SAS to SATA cables. I know that I can mix and match with a HBA, and that SAS drives have drop in support for Unraid. Where I am stuck is how to connect and power my new SAS drive. AFAIK there is a different connection on the SAS drive that means it's not a direct connection to the HBA, so whats the best avenue for connecting and powering the SAS drive on my final connection on the HBA. Do I need an adapter like this. Or am I way off?

I have one of these in a node 804. At idle sits at 35c, however under heavy load peaks at around 45. Yours seems slightly higher, but my drive sits around a lot of airflow so seems normal.

Okay after reading another forum post about docker permissions issues, i have figured it out!. The issue was the script was owned by a user it seems. Changing ownership of the script from user to nobody let's qbittorrent run it fine. Interested to know specifically what change in 6.10.3 makes this the case, I went through the change log with a fine tooth cone and couldn't see anything obvious.

I upgraded from 6.9.2 last night to 6.10.3 without any other issues. However, I am also running an automation script on my binhex/arch-qbittorrentvpn:4.3.3-1-07 docker. The script is designed to unrar files and send them to encode based on their names. I have not updated this docker, and tested the script by putting in the variables manually, however I get 'can not access file, permissions denied'. Files are created by the docker with umask 000, and are rw by everyone. So really struggling to see a solution. Can anyone else tell me what may have changed in the new version of unraid that is stopping my script from running? TorrentMove.bash adam-htpc-diagnostics-20220814-1201.zip

Okay I rebuilt onto an IronWolf I had hot spare. Precleared the drive (which went very fast!) then tried to write the 3TB back to it. Got 1tb in then write speed tanked. RMA'ing the drive now.