JasonM

This was my output: # dig @127.0.0.1 google.com ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Debian <<>> @127.0.0.1 google.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33845 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: ffc3245ab568ee35 (echoed) ;; QUESTION SECTION: ;google.com. IN A ;; Query time: 1151 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Sep 08 06:31:18 CDT 2020 ;; MSG SIZE rcvd: 51 # I also verified that equinox.io resolves in a browser. Appears to be something with the Docker network. You've given me something to work with. Thanks again!

Thanks for the containers. I'm hoping you can point me in the right direction. I've been using regular Pi-hole for a very long time. I have a br0 custom network and all containers have their own IP. Of course, unRAID points itself at an external DNS. As far as I can tell, I have everything set up correctly, However, when I try to use either the DoH container or the Pi-hole/DoH container, I cannot get DNS resolution. Here's the log from the standalone DoH container. This is all it does after the container starts. [36mINFO[0m[2020-09-07T12:29:43-05:00] Version 2020.8.2 [36mINFO[0m[2020-09-07T12:29:43-05:00] GOOS: linux, GOVersion: go1.14.7, GoArch: amd64 [36mINFO[0m[2020-09-07T12:29:43-05:00] Environment variables map[config:/etc/cloudflared/config.yml proxy-dns:true proxy-dns address:0.0.0.0 proxy-dns-port:53 proxy-dns-upstream:https://1.1.1.1/dns-query, https://1.0.0.1/dns-query] [36mINFO[0m[2020-09-07T12:29:43-05:00] Adding DNS upstream - url: https://1.1.1.1/dns-query [36mINFO[0m[2020-09-07T12:29:43-05:00] Adding DNS upstream - url: https://1.0.0.1/dns-query [36mINFO[0m[2020-09-07T12:29:43-05:00] Starting DNS over HTTPS proxy server on: dns://0.0.0.0:53 [36mINFO[0m[2020-09-07T12:29:43-05:00] Starting metrics server on 127.0.0.1:45489/metrics [36mINFO[0m[2020-09-07T12:29:43-05:00] Autoupdate frequency is set to 24h0m0s [31mERROR[0m[2020-09-07T12:29:53-05:00] update check failed: Post "https://update.equinox.io/check": dial tcp: lookup update.equinox.io on 127.0.0.11:53: read udp 127.0.0.1:35256->127.0.0.11:53: i/o timeout Any ideas as to what I'm doing wrong? Thanks!

I have been experiencing very questionable stability for several months now, and have just not had the time to create a post and gather appropriate logs. I suspect I may have a hardware issue, but troubleshooting and diagnosing this is beyond my skill level. I have attached my most recent diags from today's hard reboot, so there's not much. I also created a script that tails the syslog onto the flash drive to try and preserve information on whatever is going on. The attached syslog starts at the last array start yesterday at 13:02 and ends when the system crashed the same day at 23:15. This happens almost daily, and sometimes multiple times daily. Suddenly and without warning, containers will all stop responding, the UI may or may not respond remotely, and 2-3 random processor cores will be stuck at 100%. When the UI does respond and I try to stop the array or soft reboot, it's locks up. If I try to access the UI via console, I can enter user/pass, but Firefox will not launch. I am required to do a hard reboot every time. I occasionally will see an MCE error reported by Fix Common Problems, but I don't get that error every time. Any advice is greatly appreciated. Thanks! syslog-2020-02-10_1302 unraid-diagnostics-20200211-0856.zip

Not exactly. What you're doing is redundant. Once the NVIDIA build is released, you just need to follow step 2. Step 1 is only necessary if you want to go to vanilla 6.8.1 while you wait for the NVIDIA build to be ready.

Interesting. Every setup is a little different and there may be some variations in processor and motherboard capability. AFAIK, there isn't a specific disadvantage to using stub. If it works and you're getting the game performance you want, then I'd say you're all set. Until the next problem, of course. Living that homelab life.

Using stub employs a generic driver. Since you have the required virtualization hardware, vfio will use the dedicated driver. And it's reversed for that one. You'd use "vfio-pci.ids" in place of the other. Also, make sure you're stubbing all the functions of the card. You're showing two, but the card may or may not have more. The two you have are likely the graphics and sound controllers integral to the card. My card also has USB and serial controllers that I have to stub and pass to the VM for it to start properly. This may not be an issue for your card, but it's something to look for.

See this thread: You’ll need to modify your Syslinux file to isolate the card. Use vfio instead of stub.

I have a similar setup. I never encountered this issue, but I’ve always had the gaming GPU stubbed and passed to the VM. If you stub the card, the NVIDIA plugin won’t see it at all, thus eliminating any possibility of it using the wrong card. I suggest trying that if you don’t need the 1070 outside VM usage.

Not sure if this is technical enough, but it does have the full HTML login screen which does not exist in <6.8. Kernel version I have is 5.3.6.

Thanks. Did that twice already, but I'll give it another shot. The issue may actually be specific to 802.3ad bonding. I tried to bond the two 10g ports and got the same result I was getting with the bonded 1g ports. I'm going to discontinue using 802.3ad for the time being.

