Koenig

Members
  • Posts

    34
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Koenig's Achievements

Newbie

Newbie (1/14)

3

Reputation

  1. 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.
  2. 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.)
  3. 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!
  4. 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
  5. On one of my servers I do, but on the other it is gone....
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. Well, I only have the one docker with static IP....
  11. I just answered in another thread about the "unexpected GSO type" where someone claimed that using Q35-5.0 would solve the issue, Ill just paste that post here: "I just tried yesterday with 2 newly created VM Q35-5.0 machines (Windows 10), on Beta25 and I still get the "unexpected GSO type" flooded in my logs when i use "virto" so I don't see how using Q35-5.0 would be a solution. Only way I get rid of that in the logs for me is to use "vitio-net" with the severely diminished performance. Edit: Just tried again and still same results, attaching my diagnostics if you wish to see for yor self." unraid-diagnostics-20200821-0848.zip
  12. Not that this is really the thread to adress this but anyway: I just tried yesterday with 2 newly created VM Q35-5.0 machines (Windows 10), on Beta25 and I still get the "unexpected GSO type" flooded in my logs when i use "virto" so I don't see how using Q35-5.0 would be a solution. Only way I get rid of that in the logs for me is to use "vitio-net" with the severely diminished performance. Edit: Just tried again and still same results, attaching my diagnostics if you wish to see for yor self. unraid-diagnostics-20200821-0848.zip
  13. There is a thread about a custom kernel for this issue in another subforum: https://forums.unraid.net/forum/15-motherboards-and-cpus/ I also have faint memory about reading that this is something that is fixed in more recent kernels, and will probably be included in next release.
  14. In trying to find the best way to get past the Ryzen 3000 bug with Win10 giving "KERNEL_SECURITY_CHECK_FAILURE" I found this post: https://forum.level1techs.com/t/amd-fix-for-host-passthrough-on-qemu-5-0-0-kernel-5-6/157710 I have posted about this before in the beta22-thread and how I solved with changeing host-passthrough to host-model. But it seems that the solution given in the linked post is a more "accurate" one so I tried that as well and it works and it doesn't break my Nvidia-GPU passthrough either, but at each reboot my changes to "/usr/share/libvirt/cpu_map/x86_features.xml" reverts to the original state thus breaking my VM's again. So how can I make the changes I made to that file become permanent?