craigr

i915 Is for the Intel’s GPU. you can also create the file in windows just by navigating there and creating a new text file with extension .conf. craigr

This guide by lotetreemedia has been very helpful for me, but starting with unRAID 6.9.x the steps that are unraid specific should be done differently because unRAID has implemented GPU drivers. Everything lotetreemedia says to do in PLEX is still valid, but activating the driver is different. If you have lines in your "go" file you should remove them and change unRAID as follows: https://wiki.unraid.net/Unraid_OS_6.9.0#GPU_Driver_Integration After completing lotetreemedia 's steps in the PLEX docker, all I had to do to get QuickSync working with 6.9.1 was remove the lines from my "go" file and create a file in \flash\config\modprobe.d\i915.conf. The i915.conf file is just empty. craigr

All 17 data drives were spun up; not the PARITY drives though. craigr

Well hold on. I had rebooted earlier today and the drives had only had the SMART read once since then. I just restarted File Activity and each drive, one by one, is getting spun up and SMART read. This will require further investigation so I'll play with it. craigr

All my info is in my sig if you need it, version 6.9.1. I was running the file activity plugin, but I actually turned it off to test if this was causing the issue. Not surprisingly it's not the file activity plugin. With file activity running, it does not show any files being accessed either. The only thing is that the log says SMART is checked and the drive is spun down. craigr

