Koenig

Now I'm able to login. So that looks OK, but I still cannot create a diagnostics... Though that might be anothr matter.

root@Unraid:~# /etc/rc.d/rc.unraid-api install API has been running for 1s and is in "production" mode! -----UNRAID-API-REPORT-----> SERVER_NAME: Unraid ENVIRONMENT: production UNRAID_VERSION: 6.10.3 UNRAID_API_VERSION: 2.49.2 (running) NODE_VERSION: v14.15.3 API_KEY: invalid MY_SERVERS: signed out CLOUD: API key is missing RELAY: disconnected MINI-GRAPH: disconnected ONLINE_SERVERS: Unraid OFFLINE_SERVERS: HAS_CRASH_LOGS: no </----UNRAID-API-REPORT----->

root@Unraid:~# ls -al /usr/local/sbin/unraid-api lrwxrwxrwx 1 root root 36 Jul 27 18:31 /usr/local/sbin/unraid-api -> /usr/local/bin/unraid-api/unraid-api root@Unraid:~# ls -al /usr/local/bin/unraid-api/ /bin/ls: cannot access '/usr/local/bin/unraid-api/': No such file or directory

Well it says the same for me, but if you check the logs I attached you can see that the installation was completed.

root@Unraid:~# unraid-api report -v bash: unraid-api: command not found root@Unraid:~# php /usr/local/emhttp/plugins/dynamix/include/UpdateDNS.php -v (Output is anonymized, use '-vv' to see full details) Unraid OS 6.10.3 with My Servers plugin version 2022.07.26.1609 ⚠️ Not signed in to Unraid.net Use SSL is auto ✅ Rebind protection is disabled for myunraid.net Response (HTTP 406): null Error: Nothing to do And I can't sign in to unraid.net, it just never gets to any login page....

Hope this helps. EDIT: The image is taken after uninstall/reinstall. Install log.txt Uninstall log.txt

Same for me. + I can't create a diagnostics to attach to this post, it just says "Downloading" but nothing happens and this file - "/logs/unraid-diagnostics-20220727-1817.zip" does not exist on the flash.

No, when you put it like that it seems I'm wrong. I was looking at wich cards where supported in the latest driver (as it is a rather new feature) and the 760 was missing out, so I assumed it was an older GPU, but my assumption was wrong. however there's also this: https://www.tomshardware.com/news/nvidia-end-support-kepler-gpu-windows7-windows-8-august-31 and the article about VM-support is dated 29-09-2021. Grey area perhaps?

This release solved an issue for me that I thought was an hardware/BIOS error, when passing one of my Nvidia cards to windows VM the VM after a while lost connection to the monitor/s + the VM sort of got unresponsive and I had to force-close it. (The "sort of" because if the VM was set to do some videoencoding it still finished the encoding if I just let it be, even hours after it became unresponsive, this I determined by seeing that the resulting file was still growing after the machine went unresponsive) But passing it through to a linux-machine worked just fine. This issue must have happened when 6.10 went from beta to RC because I've had the issue for a long time, long before RC2, but it worked initially, I think my first install on this machine was a beta due to it beeing a ryzen 3970X-system.

Your card is not supported for passthrough in the Nvidia drivers, it is only Kepler or newer that are supported: https://nvidia.custhelp.com/app/answers/detail/a_id/5173/~/geforce-gpu-passthrough-for-windows-virtual-machine-(beta) So I think you are bound to test all the old workarounds/hacks to get it to work.

Sounds like it could be a case of error code 43 for the display adapter, check the device manager for that. Make sure you have the latest drivers for your Nvidia card, the older drivers does not permit to use a Nvidia card in a VM.

As an update to this thread: I ran a memtest, only one pass, and it was OK. So I went ahead and updated the BIOS again, and right now I am at 15 days uptime, which is a record, lets hope I didn't jinx it with this post At the same time as I updated the BIOS I also changed a setting that disabled the system from booting from one of the disks attached to my HBA-card (this also cut boot-times as the HBA card does not do it's own boot-thing any more) So I'm not sure wich of this actually was causing my issues, but hopefully this issue is solved now.

But it didn't, and yes when i changed the setting to what was recommended in that post you linked to, I had the latest BIOS (I updated just prior to changeing that setting), although now there's a newer BIOS. But I realized today that disabling the C-states is not really an option, the power consumption of the server vent up like a 100W when I disabled the C-states, I think from the attached image you can determine the time pretty accurate as to when I reboot with the C-states disabled. I took a photo of the screen at one of the crashes as well if that could of any help I'll atttach that as well.

Sorry for not remembering the name of the setting right, but that is exactly the setting I meant when I wrote "powerline"-setting, so I have already tried that and it did not solve the problem, I changed that setting a couple of months ago and I still have had the system go unresponsive to the point where I have to make hard reset, with a maximum uptime of 14 days. + That was the exact post I was reffering to in my previous post. The lockups are the root of my problem, but now that I have disabled global C-states (to try if that helps with the lockups) my Windows VM's performance i so slow it is unbearable so any help in understanding why that is and if there's anything to do about it would be much appreciated.

Hi! I have a Ryzen 3970X on a Gigabyte TRX40 Aorus Xtreme with 128GB Samsung ECC. I have problems with random "crashes" where the system becomes totally unresponsive and i cannot find anything in the logs (I have a separate sys-log server). When I bulit the system some 18months ago I did run a 48hr memtest without no errors, the system has been unstable ever since the build. The "crashes" are very intermittent, but always happen within 14 days after a system restart (can be 1 day, can be 13). I found some post here on the forum saying some Ryzens have som bug that can cause craches, and in these cases a powerline setting can fix the problem and sometimes one have to disable the global C-states. So I tried the powerline setting for a while but it did not help, so today I decided to test to disable the global C-states, but that had a very negative effect on my Windows VM's, they got really bad performance wise, and each machine takes about a 100% of a thread in the system constantly and the machines themselves are very "laggy". Does anybody know if there is a way to fix this?

