bungee91

Post your full diagnostics if you can to help us figure out the cause. A long Memtest would be my next obvious things to check. Also trying to capture the syslog when this occurs, I believe the fix common problems plugin has the option to capture log files regularly, which can help with troubleshooting since this is all deleted when you reboot (sits in RAM).

The rebooting is a weird occurence after a freeze, how's your power supply?

Care to explain this better? Black screen, or just gets to a boot loader screen and sits there?

While I don't understand why that tool isn't working, here's the manual method you can do http://lime-technology.com/wiki/index.php/UnRAID_Manual_6#Enable_MSI_for_Interrupts_to_Fix_HDMI_Audio_Support

So you ran the utility as administrator and selected your GPU and associated HDMI audio, hit apply, save, and rebooted the VM and it didn't take?..

No problem. If it ends up being more related to latency, I'd recommend following the suggestions in this sticky https://lime-technology.com/forum/index.php?topic=49051.0

If it's your analog sound, they say upping the frequency range in Windows can help, it's somewhere in sound playback settings. Also, I'd make sure the MSI fix is present, if not you can get strange audio issues. If you search for it, you'll find an explanation as to what it does, why you want to enable it. A utility to set it to on is in my post here https://lime-technology.com/forum/index.php?topic=46264.msg442915#msg442915

Given your hardware, there should be NO reason to need this enabled, if anything it could cause issues. The ACS override is for systems without ACS on root ports, which your 5820k has natively within the CPU.

Nice! Details here https://lime-technology.com/forum/index.php?topic=51154.msg491892#msg491892

Looking quickly from my phone, one thing I noticed or wanted to question: Are you only passing the GPU and not it's associated HDMI audio to the VM? If so, please assign the audio portion also, as this has been known to cause issues when only assigning one of them. Next thing I'd recommend is passing the rom for the card, as my AMD card requires this when using OVMF, however not needed for SeaBios.

Has to be done in the Edit XML option, instructions here http://lime-technology.com/wiki/index.php/UnRAID_6/VM_Management#Edit_XML_for_VM_to_supply_GPU_ROM_manually More info and how to extract it yourself in this thread https://lime-technology.com/forum/index.php?topic=43644.0.

Can you also provide your VM XML? You can attempt to pass the GPU rom to the VM, this can sort out a variety of issues with troublesome cards, especially AMD ones. However, doing this in the XML and then editing it through the VM Edit function will remove this entry, so keep that in mind in case you make changes. Have you confirmed this condition is gone if you unassign the GPU and switch to VNC just for testing purposes? I'm surprised this issue was not present in 6.1.9, however there have obviously been a lot of changes to the kernel, QEMU, etc... Are you using a different driver version than you were previously in 6.1.9?

Glad you figured it out! The only other thing that can help is passing the rom of the card to the VM. This can solve a variety of issues for difficult cards. As for the MSI fix, there is also a utility that makes this 100 times easier in Windows, linked here in my post https://lime-technology.com/forum/index.php?topic=46264.msg442915#msg442915 I have noticed that updates to the Nvidia Windows driver will revert the MSI setting, so this utility makes it stupid easy to fix that, just make sure to run as administrator.

Likely related to a device you're passing through to the VM, most likely a GPU. Does this happen when you remove the GPU from the XML of the VM and start/stop the VM using VNC as the display adapter? This is also not likely specific to RC3, so I'd recommend starting a thread in general support so others can help to troubleshoot the issue, and get more details as needed.

Try with OVMF and the issue may be removed. Some cards prefer this, and OVMF/UEFI allows for device initialization after POST where SeaBios does not. This will unfortunately involve reinstalling Windows. Also, you may want to make sure that the MSI fix has been applied. Search the forum for this, all my Nvidia cards require this (this is not directly your issue, but it can lead to "demonic" audio if not set correctly).

You can enable the "Enable PCIe ACS Override" option under the Settings - VM Settings page (advanced view) and reboot. This should put the GPU within its own IOMMU group, allowing you to assign only this device. Please read about the possibilities for "Warning: Use of this setting could cause possible data corruption with certain hardware configurations. Please visit the Lime Technology forums for more information.". See if that fixes your issues.

Less talky, more work on adding the system log option.. Seriously, liking the updates, thanks for the continued development!

Well my recollection will not be the best since I was dealing with the various issues related to "my server clearly hates me in XXX ways" (you joined one of those threads, it was clearly a great time!) . That issue is now fixed, and I'm in good shape (memory, also don't believe Memtest exclusively, 6 successful passes and I still had my issue). In testing I rolled back to 6.1.9, which in turn lead to not having any Docker containers listed, or (I believe) the Docker.img usable. So delete image, create new, all is well. My issue that I was testing for (not related to this; was memory related) persisted, so I went back to 6.2RC3, updated my containers (since this is needed), and here I am. So the current Docker.img was created in 6.1.9, so if that is the likely culprit, my hands are red. Will only take ~5 minutes to start new, but the other 1/2 is watching Tv (through this very Docker), so it'll have to wait. Thanks for the help!