Yeah, I have been wondering about this too. Mar 12 12:02:55 unRAID emhttpd: spinning down /dev/sdn Mar 12 12:02:58 unRAID emhttpd: spinning down /dev/sdg Mar 12 12:02:58 unRAID emhttpd: spinning down /dev/sdw Mar 12 12:02:58 unRAID emhttpd: spinning down /dev/sdd Mar 12 12:02:58 unRAID emhttpd: spinning down /dev/sdt Mar 12 12:02:58 unRAID emhttpd: spinning down /dev/sde Mar 12 12:02:58 unRAID emhttpd: spinning down /dev/sdu Mar 12 12:02:58 unRAID emhttpd: spinning down /dev/sdr Mar 12 12:02:58 unRAID emhttpd: spinning down /dev/sds Mar 12 12:02:58 unRAID emhttpd: spinning down /dev/sdq Mar 12 12:02:58 unRAID emhttpd: spinning down /dev/sdp Mar 12 12:03:02 unRAID emhttpd: spinning down /dev/sdm Mar 12 12:03:02 unRAID emhttpd: spinning down /dev/sdj Mar 12 12:03:02 unRAID emhttpd: spinning down /dev/sdh Mar 12 12:03:02 unRAID emhttpd: spinning down /dev/sdf Mar 12 12:03:02 unRAID emhttpd: spinning down /dev/sdv Mar 12 12:03:02 unRAID emhttpd: spinning down /dev/sdo Mar 12 12:03:02 unRAID emhttpd: spinning down /dev/sdi Mar 12 14:06:20 unRAID nmbd[11338]: [2021/03/12 14:06:20.406871, 0] ../../source3/nmbd/nmbd_become_lmb.c:397(become_local_master_stage2) Mar 12 14:06:20 unRAID nmbd[11338]: ***** Mar 12 14:06:20 unRAID nmbd[11338]: Mar 12 14:06:20 unRAID nmbd[11338]: Samba name server UNRAID is now a local master browser for workgroup WORKGROUP on subnet 192.168.1.15 Mar 12 14:06:20 unRAID nmbd[11338]: Mar 12 14:06:20 unRAID nmbd[11338]: ***** Mar 12 14:41:42 unRAID emhttpd: read SMART /dev/sdj Mar 12 15:26:55 unRAID emhttpd: read SMART /dev/sdh Mar 12 16:09:26 unRAID emhttpd: read SMART /dev/sdi Mar 12 16:10:19 unRAID emhttpd: read SMART /dev/sdw Mar 12 16:11:08 unRAID emhttpd: read SMART /dev/sdu Mar 12 16:12:35 unRAID emhttpd: read SMART /dev/sdf Mar 12 16:12:46 unRAID emhttpd: read SMART /dev/sde Mar 12 16:13:23 unRAID emhttpd: read SMART /dev/sdd Mar 12 16:13:42 unRAID emhttpd: read SMART /dev/sdq Mar 12 16:13:57 unRAID emhttpd: read SMART /dev/sdp Mar 12 16:14:24 unRAID emhttpd: read SMART /dev/sdt Mar 12 16:14:42 unRAID emhttpd: read SMART /dev/sds Mar 12 16:15:34 unRAID emhttpd: read SMART /dev/sdr Mar 12 16:16:03 unRAID emhttpd: read SMART /dev/sdv Mar 12 16:17:54 unRAID emhttpd: read SMART /dev/sdg Mar 12 16:52:49 unRAID emhttpd: read SMART /dev/sdn Mar 12 16:55:00 unRAID emhttpd: read SMART /dev/sdm Mar 12 16:55:00 unRAID emhttpd: read SMART /dev/sdo Mar 12 17:11:09 unRAID emhttpd: spinning down /dev/sdu Mar 12 17:12:47 unRAID emhttpd: spinning down /dev/sde Mar 12 17:14:00 unRAID emhttpd: spinning down /dev/sdp Mar 12 17:14:27 unRAID emhttpd: spinning down /dev/sdt Mar 12 17:14:45 unRAID emhttpd: spinning down /dev/sds Mar 12 17:14:53 unRAID emhttpd: spinning down /dev/sdd Mar 12 17:15:51 unRAID emhttpd: spinning down /dev/sdr Mar 12 17:16:22 unRAID emhttpd: spinning down /dev/sdf Mar 12 17:16:29 unRAID emhttpd: spinning down /dev/sdw Mar 12 17:16:29 unRAID emhttpd: spinning down /dev/sdq Mar 12 17:16:36 unRAID emhttpd: spinning down /dev/sdi Mar 12 17:17:55 unRAID emhttpd: spinning down /dev/sdg Mar 12 17:18:20 unRAID emhttpd: spinning down /dev/sdv Mar 12 17:39:46 unRAID emhttpd: spinning down /dev/sdj Mar 12 17:41:18 unRAID emhttpd: read SMART /dev/sdj Mar 12 17:47:23 unRAID ool www[32538]: /usr/local/emhttp/plugins/dynamix/scripts/notify 'smtp-init' Mar 12 17:56:21 unRAID emhttpd: spinning down /dev/sdm Mar 12 17:56:21 unRAID emhttpd: spinning down /dev/sdn Mar 12 17:56:21 unRAID emhttpd: spinning down /dev/sdo Mar 12 17:56:24 unRAID emhttpd: read SMART /dev/sdv Mar 12 17:56:57 unRAID emhttpd: read SMART /dev/sdi Mar 12 17:57:13 unRAID emhttpd: read SMART /dev/sdr Mar 12 17:57:43 unRAID emhttpd: read SMART /dev/sde Mar 12 17:57:59 unRAID emhttpd: read SMART /dev/sdg Mar 12 17:58:30 unRAID emhttpd: read SMART /dev/sdp Mar 12 17:58:44 unRAID emhttpd: read SMART /dev/sdw Mar 12 17:59:05 unRAID emhttpd: read SMART /dev/sdf Mar 12 18:00:05 unRAID emhttpd: read SMART /dev/sdu Mar 12 18:00:16 unRAID emhttpd: read SMART /dev/sdt Mar 12 18:00:49 unRAID emhttpd: read SMART /dev/sdd Mar 12 18:01:10 unRAID emhttpd: read SMART /dev/sdq Mar 12 18:02:56 unRAID emhttpd: read SMART /dev/sds Mar 12 19:00:21 unRAID emhttpd: read SMART /dev/sdn Mar 12 19:03:21 unRAID emhttpd: spinning down /dev/sdg Mar 12 19:04:27 unRAID emhttpd: spinning down /dev/sdt Mar 12 19:04:57 unRAID emhttpd: spinning down /dev/sdu Mar 12 19:05:09 unRAID emhttpd: spinning down /dev/sdq Mar 12 19:05:12 unRAID emhttpd: spinning down /dev/sds Mar 12 19:05:31 unRAID emhttpd: spinning down /dev/sde Mar 12 19:06:00 unRAID emhttpd: spinning down /dev/sdp Mar 12 19:06:04 unRAID emhttpd: spinning down /dev/sdd Mar 12 19:06:10 unRAID emhttpd: spinning down /dev/sdr Mar 12 19:06:13 unRAID emhttpd: spinning down /dev/sdk Mar 12 19:06:31 unRAID emhttpd: spinning down /dev/sdw Mar 12 19:06:52 unRAID emhttpd: spinning down /dev/sdv Mar 12 19:07:01 unRAID emhttpd: spinning down /dev/sdh Mar 12 19:07:03 unRAID emhttpd: spinning down /dev/sdf Mar 12 19:07:08 unRAID emhttpd: spinning down /dev/sdi Mar 12 19:07:11 unRAID emhttpd: spinning down /dev/sdj Mar 12 19:11:23 unRAID emhttpd: read SMART /dev/sdk Mar 12 19:23:44 unRAID ool www[4095]: /usr/local/emhttp/plugins/dynamix/scripts/notify 'cron-init' Mar 12 19:27:41 unRAID ool www[5874]: /usr/local/emhttp/plugins/dynamix/scripts/notify 'cron-init' Mar 12 19:42:11 unRAID ool www[24315]: /usr/local/emhttp/plugins/dynamix/scripts/notify 'cron-init' Mar 12 20:00:22 unRAID emhttpd: spinning down /dev/sdn Mar 12 20:41:34 unRAID emhttpd: read SMART /dev/sdj Mar 12 20:42:54 unRAID emhttpd: read SMART /dev/sdv Mar 12 21:51:09 unRAID emhttpd: spinning down /dev/sdj Mar 12 22:11:40 unRAID emhttpd: spinning down /dev/sdk