I have this issue as well. I have two monitors attached to a Nvidia 2070 Super. The VM becomes unresponsive when this happens, it is a Windows VM and i have tried to used remote desktop when it happens but it doesn't seem to connect (says configuring session or something like that the whole time until I aborts it), also a noraml shutdown doesn't work but a forced one does.

For a long time WINS-server has worked for me by adding "wins support = yes" in the "SMB Extras" section, but after I upgraded from 6.8.3 to 6.9.2 I keep getting this in my log: May 26 08:31:54 NAS nmbd[15831]: process_name_registration_request: unicast name registration request received for name SAMSUNG_6260ND<20> from IP 192.168.8.65 on subnet UNICAST_SUBNET. Error - should be sent to WINS server May 26 08:33:27 NAS nmbd[15831]: [2021/05/26 08:33:27.527778, 0] ../../source3/nmbd/nmbd_incomingrequests.c:170(process_name_refresh_request) May 26 08:33:27 NAS nmbd[15831]: process_name_refresh_request: unicast name registration request received for name DAILY-DRIVER<20> from IP 192.168.8.205 on subnet UNICAST_SUBNET. May 26 08:33:27 NAS nmbd[15831]: [2021/05/26 08:33:27.527875, 0] ../../source3/nmbd/nmbd_incomingrequests.c:173(process_name_refresh_request) May 26 08:33:27 NAS nmbd[15831]: Error - should be sent to WINS server May 26 08:33:32 NAS nmbd[15831]: [2021/05/26 08:33:32.051536, 0] ../../source3/nmbd/nmbd_incomingrequests.c:170(process_name_refresh_request) May 26 08:33:32 NAS nmbd[15831]: process_name_refresh_request: unicast name registration request received for name DAILY-DRIVER<00> from IP 192.168.8.205 on subnet UNICAST_SUBNET. May 26 08:33:32 NAS nmbd[15831]: [2021/05/26 08:33:32.051696, 0] ../../source3/nmbd/nmbd_incomingrequests.c:173(process_name_refresh_request) May 26 08:33:32 NAS nmbd[15831]: Error - should be sent to WINS server May 26 08:33:36 NAS nmbd[15831]: [2021/05/26 08:33:36.571248, 0] ../../source3/nmbd/nmbd_incomingrequests.c:170(process_name_refresh_request) May 26 08:33:36 NAS nmbd[15831]: process_name_refresh_request: unicast name registration request received for name TOK<00> from IP 192.168.8.205 on subnet UNICAST_SUBNET. May 26 08:33:36 NAS nmbd[15831]: [2021/05/26 08:33:36.571325, 0] ../../source3/nmbd/nmbd_incomingrequests.c:173(process_name_refresh_request) May 26 08:33:36 NAS nmbd[15831]: Error - should be sent to WINS server May 26 08:33:51 NAS nmbd[15831]: [2021/05/26 08:33:51.694575, 0] ../../source3/nmbd/nmbd_incomingrequests.c:211(process_name_registration_request) May 26 08:33:51 NAS nmbd[15831]: process_name_registration_request: unicast name registration request received for name SAMSUNG_6260ND<00> from IP 192.168.8.65 on subnet UNICAST_SUBNET. Error - should be sent to WINS server Anyone know if the support for WINS has been removed or if something else has changed that break this? (I use WINS only to get name resolution when connecting to my network via VPN, so if there's another way to get that working I would be thankful for some tips on how to do that.)

Moved to General support.

Thank you, changing the CPU-governor to "on demand" seems to bring the CPU-levels back to where they were before the upgrade. However that also seems to increase the power-draw a bit, not unexpected and I can't really say if it is more now than before the upgrade (should be, atleast some as it was on power save before but not stuck at the lowest p-state). Again - Thank you for the tip!

Hi! I upgraded to 6.9.2 from 6.8.3 on one of my servers and I thought everything went just fine, but now a couple of days in I see that the CPU-usage on my 6-core Intel 4930K has gone from ~6% to ~20% when "idle" or maybe it should expressed as a "normal" state. This with 2 VM's (hassio and unifi) and 3 dockers running, same things both before and after the upgrade. I can't wrap my head around what is using the CPU so much, "top" and "htop" gives different answers + I'm not that familiar with linux. So maybe someone could be kind enough to check my attached diagnostics and help me figure out what is going on? nas-diagnostics-20210415-0744.zip

On one of my servers I do, but on the other it is gone....

I have a Gigabyte Aorus Xtreme also with dual audio (at least one of them ALC1220), and to me they show up as USB-devices, see attached image.

As I understand it you want to passthrough the NVME and use it as primary disk for the VM, then you should set the option "Primary vDisk Location:" to "none" instead.

I can confirm this behaviour, powered off I have "host-model" for CPU (own edit to get win 10 to work with ryzen 3), but if I look at the xml with the machine powered on I can see the same "features" as the OP, but this is all reverted back when machine is powered off again. And indows reports it as "EPYC", same as OP.

I do have a Gibyte Aorus Xtreme with dual 10Gbe NIC so I might just test this suggestion, thank you, I had some other plans for the second NIC but that comes further into the future and perhaps this issue is ironed out until then.