heilage

Hey guys. I've had my rig up and running for a little over a year, but there is a need emerging for doing more Linux desktop work, and I need a GPU for that. So I'm looking for suggestions. When i've previously tried this with an Nvidia GTX 970, the results left a lot to be desired. A lot of unstable behavior, and difficulties with drivers. I'm not sure if there are inherent problems with Nvidia cards in unRAID VM setups, or if this was something else, but I'm looking for suggestion for a cheap GPU to put in that provides decent driver support for Linux (Fedora in particular). The only physical requirement is DP1.2 output, because I daisy chain my monitors.

As of yesterday, I was looking for a system crash, which should have been logged in some form, but I gained access to the event logs for my alarm system, and it turns out to have been some kind of power error that evening. Looks like unRAID was fine, but I should get a UPS on it anyway. I'll have to ask my alarm company why they couldn't tell me what was in the event log in my alarm system, but that's another matter. Thanks for helping

I do not have a UPS (should though... one of those things), so the parity check is running now. Everything seems to be fine though, at least for now. I'll try the plugin, so I can check it out if it happens again. If not, I'll have to chalk it up to a coincidence or freak occurrence. I have no pets (sadly), and to my knowledge no critters, so I doubt that was the issue.

Hi everyone. Last night my Plex docker died (was not at home), and I couldn't connect to it again for some reason. When I got home today, my server was dead. I apparently didn't have a power outage, I called my alarm company and they could inform me that there hasn't been any outages recently that affected my system. So I'm concluding that my server died, for some reason. I booted it back up, and it seems to be working, but the syslogs all start from today, I can't seem to find any logs or diagnostics that are older than when I just now turned it on. What happened here? Shouldn't unRAID keep the old logs, at least for a while?

I suspect that the root issue here is in Windows, actually. I have previously (although not in unRAID setups) had problems with Windows being finicky about which audio outputs were enabled/disabled and presedence. Could you show a screenshot of your output devices from Windows? (Right click on the sound icon in the taskbar)

Updates abound! Sorry for the delay, I'm preparing to move to a new apartment, so I have less time to mess around with my computers, naturally. Right now, stability looks pretty good. I've rebooted several times, shutdown unRAID and rebooted it to see if I lose any configs. As far as I can see, I haven't gotten any reboot loops or BSODs for a while. I have no tried editing syslinux like jonp suggested though, but I might as well try it. I even got games from network shares to work (enabling visible shares for alternate accounts helped massively). Pretty happy with the results right now, but I'd still like to know what was causing all my issues. And who knows, the BSODs might turn up again. I haven't had any issues since disabling core 0 for VMs though, as I read in another post that unRAID uses it a lot. I want more cores...

I've been using 0.1.110, I believe it was the recommended version?

Since installing the drivers often cause the issues, yes. I use the latest stable set, from GeForce Experience. In the previous thread, I also rolled back the drivers in an attempt to fix the issues, but it did not help.

Oh, forgot to mention that. I set the CPU cores to 3 since that post, and have not changed it since. Also, I always pass through the audio now too. I have updated the GPU BIOS, luckily Gainward supplies self-installing updates from their website, so it went smoothly. I'm working on setting MSI interrupts now (it was disabled). EDIT: Enabled MSI interrupts, rebooted, still working fine. EDIT2: Getting random BSODs now. First SYSTEM_SERVICE_EXCEPTION, then MEMORY_MANAGEMENT, but in both cases it boots normally again after a reboot. This is on SeaBIOS. Also, has anyone experienced that unRAID switches the vdisk order, so that it doesn't boot?

Suggestions from any angle are welcome I have not messed with MSI interrupts, and right now I have a SeaBIOS based one working. I'm not using HDMI sound, but it does say to do it anyway. I would also like to try flashing the ROM/BIOS on my GPU, I will report back with results. (Trying the MSI thingy first)

Okay, so I'm having a bunch of issues in general with my Windows VMs. There appears to be two patterns emerging: SeaBIOS - Mostly work fine on initial installation, I can even use it for some time to game - Fail after a few days to BSODs with SYSTEM_THREAD_EXCEPTION_NOT_HANDLED, and constant reboots, caused by the graphics card - Perhaps something goes wrong here after a reboot as well? OVMF - When they crash, and they do, they take unRAID with them - Will also crash when initializing driver - Non-persistent boot configuration whenever unRAID goes down, will not boot after a reboot and has to be reinstalled/reconfigured from scratch The issues appear to be linked to the initialization of the graphics drivers, on my Nvidia GTX 970. This card should work fine, but it does not. Linux appears to be fine in most cases, although Fedora had some issues after I fiddled around with some drivers and window managers. That said, right now I can boot both my Xubuntu and Fedora VMs (SeaBIOS based) just fine. I upgraded to unRAID 6.1.7 this weekend, and I was hoping for some stability, but thus far no luck. I refer you also to my thread from last week or so: https://lime-technology.com/forum/index.php?topic=45367.0 What am I doing wrong? I've had to install Windows 10 10-15 times the past two weeks, I can't help but feel that something is very wrong. I could RMA my GTX 970, but if it is the cause of my issues, why is Linux working fine?