It will work fine this way. I have used half a dozen of the M1015 cards and they are great if all you need is PCIe 2x. craigr

Wow again and double thanks because the new usage of modprobe is included in the release notes you posted so I finally got that all cleaned up and the commands out of my go file. craigr

Wow, that is great. It really is better implementation too and one less plugin to worry about. Thanks again, craigr

Thanks, I had no idea. Where is it located? Best, craigr

Not usually necessary and a pain too because you have to stop docker and all VM's first. I was just thinking it might be a work around for others and also give some insight into the problem. craigr

Been getting this error since I started using 6.9 RC1: VFIO-PCI CFG has been working fine and is working fine for me in 6.9.1 official release. Thanks, craigr

Been getting this error since I started using 6.9 RC1: VFIO-PCI CFG has been working fine and is working fine for me in 6.9.1 official release. Thanks, craigr

Been getting this error since I started using 6.9 RC1: VFIO-PCI CFG has been working fine and is working fine for me in 6.9.1 official release. Thanks, craigr

Well that shoots my theory down. Did you have the array stopped or was it still running? craigr

I had no issues upgrading from 6.9 RC2, but I had already turned off docker, shutdown my VMs, and stopped my array to make the FLASH backup. In that state, I upgraded to 6.9.1 and restarted. I think on both RC1 and RC2 I had the unsafe shutdown notification after upgrading. So if you are running dockers or VM's, it may be a good idea to shut them down before the upgrade. However, when I got the unsafe shutdown, there were no parity sync errors anyway so it's probably not a big deal. craigr

You catch more flies with honey. craigr

