bungee91

Members
  • Posts

    744
  • Joined

  • Last visited

Posts posted by bungee91

  1. I'm afraid I don't know how to interpret them either but I see "kvm" crop up time and time again. Someone like RobJ might be able to help if he reads your post. I'm afraid I have nothing else to offer, other than to repeat what I would do. You need to simplify the problem and the virtualisation part is a major complication.

     

    I get it, and thanks for looking!

    I have already had some help from RobJ in the B23 thread, and nothing was conclusive, he believes that it is a bug in the low level memory mangement.

    I posted on the VFIO forum with that kind of title, and no one found it interesting enough, or had an idea either.

    I will do some more shuffling soon, will try OVMF instead on a VM or two.

    I'm nearly certain if I remove VM's, or even remove the use of VT-d (meaning have nothing assigned) this issue will "fix" itself.

    However, that only tells me it is something related to memory management within IOMMU or shadow pages and then I'm still at a loss....  Lame!

     

  2. I didn't go through your diagnostics or follow the links you gave but, given that your memory passes the MemTest, I would strip everything back to the basic unRAID NAS functions - i.e. no VMs and no Dockers. If that proved to be stable I'd reinstate the Dockers and check again, then the VMs, one at a time.

     

    Yeah, trying to avoid this, but understand the troubleshooting reasons for the suggestion.

    You would think that these traces and events in the syslog would mean something useful to someone other than me, but I have yet to find that person, or that information through my searches.

    The thing is, I think the messages WILL go away without any VM's running, as the "tainted" is always in line with VM's attached to CPU cores. So if I see the line for CPU 3, I also see the thread pair I pass as well in a message a little later (which would be CPU 9 in this case).

    Hmmm, so at that point we're thinking VM specific issues, which could be the case..

    Maybe I'll switch one or two of them (would be nice if I could just "switch" them... ;) ) from SeaBIOS to OVMF/UEFI and see if it helps.

  3. So..... This is starting to drive me batshit crazy, so any input from whomever is really appreciated.

    If I cannot get to the bottom of it, I'm saying F*** it, and buying a different motherboard (original one died, this one is a replacement, also screw Gigabyte lately they use to be so much more awesome than my experience with recent releases).

     

    I have these kinds of errors within my syslog

    Jul 27 15:56:46 Server kernel: WARNING: CPU: 11 PID: 16664 at arch/x86/kernel/cpu/perf_event_intel_ds.c:334 reserve_ds_buffers+0x110/0x33d()
    Jul 27 15:56:46 Server kernel: alloc_bts_buffer: BTS buffer allocation failure
    Jul 27 15:56:46 Server kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables vhost_net tun vhost macvtap macvlan xt_nat veth ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat md_mod it87 hwmon_vid mxm_wmi x86_pkg_temp_thermal coretemp kvm_intel kvm e1000e i2c_i801 ahci ptp pps_core libahci wmi
    Jul 27 15:56:46 Server kernel: CPU: 11 PID: 16664 Comm: qemu-system-x86 Not tainted 4.4.15-unRAID #1
    Jul 27 15:56:46 Server kernel: Hardware name: Gigabyte Technology Co., Ltd. Default string/X99-SLI-CF, BIOS F22 06/13/2016
    Jul 27 15:56:46 Server kernel: 0000000000000000 ffff880580de7920 ffffffff81369dfe ffff880580de7968
    Jul 27 15:56:46 Server kernel: 000000000000014e ffff880580de7958 ffffffff8104a31d ffffffff81020923
    Jul 27 15:56:46 Server kernel: 0000000000000000 0000000000000001 0000000000000009 ffff880125248700
    Jul 27 15:56:46 Server kernel: Call Trace:
    Jul 27 15:56:46 Server kernel: [<ffffffff81369dfe>] dump_stack+0x61/0x7e
    Jul 27 15:56:46 Server kernel: [<ffffffff8104a31d>] warn_slowpath_common+0x8f/0xa8
    Jul 27 15:56:46 Server kernel: [<ffffffff81020923>] ? reserve_ds_buffers+0x110/0x33d
    Jul 27 15:56:46 Server kernel: [<ffffffff8104a379>] warn_slowpath_fmt+0x43/0x4b
    Jul 27 15:56:46 Server kernel: [<ffffffff810f6bc3>] ? __kmalloc_node+0x22/0x153
    Jul 27 15:56:46 Server kernel: [<ffffffff81020923>] reserve_ds_buffers+0x110/0x33d
    Jul 27 15:56:46 Server kernel: [<ffffffff8101b3e0>] x86_reserve_hardware+0x135/0x147
    Jul 27 15:56:46 Server kernel: [<ffffffff8101b442>] x86_pmu_event_init+0x50/0x1c9
    Jul 27 15:56:46 Server kernel: [<ffffffff810ae054>] perf_try_init_event+0x41/0x72
    Jul 27 15:56:46 Server kernel: [<ffffffff810ae4a5>] perf_event_alloc+0x420/0x66e
    Jul 27 15:56:46 Server kernel: [<ffffffffa0837596>] ? kvm_dev_ioctl_get_cpuid+0x1c0/0x1c0 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffff810b041b>] perf_event_create_kernel_counter+0x22/0x112
    Jul 27 15:56:46 Server kernel: [<ffffffffa08376e1>] pmc_reprogram_counter+0xbf/0x104 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0837933>] reprogram_fixed_counter+0xc7/0xd8 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0b4e941>] intel_pmu_set_msr+0xe0/0x2ca [kvm_intel]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0837b34>] kvm_pmu_set_msr+0x15/0x17 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0819a5a>] kvm_set_msr_common+0x921/0x983 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0b4e3ba>] vmx_set_msr+0x2ec/0x2fe [kvm_intel]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0816427>] kvm_set_msr+0x61/0x63 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0b479ba>] handle_wrmsr+0x3b/0x62 [kvm_intel]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0b4c5f9>] vmx_handle_exit+0xfbb/0x1053 [kvm_intel]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0b4e0bf>] ? vmx_vcpu_run+0x30e/0x31d [kvm_intel]
    Jul 27 15:56:46 Server kernel: [<ffffffffa081ff9c>] kvm_arch_vcpu_ioctl_run+0x38a/0x1080 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa081a93b>] ? kvm_arch_vcpu_load+0x6b/0x173 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa081a9b8>] ? kvm_arch_vcpu_load+0xe8/0x173 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa08120ec>] kvm_vcpu_ioctl+0x178/0x499 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa082e7d9>] ? em_rsm+0x14d/0x14d [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffff81117b8f>] do_vfs_ioctl+0x3a3/0x416
    Jul 27 15:56:46 Server kernel: [<ffffffff8111fba5>] ? __fget+0x72/0x7e
    Jul 27 15:56:46 Server kernel: [<ffffffff81117c40>] SyS_ioctl+0x3e/0x5c
    Jul 27 15:56:46 Server kernel: [<ffffffff81622f6e>] entry_SYSCALL_64_fastpath+0x12/0x6d
    Jul 27 15:56:46 Server kernel: ---[ end trace 8f5773cb964683c2 ]---
    Jul 27 15:56:46 Server kernel: qemu-system-x86: page allocation failure: order:4, mode:0x260c0c0
    Jul 27 15:56:46 Server kernel: CPU: 11 PID: 16664 Comm: qemu-system-x86 Tainted: G        W       4.4.15-unRAID #1
    Jul 27 15:56:46 Server kernel: Hardware name: Gigabyte Technology Co., Ltd. Default string/X99-SLI-CF, BIOS F22 06/13/2016
    Jul 27 15:56:46 Server kernel: 0000000000000000 ffff880580de7798 ffffffff81369dfe 0000000000000001
    Jul 27 15:56:46 Server kernel: 0000000000000004 ffff880580de7830 ffffffff810bcc1f 0260c0c000000010
    Jul 27 15:56:46 Server kernel: ffff880600000040 0000000400000040 0000000000000004 0000000000000004
    Jul 27 15:56:46 Server kernel: Call Trace:
    Jul 27 15:56:46 Server kernel: [<ffffffff81369dfe>] dump_stack+0x61/0x7e
    Jul 27 15:56:46 Server kernel: [<ffffffff810bcc1f>] warn_alloc_failed+0x10f/0x127
    Jul 27 15:56:46 Server kernel: [<ffffffff810bfc36>] __alloc_pages_nodemask+0x870/0x8ca
    Jul 27 15:56:46 Server kernel: [<ffffffff810bfe3a>] alloc_kmem_pages_node+0x4b/0xb3
    Jul 27 15:56:46 Server kernel: [<ffffffff810f4424>] kmalloc_large_node+0x24/0x52
    Jul 27 15:56:46 Server kernel: [<ffffffff810f6bc3>] __kmalloc_node+0x22/0x153
    Jul 27 15:56:46 Server kernel: [<ffffffff8102099f>] reserve_ds_buffers+0x18c/0x33d
    Jul 27 15:56:46 Server kernel: [<ffffffff8101b3e0>] x86_reserve_hardware+0x135/0x147
    Jul 27 15:56:46 Server kernel: [<ffffffff8101b442>] x86_pmu_event_init+0x50/0x1c9
    Jul 27 15:56:46 Server kernel: [<ffffffff810ae054>] perf_try_init_event+0x41/0x72
    Jul 27 15:56:46 Server kernel: [<ffffffff810ae4a5>] perf_event_alloc+0x420/0x66e
    Jul 27 15:56:46 Server kernel: [<ffffffffa0837596>] ? kvm_dev_ioctl_get_cpuid+0x1c0/0x1c0 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffff810b041b>] perf_event_create_kernel_counter+0x22/0x112
    Jul 27 15:56:46 Server kernel: [<ffffffffa08376e1>] pmc_reprogram_counter+0xbf/0x104 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0837933>] reprogram_fixed_counter+0xc7/0xd8 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0b4e941>] intel_pmu_set_msr+0xe0/0x2ca [kvm_intel]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0837b34>] kvm_pmu_set_msr+0x15/0x17 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0819a5a>] kvm_set_msr_common+0x921/0x983 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0b4e3ba>] vmx_set_msr+0x2ec/0x2fe [kvm_intel]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0816427>] kvm_set_msr+0x61/0x63 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0b479ba>] handle_wrmsr+0x3b/0x62 [kvm_intel]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0b4c5f9>] vmx_handle_exit+0xfbb/0x1053 [kvm_intel]
    Jul 27 15:56:46 Server kernel: [<ffffffffa0b4e0bf>] ? vmx_vcpu_run+0x30e/0x31d [kvm_intel]
    Jul 27 15:56:46 Server kernel: [<ffffffffa081ff9c>] kvm_arch_vcpu_ioctl_run+0x38a/0x1080 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa081a93b>] ? kvm_arch_vcpu_load+0x6b/0x173 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa081a9b8>] ? kvm_arch_vcpu_load+0xe8/0x173 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa08120ec>] kvm_vcpu_ioctl+0x178/0x499 [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffffa082e7d9>] ? em_rsm+0x14d/0x14d [kvm]
    Jul 27 15:56:46 Server kernel: [<ffffffff81117b8f>] do_vfs_ioctl+0x3a3/0x416
    Jul 27 15:56:46 Server kernel: [<ffffffff8111fba5>] ? __fget+0x72/0x7e
    Jul 27 15:56:46 Server kernel: [<ffffffff81117c40>] SyS_ioctl+0x3e/0x5c
    Jul 27 15:56:46 Server kernel: [<ffffffff81622f6e>] entry_SYSCALL_64_fastpath+0x12/0x6d
    Jul 27 15:56:46 Server kernel: Mem-Info:
    Jul 27 15:56:46 Server kernel: active_anon:1844977 inactive_anon:10104 isolated_anon:0
    Jul 27 15:56:46 Server kernel: active_file:555155 inactive_file:761395 isolated_file:0
    Jul 27 15:56:46 Server kernel: unevictable:4571771 dirty:629 writeback:53 unstable:0
    Jul 27 15:56:46 Server kernel: slab_reclaimable:261411 slab_unreclaimable:31708
    Jul 27 15:56:46 Server kernel: mapped:31517 shmem:100649 pagetables:16889 bounce:0
    Jul 27 15:56:46 Server kernel: free:90006 free_pcp:64 free_cma:0
    Jul 27 15:56:46 Server kernel: Node 0 DMA free:15892kB min:64kB low:80kB high:96kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15976kB managed:15892kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
    Jul 27 15:56:46 Server kernel: lowmem_reserve[]: 0 1979 31930 31930
    Jul 27 15:56:46 Server kernel: Node 0 DMA32 free:128068kB min:8372kB low:10464kB high:12556kB active_anon:501832kB inactive_anon:3032kB active_file:29564kB inactive_file:26644kB unevictable:1411940kB isolated(anon):0kB isolated(file):0kB present:2174356kB managed:2164640kB mlocked:1411940kB dirty:12kB writeback:0kB mapped:9220kB shmem:25704kB slab_reclaimable:46352kB slab_unreclaimable:4568kB kernel_stack:912kB pagetables:4532kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
    Jul 27 15:56:46 Server kernel: lowmem_reserve[]: 0 0 29951 29951
    Jul 27 15:56:46 Server kernel: Node 0 Normal free:216064kB min:126728kB low:158408kB high:190092kB active_anon:6878076kB inactive_anon:37384kB active_file:2191056kB inactive_file:3018936kB unevictable:16875144kB isolated(anon):0kB isolated(file):0kB present:31195136kB managed:30670976kB mlocked:16875144kB dirty:2504kB writeback:212kB mapped:116848kB shmem:376892kB slab_reclaimable:999292kB slab_unreclaimable:122264kB kernel_stack:15408kB pagetables:63024kB unstable:0kB bounce:0kB free_pcp:256kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:64 all_unreclaimable? no
    Jul 27 15:56:46 Server kernel: lowmem_reserve[]: 0 0 0 0
    Jul 27 15:56:46 Server kernel: Node 0 DMA: 1*4kB (U) 0*8kB 1*16kB (U) 0*32kB 2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (U) 3*4096kB (M) = 15892kB
    Jul 27 15:56:46 Server kernel: Node 0 DMA32: 809*4kB (UME) 936*8kB (UME) 1036*16kB (UME) 571*32kB (UME) 261*64kB (UME) 118*128kB (UM) 36*256kB (UM) 13*512kB (UME) 16*1024kB (UME) 5*2048kB (M) 2*4096kB (M) = 128068kB
    Jul 27 15:56:46 Server kernel: Node 0 Normal: 26167*4kB (UME) 9745*8kB (UME) 2095*16kB (U) 14*32kB (U) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 216596kB
    Jul 27 15:56:46 Server kernel: 1417236 total pagecache pages
    Jul 27 15:56:46 Server kernel: 0 pages in swap cache
    Jul 27 15:56:46 Server kernel: Swap cache stats: add 0, delete 0, find 0/0
    Jul 27 15:56:46 Server kernel: Free swap  = 0kB
    Jul 27 15:56:46 Server kernel: Total swap = 0kB
    Jul 27 15:56:46 Server kernel: 8346367 pages RAM
    Jul 27 15:56:46 Server kernel: 0 pages HighMem/MovableOnly
    Jul 27 15:56:46 Server kernel: 133490 pages reserved
    Jul 27 15:56:46 Server kernel: qemu-system-x86: page allocation failure: order:4, mode:0x260c0c0

     

    Sometimes repeating LOTS of times.

     

    They've been there for quite some time throughout the 6.2 beta's, however I also believed they started to appear when the motherboard was replaced with the replacement board (the one installed currently).

     

    I initially reported about it here http://lime-technology.com/forum/index.php?topic=48193.msg471875#msg471875

    then followed up here https://lime-technology.com/forum/index.php?topic=49705.msg481602#msg481602.

    I requested a support request from LT which resulted in this (I think they're a little busy lately!!)

    I've reviewed your post and the log and unfortunately don't have much to comment on at this time.  I would suggest trying the latest RC to see if any improvements are there.  This definitely feels hardware-specific as it's the first case of this I've seen.  We'll keep our eyes open and see if we can recreate this ourselves, but the initially look is that it's hardware-related which means it will be difficult to reproduce.

     

    I followed up hoping to get some pointing in a direction as to a way to figure out, but that was 2 weeks ago and I got nothing back.  :-[

     

    I've played with the memory timings just in case something is odd... Nada.

    Newest Bios, check... New fancy power supply cause it was my birthday (HX850i), check (no difference, but I didn't figure it was related).

    Memtest included and the Passmark (newest) version, all passed multiple tests.

    Tried various XMP, and "optimization" settings related to RAM in the BIOS, no different..

    Everything else set to Auto, lowered to 2133 from 2400 just in case.

     

    I was thinking this was an OOM issue related to KVM or QEMU, however no one has thought this to be the case from the entry in the Syslog, so I guess that is not the case.

    These parts to me always look suspicious

    Jul  4 12:47:20 Server kernel: 0 pages in swap cache
    Jul  4 12:47:20 Server kernel: Swap cache stats: add 0, delete 0, find 0/0
    Jul  4 12:47:20 Server kernel: Free swap  = 0kB
    Jul  4 12:47:20 Server kernel: Total swap = 0kB
    Jul  4 12:47:20 Server kernel: 8338252 pages RAM
    Jul  4 12:47:20 Server kernel: 0 pages HighMem/MovableOnly

     

    While these don't always make UnRAID unstable, they certainly aren't supposed to be there.

    Sometimes however they get bad enough to where a VM will shutdown. However I have also recently seen an OOM related issue, which did force a shutdown of 3 of 4 active VM's.

     

    Current diagnostics attached, along with this fluke of an OOM condition I had the other day which is likely unrelated to this (I was playing with ram settings a little, so it may be related).

     

    If you have some thoughts, great, as I am about to just buy a new MB (I don't really WANT to do this!) if not as I have wasted too much time on this..  :-\

     

    The WAF also went down, to the "your other hardware seemed to be fine, why did you get this new stuff you've had a lot of issues?" (no comment)..  :P

    server-diagnostics-20160727-1728.zip

    server-syslog-20160725-1930.zip

  4. I have also tried changing the machine type and the number of cores and the activation has stuck so far.

     

    lionelhutz has tried changing machine type and reports activation is okay when changed

     

    I think this is still questionable, as I recently performed some testing on this very thing (it was not specifically for this, but related).

    This is what I know on my main W10 VM activated using i440FX.

    Activated status, disable network (thought it'd be a good idea) and shutdown.

    Changed to Q35 (was testing for a USB related issue), checked activation "Windows is not activated" can't connect to Microsoft, blah blah (meaning the switch to Q35 flagged it to break the initial activation).

    Shutdown, change back to i440FX, re-enable network, "Windows is not activated" still a can't connect displaying.

    Try to hit the manual check option, not working.

    Reboot, same not activated message.

     

    Stop thinking about it, use computer as normal, check back a day or so later "Windows is activated".

     

    So the change to Q35 certainly made Windows take notice and kill my initial activation status (this machine has been activated for the last 6 months).

    However, would keeping it at Q35 from i440FX eventually lead to an activated status? IDK, however I have my doubts as this is basically a new motherboard to M$ and that almost always flags re-activation.

  5. I assume RC2? If so LT is aware, no fix currently.

    I'm trying to add a new(ish) disk to the array but after I've assigned it to an empty slot (disk 2 slot) and started the array it just loops and goes straight back to "click start to bring array online and pre-clear disk, etc" without the array actually starting. The disk hasn't been used on unRAID before and is freshly cleared in OS X.

     

    I recall an issue like this quite some time ago (perhaps V5 era). Diagnostics attached.

     

    Cheers

     

    https://lime-technology.com/forum/index.php?topic=50344.msg484087#msg484087

     

    Yes, this is a bug.  Fixed in next release.

    https://lime-technology.com/forum/index.php?topic=50344.msg484087#msg484087

  6. The G210 I used to use for testing did the exact same thing.

    This card worked fine in Linux/OE (needed legacy drivers) not so much in Windows. I think it was better with passing the rom, so I'd recommend trying that.

    Fortunately when this happens your entire server does not lockup, as that was the norm for me.

    I have a feeling even without installing the drivers (using basic display drivers) multiple reboots or power offs of the VM will result in strange behavior, however I'd like to be wrong in that assumption.

  7. In response to my own questions: it looks like AMD does not have onboard graphics so I'm assuming I would need 2 GPUs for an AMD build, one for the unraid system ( maybe something cheap) and one for the VM?

     

    With an AMD card, no, you can "steal" it from the UnRAID console however you will have no console output (which many including myself do not have).

    You can also do it with Nvidia cards, but there is some trickery to get it to work.  ;)

    While AMD will work no doubt, I and many others will recommend Intel as it is the primary platform UnRAID is tested on, and even though you get less cores you get better per core ratings.

    I think if you run a lot of VM's the extra cores can help with isolation, however the comparison of 4 AMD cores to 2 Intel cores is likely not much difference (I say this without looking at specific ratings, but I know a 4 core i5 goes against an 8 core FX).

  8. Hi bungee91 ,

    I did your win 10 fix and its working Thanks

    Now when i want to connect to the folder of my m i get

    -bash: /mnt/disks/kvm/domains/OpenELEC: Is a directory

    I have my vms folder in Unassigned Devices

    And i should connect to it but i cant !

    I really need help i cant connect to the vms folder

    Because when i try to go through the steps i get  [ Error writing .config/modprobe.d/sound.conf: No such file or directory ]

     

    Hi Sniper, really hoping someone other than me reads this and gives you direction (sorry, command line is a when I need to, not a cause I like to kind of thing)  :D

     

    It sounds as if your OE VM is located at " /mnt/disks/kvm/domains/OpenELEC"

    At the bash prompt type

    cd  /mnt/disks/kvm/domains/OpenELEC

    this should get you into the directory, then you can make the folders, and create the needed file using nano.

  9. Okay, so I've updated my mainboard BIOS to the latest version, tried different settings (SeaBIOS/OVMF and different machines), Hyper V off. Did also try with Windows 7 (with and without the xml line rom file..)

    Anything else I can test or check?

     

    Did you attempt to pass the rom for the card?

    Instructions in the wiki somewhere (sorry, in a hurry).

  10. Hi bungee91,

    I did create the file in my mac by text editor and copy it to oe in the network and past it

    If this wrong Can you please guide as i am newbie LOL

    I think amd is the best in unraid no problems i hope i will buy cheap amd card

    And i want to run this built if i can https://forum.libreelec.tv/thread-302.html

    Can i run it ?

     

    Thanks a lot

     

    I think that's probably well enough, but can't say for sure.

    I'm by no means great at using a console based text editor, but it is basically:

    At the command line when in the directory for your OE/LE VM (such as /mnt/cache/VMs/OE/) type:

    nano .config/modprobe.d/sound.conf

     

    I can't recall if the folders are there or not by default, if not you may have to make the folders first

    A directory location you could be in at the shell is (as an example)  /mnt/cache/VMs/OE/ type:

    mkdir .config

    now when in the .config folder that you just created (/mnt/cache/VMs/OE/.config/) type:

    mkdir modprobe.d

     

    Now that we have the needed folders:

    nano .config/modprobe.d/sound.conf

    Type:

    options snd-hda-intel enable_msi=1

    into the nano file editor, exactly as written.

     

    Exit nano

    CTRL + X

    When asked to save the modified file, say yes.

    Boot or restart your OE/LE VM.

     

    There's likely a much easier way to do this, I had to look that up to give directions..  :D

     

     

    Also, Nvidia is the recommended GPU from Limetech and others on the Vfio forums. AMD is a bit more hit or miss with some cards.

  11. I've tried with SeaBIOS, but I wonder if I have to reboot UnRAID between each try because when I try to start a VM with the card attached the screen goes black (UnRAID console is lost)

     

    No reboot needed, and the console going black is to be expected.

    When using SeaBIOS and starting a VM the console output will always be lost as there is a VGA arbitration "thing" going on (I'm not looking it up right now) and this is to be expected.

    The console will only come back after a reboot. The boot option with the GUI I don't believe has this issue (however I've never tried).

    Unless your card is in hard locked state, reboot or power down will likely not help.

    Thinking of that, and likely not your issue. If your card was hard locked, a complete power off with removal of power (turn off PSU, unplug, etc...) would get the card useable again, however this is not common at all and I doubt the issue. 

     

     

  12. Hi bungee91,

    I do have the same problem with the lastest unraid version and nvidia gpu

    I did the config file and restart the vm nothing happen

    The sound like in the menu and no sound when you play anything

    I do have my own post on that https://lime-technology.com/forum/index.php?topic=50267.0

    And i hope we can fix it

    And it seems the problem not only with OpenELEC & LibreELEC

    I did see it in Win 10

    I have Steam os It did work amazing and some time you do get no sound at boot after that its working with no problem

     

    One more thing, many Nvidia cards in Windows need the MSI interrupt set. There is a utility here to do this for you, if not you'll eventually get "demonic audio".

    Searching............: Thread is here https://lime-technology.com/forum/index.php?topic=47089.msg453669#msg453669

    I have noticed when upgrading drivers this gets set back to off, so you may have to complete this again if you update.

  13. Just want to make sure you did the config file exactly as posted, using nano or vi to edit/create the file using ssh?

    This has always solved the OE (and I suppose now LE) issues for Nvidia cards.

    I believe I also had to set passthrough to on for all supported formats, but perfect after that.

     

    As described I would get the "indefinite clicking sounds (much like if you were to hold down an arrow key and continually scroll through the main menu)", but this solved it.

    The last time I went to set one of these up (OE VM) I had issues with the Nvidia driver not being installed and I had to follow steps outlined in this thread https://lime-technology.com/forum/index.php?topic=47550.msg458389#msg458389 to get the Nvidia drivers installed, however this is not either of your issues.

  14. For OE you have to do the following:

    create file in config folder of OE

     

    .config/modprobe.d/sound.conf

    and put line

    options snd-hda-intel enable_msi=1

     

    That should fix the audio stutter right away (reboot after change).

    I thought this was supposed to be done automatically WAY back in 6.1 days, I guess not.  ;)

    • Upvote 1
  15. Lousy.

    Well I'm uncertain that this is tied to a driver anyhow, just some troubleshooting is all.

    Now that I think of it the 710 wasn't released at that point yet, so it certainly makes sense.

    I had only heard of the most recent Nvidia driver giving issues, however it is also possible that driver is no longer the most recent.

     

    The OE fix should solve that issue, however uncertain with Windows.

    What make is the 710 you have? I know some Asus cards can be a pain in the ass (for whatever reason, likely a card rom/bios issue).

    Have you attemped to extract the rom and add it to the XML of the VM?

    I wouldn't think for this card it is needed, but at this point it is worth trying.

  16. You do realize you need 2 video cards if you want to pass through to a VM? unRAID needs a video input and the VM needs one. Doesn't matter if unRAID is using onboard or a installed card.

     

    This is a false statement, UnRAID doesn't require a GPU at all however will certainly use one if it is available.

    The reason we need two cards is an Nvidia issue, and not apparent with an AMD GPU (however the workaround gridrunner linked to has been successful for many individuals) .

    I have four video cards and run 4 VM's with GPU's assigned, UnRAID grabs the 1st card (AMD) initially, and then I "steal" it away for my primary VM.

     

    You do realize you need 2 video cards if you want to pass through to a VM? unRAID needs a video input and the VM needs one. Doesn't matter if unRAID is using onboard or a installed card.

    Yeah, like I said: I did try to add another graphic card (9500 GT), placed it in slot 1 and moved the 650 card to slot 2. No changes.

    And it seems like users with one GPU have got it working: http://lime-technology.com/forum/index.php?topic=43644.0

     

    When you had two Nvidia cards, you got the exact same condition/issue?

    Have you tried SeaBIOS as opposed to OVMF? OVMF/UEFI doesn't work with all cards.

  17. I've also tried OpenELEC. It works great on the GPU. It worked on the GT710 but the audio stuttered badly. I only tried it with the PCIe ACS Override OFF and think it should have been ON since there are other PCI devices in the same group as the GT710.

     

    For OE you have to do the following:

    create file in config folder of OE

     

    .config/modprobe.d/sound.conf

    and put line

    options snd-hda-intel enable_msi=1

     

    That should fix the audio stutter right away (reboot after change).

     

    I'm surprised you're having such issues with the 710, as it is very similar to the 720, which I have nothing but good things to say about (which means it is boring in that it just works, X2 or X3 for me).

    Anyhow, the only thing I can think of off hand is removing any remnants of old drivers prior to installing new ones. The best way is to use the DDU utility http://www.guru3d.com/files-details/display-driver-uninstaller-download.html to wipe out everything and start fresh. I have not updated the drivers in a while, however had heard newer Nvidia drivers were causing issues.

    I'm currently on 361.43 and have tested many prior versions, with no issues. It looks like 361.43 is pretty old by now though (1/19/2016), but you may want to try it. I experienced no longer than expected display blackout when installing the driver on 3 seperate VM's, Windows 10 64 bit, i440FX (newest, 2.5?), and SeaBIOS.

     

  18. If you motherboard BIOS allows for selection of GPU based on the slot (as mine and I'm sure others do, as both my recent builds allowed for this), you can add a secondary GPU for UnRAID and set the primary GPU for boot/UnRAID to that GPU, leaving the 16X slot available for a VM.

    If you have an old style PCI slot (most don't anymore), you can even buy a cheesy ~$10 PCI video card, and use that to for boot/UnRAID usage, leaving the other card available.

     

    The thread that is mentioned for single Nvidia GPU passing to a VM is located here: https://lime-technology.com/forum/index.php?topic=43644.msg464975#msg464975

     

    I'm in the AMD in the 1st slot (I've had this card prior to switching to the "one machine to rule them all" thinking), Nvidia in all of the rest.

    Boot/UnRAID does its thing on that primary card, then I steal it away for my primary VM, which works pretty well (I'd also call this "magic").

  19. Many people have had great luck with the AMD 6450 so if you have them you may want to try them first, and also the 5450 (however I didn't so I won't recommend it).

    Since your build looks to have onboard GPU, I'd recommend you stick with Nvidia, as they're the current recommended card overall (AMD can be a bit more picky across the range of selection).

    Low power, possibly fanless, I highly recommend the GeForce GT710/720/730 I have extensively tested the 720 in both SeaBIOS (my primary usage) and OVMF and do not have any complaints.

     

  20. 1a. Is it possible to install Unraid on my PC and have it boot directly to Windows 10 with Unraid running in the background?  My family occasionally use my PC, so I need something that lets them reboot and login easily if necessary if I'm not there i.e. I don't want them having to use Unraid to boot into Windows 10

     

    No, you will not be able to do any of this without VT-d there is no way around this (Your subject line clearly states "Non VT-D Installation").

    UnRAID doesn't need a GPU, however it will grab one if it is there and available, however any VM will still be managed by the host/hypervisor which would then allocate/assign resources to the VM. To do this with a GPU (or any physical hardware device), you need VT-d, as the VM is a child to UnRAID as the parent.

    The best you can do is boot UnRAID in GUI mode, however that environment is not meant for anything more than UnRAID management.

  21. I thought this may have been solved, but just noticed it cropped up again in my syslog (certainly took longer to show up than previous beta (up 14 days now)).

    I'm not positive I understand your statement, as it almost sounds like you've had this before?  It's the first one like this that I've seen.

     

    These messagess have been common for me on the last couple of beta's, and I have reported as such in at least one other of the threads.

    I honestly don't know what causes it, just know that over time I get these messages again, and again, and again.

    They do not result in instability (which to me is quite surprising) and my assumptions is whatever is managing memory reallocates this, and everything goes back to working as it should (meaning no more of these in the syslog). On previous beta's I received these messages much earlier in regards to uptime.

    These parts of that snippet don't seem correct, as I'd assume these should be a value > "0" 

    Jul  4 12:47:20 Server kernel: 0 pages in swap cache
    Jul  4 12:47:20 Server kernel: Swap cache stats: add 0, delete 0, find 0/0
    Jul  4 12:47:20 Server kernel: Free swap  = 0kB
    Jul  4 12:47:20 Server kernel: Total swap = 0kB
    Jul  4 12:47:20 Server kernel: 8338252 pages RAM
    Jul  4 12:47:20 Server kernel: 0 pages HighMem/MovableOnly

     

    When I first started getting these I assumed it was my setup, as I recently had my motherboard die, and this board (exact same as prior) is pickier about ram timings (I have them set to relaxed timings, no XMP, a bit more voltage just in case).

    Anyhow, I've ran Memtest for plenty of passes with 0 errors (can only run the included Memtest in default/non multithreaded mode or it will fail), however I've considered grabbing a newer version that is aware of DDR4 and the X99 chipset, and running that for stability tests.

     

    I do have a BIOS update available, and will venture on installing it soon. There is a good reason I have delayed this, as I have tested with newer versions (there were plenty of beta release bios's for my board, I am actually currently on one), however they had worse issues such as: not being able to get into setup, a warning about PCIe resources low, etc...

    Most of the bios updates are because of the newer CPU's available for the X99 socket, now that Skylake versions have been released.

     

    I mentioned this same issue in the B21 thread here http://lime-technology.com/forum/index.php?topic=48193.msg471875#msg471875

    Similar issue, supposedly fixed and should be included in the current kernel https://bugzilla.kernel.org/show_bug.cgi?id=93251

    Fixed in v4.0

    commit 744961341d472db6272ed9b42319a90f5a2aa7c4

        kvm: avoid page allocation failure in kvm_set_memory_region()

     

    Thanks for looking, I appreciate any help with this!

     

    Edit:

    Edit: forgot to mention one more symptom, there are 3 'migration' processes running at CPU of '99', which would appear to be another indicator that the system is ailing, but I don't know more.  There are 12 migration processes, one per core to help distribute the CPU workload.  The fact that 3 are running near max means something's wrong.

    I will look into this further, as I have no experience with something of that nature.