Nothing you can do but this: http://lime-technology.com/forum/index.php?topic=40937.msg481138#msg481138 Hmmm, ok, if that's what needs to happen. I'm surprised since my image is less than a week old, and I haven't installed much onto it. However, will do just that soon.

Is there any chance of adding VM backup natively into CA's backup function? I think this would be the most streamlined way while we await (at some point) getting snapshot's added into the VM manager. Waiting to hear from danioj on that one. I don't run VM's so need to get together with him to sort that all out. Good deal, thanks for the update and continued development. It's 5 o'clock somewhere, I tossed a "beer" your way!

Trying to install unstable through CA, and keep getting "Error: layers from manifest don't match image configuration" Pic attached.

Is there any chance of adding VM backup natively into CA's backup function? I think this would be the most streamlined way while we await (at some point) getting snapshot's added into the VM manager.

Also, there are two Kodi plugin's for the HDHR one is a PVR plugin that is unofficial, the other is a video plugin released by SiliconDust that is officially supported. I use TvHeadend as suggested above, and it works very well.

Well, you're right.... (it's not personal) There is still something wrong with my setup, AND it's likely hardware related.. Seen this with the 6.1.9 installation and I know for a fact I never had these issues prior to the MB and GPU that died and needed to be replaced. Server kernel: WARNING: CPU: 11 PID: 24446 at arch/x86/kernel/cpu/perf_event_intel_ds.c:315 reserve_ds_buffers+0x10e/0x347() Aug 9 02:00:23 Server kernel: alloc_bts_buffer: BTS buffer allocation failure Aug 9 02:00:23 Server kernel: Modules linked in: kvm_intel kvm vhost_net vhost macvtap macvlan md_mod xt_nat veth xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables tun ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat hwmon_vid igb i2c_algo_bit ahci ptp sata_mv i2c_i801 libahci pps_core ipmi_si [last unloaded: md_mod] Aug 9 02:00:23 Server kernel: CPU: 11 PID: 24446 Comm: qemu:Main Not tainted 4.1.18-unRAID #1 I attached that syslog, but it looks the same as the others. I also seen this towards the bottom, and I know I have seen it before, and it may be harmless but I thought I'd mention it: kernel: perf interrupt took too long (2563 > 2500), lowering kernel.perf_event_max_sample_rate to 50000 All photos of my BIOS setup screens are here https://photos.google.com/share/AF1QipNcs6rSDd3rAgkKe9LpxOV5cUn3gt1zkZkjJqQK93oiUmbsW6LCHZTsGMcnZHqqeg?key=MzdVOXI3aXUtVkVwTTlMa1ZqSjB5Q2lFN1RsU0R3 they're legible, but phone pics while holding a keyboard and mouse (this BIOS cannot be navigated solely with just a keyboard, stupid!). So, I now continue down this path. I know I have seen the tainted message on more CPU's than the one assigned to only my primary VM, but recently it has only been that one in particular (4,5,10,11). Knowing this I removed the RMA'd 260X from the server, and have that VM as VNC for now. I will likely switch it over to a spare GT720 I have in there at some point, for tonight I don't think I care. Look forward to any specifics you may see in the BIOS screens, but again, I never had these issues initially before that MB died, and while I thought it was tied to it initially, the more I tried other things the less likely it appeared to be a hardware related case. Prior to the MB dieing, it took out my initial 260X GPU, prompting RMA, then a week later the MB died. I wouldn't think this type of failure is good for any component that was on the MB, so all GT720's I have, and even the RAM (even though it won't fail Memtest) is suspect. I have one odd thing with Memtest newest version (Passmark), if I run it in multiple CPU mode it will freeze up pretty quickly. While I know this can be an issue with the included older Memtest distributed with UnRAID, I didn't expect this to be the case with the newest Passmark version. If this is any indication of anything, well, I've now shared that experience. Looking forward to your input, back on 6.2RC3 with my replacement AMD card removed just in case. If there was something odd with it (or any of the GPU's installed) since their lanes go directly to the CPU, I could see this causing issues however uncertain of that extent. I fully understand in troubleshooting removing all but required components is key, and if that means loosing the other GPU's as I test, so be it. Just sucks with so much reliance on one box, that and I was in denial to a point. Thanks, Jeff Edit:If you care to read about my initial misery (sickens me to know I've been fighting this on/off for 5 months now), the thread with details is here https://lime-technology.com/forum/index.php?topic=48024.msg460209#msg460209 it has some back story that may be helpful, but mainly just failure.. server-syslog-20160809-1846.zip

Called in the big guns huh?! Let me take a look once I get home this evening, the only difference between this and my previous board was that above 4g decoding had to be disabled on the Gigabyte board or it reverted to BIOS default settings (no idea why), so it was always set to off. On the SuperMicro I have now I was able to enable it (even though supposedly only useful for Grid or fancy CUDA cards or something of that nature), and pass all related Memtest's with it on, so I left it that way. Will have all the information you can shake a stick at this evening.