I don't think you should waste a second hard drive on parity. One parity disc is enough on unRAID especially with how few discs you have. Remember unRAID is not RAID so even if you were to lose two discs the data on the remaining discs would still be there and you wouldn't be out everything. Furthermore, unRAID does not wear all the discs evenly because to retrieve data it only needs to spin up one disc at a time. This makes it less likely that you will lose multiple discs around the same time. You can also consider starting with dual parity and then when your system is getting full you may convert parity two to a data disc easily. I have 19x 8TB drives now with dual parity, but as soon as I get near full I'm dropping the second parity disc and converting it to data. craigr

I just got this error during a parity check: Is there an incompatibility on RC2? Thanks, craigr

Well that sure makes it easy. Thanks! Last night I rebooted the server though and the fans refused to go below their max speeds. It sounded like I was sitting next to a jet airplane about to take off. I tried so many setting and the fans would just sometimes slow down for an instant. Finally had to reboot the BMC and then it was fine. The settings in the BMC for fan mode keep changing themselves though and I don't understand how that can happen. My choices are: Set Fan to Standard Speed Set Fan to Full Speed Set Fan to Optimal Speed Set Fan to PUE2 (Power Utilization Effectiveness) Speed Set Fan to HeavyIO Speed It used to be set on "optimized" but ever since I tried PUE2 now it seems to randomly be changing its self. I tried setting back to optimized, but it still keeps changing its self and has now chosen full speed. Fan Speed seems to override this regardless so maybe it doesn't matter? I had my config modified for Fan Control to what seemed like good settings, but reverted it last night. I may try putting that back in again so that the percentages aligh with what my fans can actually do. Kind regards, craigr

So that does it and I was able to reduce my high temperature threshold down to 45 degrees where I want it. Will this make the fans run at 100% when the hard drives hit 45 degrees? What exactly is low temperature threshold? It seems counterintuitive to me that raising it will reduce fan speed, but it did. Thanks, craigr

Sorry if this has been explained elsewhere and if it has I would appreciate a link. My config is in my signature but its a SuperMicro X11SCZ-F motherboard with four Noctua NF-P14s redux-1500 PWM fans connected to FAN1 and FAN4. I have these fans set to poll the hard drives for temperatures. The trouble is that they are running too fast most of the time and not as fast as I'd like them to during a parity sync. I just switched to "Fan to PUE2 (Power Utilization Effectiveness) Speed" but it seems identical to "Fan to Optimal Speed." With my high temperature threshold set to 50 degrees the fans usually run at around 1100 RPM with hard drive temperatures around 34 degrees (normal temps in my system). I'd like to try and get this down to around 900 RPM as the fans are much quieter here and the fans spinning at 1100 RPM isn't really lowering the temperatures anyway. What I would like is for the fan speeds to exponentially increase with respect to temperature such that at 45 degrees the fans run at their full 1500 RPM. The trouble with the top end is that I have never seen the fans go above 1300 RPM even when the hard drives are above 45 degrees (and even if they actually hit 50 degrees) which can happen during parity syncs in Summer. I can get the fans to run slower by raising the high temperature threshold, but then of course they don't run fast enough when the hard drives get hot. Is there any way to have my cake and eat it too? Thanks for any help, craigr

I don’t ever sleep the server, only the Windows 10 VM running on it. craigr

Want to say thanks again for CA Backup / Restore Appdata as it just saved me a lot of time. I changed the location of my appdata folder to a different hard drive and forgot one setting in PLEX and lost my whole config last night. Thankfully I slept on it and remembered, "hey, I have a backup." This app just saved me a few hours and it has saved me a few hours a few other times too Thank you, craigr

Well, you may want to go back to this old tried and true technique. I just upgraded to v6.9.0-BETA35 and didn't change a thing and UHD hardware transcoding is still working for me. I didn't try the new way, just stuck with this older technique. I have hardware transcoding and tone mapping enabled and it is working on UHD transcodes down to 1080p (didn't try anything else). I didn't change a single thing, it just kept working. The addresses for my mouse using evdev changed so my Win10 VM wouldn't start until I fixed that. Other than that so far uneventful. Now to get to what I wanted to do with beta 35, multiple cache pools craigr