I did tray all 4 ports with the same result. The 10g ports (which are onboard) work fine. I was hesitant to post diags since there was a *possibility* it was related to the know issue, and I didn't want anyone to waste time digging through them. Y'all have more important things to do. I'm up and running on a 10g port. Like I said, the only reason I raised the bug report was because the quad card's ports were detected, reported as cable connected, full duplex, etc. So it didn't seem to be a "no driver" issue. At this point, it appears it is indeed related. In case it helps in the dev effort, I'm posting diags here, but please be assured I'm not expecting any specific help or troubleshooting. unraid-diagnostics-20191013-1701.zip

I did see that; however, I did not immediately assume it was related since the NIC is detected by unRAID. With no driver at all, I’d think the card would not be seen at all. In my case, it’s there, seems to be working normally, but doesn’t get an IP. I do have 10g ports also, but haven’t had a chance to try them.

Unfortunately, there is no fix for this. The 750 has a Marvell controller which has known and irreconcilable issues with the kernel. It's time to start looking at new controllers. I have two 750s collecting dust in my office which I can't even give away. The LSI 9207-8i or 9207-16i can be had on eBay for very reasonable prices, and you can get them pre-flashed into IT mode, so they'll work OOB.

When running nvidia-smi dmon, I can see both enc and dec activity. Interestingly, it seems something with Tautulli isn't caught up yet. Tautulli still shows "hw" for encoding only, not decoding. Is anyone seeing "hw" for both with this new version of Plex and 6.7.2?

Is it your observation from the logs that Mover is the problem? I changed it to monthly and will see how things look in the morning.

Yes, I do have cache drives, but I only use cache-only shares. There is nothing for mover to move. I wish there were a way to disable mover completely, but there is no readily apparent way to do so. Mover is set for 1AM. I have scheduled tasks spread out enough such that they should not conflict with each other: 1AM Mover 2AM Auto update plugins 3AM Auto update containers 4AM CA backup 5AM SSD TRIM

I've been trying to isolate this issue for a while. It has survived hardware changes and complete USB rebuild. At some point overnight, the system becomes unresponsive. Dockers and VMs cease to operate. The web UI is sometimes available, and when it is, shows 2-3 CPUs pegged at 100%. Interacting with the web UI in this state works for a few navigation clicks before completely locking up. On other mornings, the web UI won't load at all. In all cases, a hard reboot is required. The server runs all day without issues. In an attempt to get more data, I installed a user script that tails the syslog onto the flash drive since I'm not able to get a log at time of crash. Regular diags as well as this log are attached. Around line 460, the system seems to enter an endless loop. On one occasion, I noticed a strange message about CA Backup in my browser status bar, of which I took a screen shot. All three files are attached. Any help nailing down this issue is greatly appreciated. unraid-diagnostics-20190911-1207.zip syslog-2019-09-09_0637.txt

Thanks for the shout out. Helping each other is what this community is all about. Also, I see above that you're passing your keyboard and mouse from the host to the VM. Since you're handing off the USB controller from your GPU, you can connect a USB hub to that USB-C port on the back of the GPU, and then plug the input devices into that. This way, you don't have to pass them through at all, and you also get true USB Plug-and-play support in windows. You can connect flash drives and the like without unRAID even knowing they're there. I do this with a dedicated PCI USB card, but it works with that port on the back of the GPU just as well.

I had this issue also. The workaround (although it's not really a "workaround" as much as it is just doing it a little differently) is to, instead of stubbing the NVIDIA USB and serial controllers, add them as two hostdev blocks to the VM XML for the two devices. This will have the same result with the two devices appearing in the GUI so you can check them to pass to the VM, but they will be returned to the host when the VM shuts down. This way, all four NVIDIA devices in the IOMMU group go to the VM together and are released together. Spaceinvader One has a good video with copy/paste XML on doing this with an NVMe drive, but the same principle applies here as well.

Regrettably, this did not correct the problem. At least not for me. I'm going to leave it stubbed since that makes sense anyway, but I'm still chasing random crashes. It seems to happen over night, so I suspect it is a scheduled task that's making things freak out. I'll post diags to the main forum and see what we get.

I am not currently, but I'll try that tonight. If I wake up in the morning to a functioning unRAID UI, that may be the fix.

Yes, very similar issues. I have an RTX 2080 passed to a Windows VM and a P2000 for transcodes. Even with hardware acceleration disabled and the NVIDIA variables removed from the Plex docker, I'm getting random crashes that require a hard reboot. Haven't had much time to troubleshoot, but I was planning to start by reverting to vanilla unRAID to see if that was the issue. I'll continue following your progress and will report updates as well. Thanks!

Not any more, because of this. I had a Plex meltdown last week that caused filesystem corruption. The server would lock up and require a hard reboot within minutes of starting the Plex docker. After several repeats of this, I started in maintenance, ran check and repair, nuked docker image and reinstalled everything minus the decode patch, and it's been fine. TL;DR: +1 for this being a Plex issue.

Now y'all have me thinking... This may be the solution to the artifact issue I posted about a while back. The P4000 is Pascal based. I need more than 2 transcodes at a time, so it's gotta be a Quadro. It looks like I could flip my current card and cover about 75% of the new one. If it fixes the issue, that's worth it. Is there anyone out there using an RTX 4000?