I think you can, Jon. I haven't had any issues since. (Is there a button for marking it as solved? I can't find it)

Hah, don't worry about that. It was my own error (although I can't remember this being specified in the manual?). I'm just glad it's working again, although I do wonder what made it work the past month or so.

It works! It was working fine with Win10 natively installed, so I was suspicious as to what could cause it, if the GPU was not faulty (it may still be, but that remains to be seen). I will address this point by point: - This was not recommended, as per my google results. I did not do this step. - Changed to OVMF, may have contributed to my success - HyperV is off, always have been - GPU firmware, I left this as-is, to limit the number of variables. Also, the newest firmware is older than when I bought the card (may still be outdated though) - Switched from 110 to 109, may have contributed to my success - I did not know about this. I have never forwarded the GPU audio, and as such, this may have been the issue all along. It would also kinda make sense given my BSOD. Setting this may have contributed. - MSI interrupts have not been set, but this could be an option. Thank you, you put me on the right track! More testing and verifications are necessary, but this was a huge help.

I'm not sure if I have a spare 8.1 image available that can be used to install (I don't think I have a key right now, I believe I need one to install?). I'm starting to think that this might be down to the GPU itself, and a hardware issue (maybe the RAM?). There appears to be some instruction running when the GPU initializes that causes it to crash, and it wouldn't surprise me if the process is different under Ubuntu, considering it has a completely different driver package, which may explain why it does not break when booting there. I'm going to yank out the power on the unRAID drives and try to install Win10 again directly. If it fails again, I believe we have our man. It actually didn't occur to me that the GPU might be faulty until I woke up this morning. It's less than a year old, so RMAing it shouldn't be an issue, if that's the case. If it works fine on a native Windows installation, then I'm not sure what to do. Scrapz: I actually haven't set a lot of the things you mention, but considering that Win10 was working fine for a good month before it suddenly crashed, these things shouldn't really be that relevant? It appears to have spontaneously died on me, but of course, it may have been running half-assed without me noticing (I have had some issues, and I haven't had time to go into heavy usage yet).

Try installing Windows 10 and just disable windows update completely. Install the missing drivers from Device manager from the mounted virtio iso and then Install your Nvidia Drivers. Already tried that today, same result. Immediate crash on completion and reboot of the Nvidia drivers, both with the old (1/12) and new (23/12) drivers. EDIT: Tried again for luck. Clean W10, no updates, latest nvidia drivers, crash.

Sorry, I'm bumping this, my whole machine is broken and I can't explain why. Se the edits at the bottom of the first post.

Hey guys. I was booting up my Windows VM today, as usual, and discovered to my dismay that for some reason, it was now stuck in some kind of loop. The boot process crashes, it reboots, try to repair, BSODs with SYSTEM_THREAD_EXCEPTION_NOT_HANDLED, reboots again, crashes, and so forth. Once, this loop ran enough times for Windows to apparently "fix" itself, but then the whole OS suffered greatly from lag and even opening up a menu took a second or two. Hopeless. Quick rundown: - When removing the GPU passthrough on my Nvidia GTX970, it boots fine and I can interact with the system over VNC - I uninstalled the Nvidia drivers over VNC, reenabled GPU passthrough, and it booted fine - When installing the latest drivers (I had drivers from 9/12, latest was 21/12), the cycle repeats on reboot - Disabling/enabling cores or other passthrough devices appear to have no effect, on the GPU - Booting into Ubuntu with the same devices appear to work just fine, so I do not think it is related to any physical components On Wednesday (6/1), it worked fine and I was using it. It has been off since. What the hell has happened in the meantime? If a Windows Update was causing the crash, then it would presumably crash when the GPU is not attached as well. Of course, an update could have been issued that specifially broke compatibilty with the GTX 970 on any recent drivers, but that seems unlikely, no? Remember, this happens on both the latest and penultimate driver sets here, and it worked fine as of Wednesday, so the drivers have not been updated since (I also, upon removing the drivers over VNC, saw that they were dated 9/12). Has anyone experienced anything like this? As of right now, my VM is broken. And that sucks. Settings: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>Prometheus</name> <uuid>32e936ec-5987-9089-029f-574bd8c1cbb2</uuid> <description>Spillmaskina</description> <metadata> <vmtemplate name="Custom" icon="windows.png" os="windows"/> </metadata> <memory unit='KiB'>12582912</memory> <currentMemory unit='KiB'>12582912</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='1'/> <vcpupin vcpu='2' cpuset='2'/> <vcpupin vcpu='3' cpuset='3'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='4' threads='1'/> </cpu> <clock offset='localtime'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/cache/VMer/Prometheus/vdisk1.img'/> <target dev='hda' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/cache/VMer/Prometheus/vdisk2.img'/> <target dev='hdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:4d:8f:4b'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/Prometheus.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x046d'/> <product id='0xc52b'/> </source> </hostdev> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x046d'/> <product id='0xc318'/> </source> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </memballoon> </devices> <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='ioh3420,bus=pci.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=00:1b.0,bus=root.1,addr=01.0'/> </qemu:commandline> </domain> Specs: - MSI Z97S SLI Krait Edition S-1150 ATX - Intel i5-4440 - Mixed 20GB RAM - Samsung 840 250GB SSD EDIT: I made a new, clean VM. Installed fine. Updated Windows (which included some set of Nvidia drivers), and it broke again. There is definitely something with a Windows Update crashing this, I suspect. EDIT2: Removed all Windows updates, still crashes. Going to try rolling back Nvidia drivers now. EDIT3: So yeah. I think there is a problem with UnRaid and the GPU passthrough with Windows 10. There is no previously confirmed working configuration that works as of now. In addition, every time the VM crashes now, it kills unRAID and I have to do a dirty reboot. This is not acceptable. What should I do?

Here are the benchmarks for the system drive, which is a vdisk on the cache, and the mounted share where the steam library is, which is a cache-only share, mounted through SMB. Doesn't seem bad at all, so I guess AS SSD was the issue for me.

I benched it with AS SSD, but I'll give it a go with Crystal Disk Mark and report back with the results some time during the weekend.

How did you mount outside of the array? Are we talking like it's a raw drive formatted for Windows? My cache drive is a Samsung 840 250GB, and I run the vdisks off it. Maybe the SSD itself is dying...

I haven't had time to look into this, unfortunately. Some notes: - I only use local accounts - Currently, unRAID shares are invisible to my Windows VM. Should they not be browseable? They must manually be added by using hostname or IP - I know that any application running as administrator (or requiring UAC, like running first time setup) does not see my mounted share. Why? Is it only mounted on user level? - It does appear that running a game off a network share, except in jonp's case, even on SSD, has a high performance penalty? So far vdisks seem to be the best way to do this, which is less than optimal as a practical solution I guess. I attached the XML for my VM, maybe someone can spot something. Have I perhaps set up the network in a bad way? In the meantime I'll keep tinkering, and I'm going to try to bench the cache-only share to see what kind of reads and writes I'm getting. <domain type='kvm' id='11' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>Prometheus</name> <uuid>32e936ec-5987-9089-029f-574bd8c1cbb2</uuid> <description>Spillmaskina</description> <metadata> <vmtemplate name="Custom" icon="windows.png" os="windows"/> </metadata> <memory unit='KiB'>12582912</memory> <currentMemory unit='KiB'>12582912</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='1'/> <vcpupin vcpu='2' cpuset='2'/> <vcpupin vcpu='3' cpuset='3'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='4' threads='1'/> </cpu> <clock offset='localtime'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/cache/VMer/Prometheus/vdisk1.img'/> <backingStore/> <target dev='hda' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/cache/VMer/Prometheus/vdisk2.img'/> <backingStore/> <target dev='hdb' bus='virtio'/> <alias name='virtio-disk1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <controller type='usb' index='0'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:4d:8f:4b'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/0'/> <target port='0'/> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/0'> <source path='/dev/pts/0'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/Prometheus.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x046d'/> <product id='0xc52b'/> <address bus='1' device='6'/> </source> <alias name='hostdev0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x046d'/> <product id='0xc318'/> <address bus='1' device='5'/> </source> <alias name='hostdev1'/> </hostdev> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </memballoon> </devices> <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='ioh3420,bus=pci.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=00:1b.0,bus=root.1,addr=01.0'/> </qemu:commandline> </domain> EDIT: Holy crap, I benched the C: drive (vdisk1) with AS SSD, and got 0,5MB/s 4K Write. What the hell? This can't be normal? A lot in this setup seems to be off. EDIT2: I messed around a bit more and painted myself into a corner. It turns out, you can do a soft link in the main steam folder to the SMB share, which appears to work well and Steam assumes all games are locally. The backside of this however, is that the space calculations are done on the C drive, which means that if your free space is less than the size of the game, it will not install, even though you're not actually installing it to C. Not sure how to get around this, but I might just create a new VM and reinstall...

Well, i guess we're gonna have to get to work then. I want to figure this out. If I have time tomorrow, I will return with a bunch of data describing setups and settings, and we can have a look at how it differs from a working setup.

I noticed he was using a newer beta, I'm currently on the last official release. Any word on release date for 6.2?

For a short time, I had serious issues as well. Even opening the start menu in Windows would lag horribly, and playing anything was out of the question. This resolved itself when I played around with the settings, it would appear that the issues I had were caused by allocating cores 1-3, and it worked as expected with cores 0-2 or 0-3, but in the meantime I also installed QEMU-drivers, so I'm honestly not sure what did the trick. But obviously, you are stilling having issues despite this.