goober07

6.2.0-rc4 Couldn't get kodibuntu to work at all. Trying openelec and gpu passthrough doesn't seem to be working. warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 16] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 17] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 23] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 24] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 0] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 1] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 2] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 3] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 4] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 5] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 6] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 7] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 8] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 9] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 12] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 13] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 14] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 15] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 16] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 17] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 23] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 24] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 0] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 1] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 2] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 3] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 4] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 5] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 6] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 7] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 8] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 9] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 12] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 13] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 14] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 15] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 16] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 17] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 23] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 24]

http://slickdeals.net/f/9075255-toshiba-x300-6tb-desktop-3-5-inch-sata-6gb-s-7200rpm-internal-hdd-170-shipped-amazon Seems like a lot of storage for money. Think it's worth it?

Resurrecting this because I had to use xfs_repair for the first time via the webUI. Initially, the drive in question was had the file system set to "auto" which hid the ability to check the file system. Stopping the array and changing that to xfs got the display issue fixed. But running with the option -nv left me just as confused as RobJ. It ran, and nothing in the report stood out to me saying "we found errors - run this again without the -n." Since the disk still would not mount, I figured I had nothing to lose by running xfs_repair -v, so I did and that ended up fixing it.

Ran xfs_repair from the webui, but I don't really know what all of this means: Phase 1 - find and verify superblock... - block cache size set to 260056 entries Phase 2 - using internal log - zero log... zero_log: head block 445198 tail block 445198 - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 3 - agno = 2 Phase 5 - rebuild AG headers and trees... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... Maximum metadata LSN (1:445691) is ahead of log (1:445198). Format log to cycle 4. XFS_REPAIR Summary Wed Aug 31 19:09:41 2016 Phase Start End Duration Phase 1: 08/31 19:08:35 08/31 19:08:35 Phase 2: 08/31 19:08:35 08/31 19:08:35 Phase 3: 08/31 19:08:35 08/31 19:08:37 2 seconds Phase 4: 08/31 19:08:37 08/31 19:08:37 Phase 5: 08/31 19:08:37 08/31 19:08:37 Phase 6: 08/31 19:08:37 08/31 19:08:39 2 seconds Phase 7: 08/31 19:08:39 08/31 19:08:39 Total run time: 4 seconds done edit: apparently it means xfs_repair fixed whatever I managed to do to disk1's file system! It mounted, my old shares are back, and I've grabbed the files I really wanted (not that was looking forward to re-ripping my movies, but still...) I will say figuring out xfs_repair was a huge pain. Unraid kept setting disk1 to auto instead of xfs, which meant "check filesystem" didn't appear in the webui. Figured it out though. Thanks for the help everyone.

Fair to say. Tried firmware update, disconnecting the parity disk, removing the (unused) SY-PEX40039 sata expansion card, and swapping parity & disk1 ports. When none of those worked, I reinstalled the expansion card, connected disk1 & parity to it, and still won't mount. Yes it is. Parity & Disk1 were working with an SSD as cache on my previous build. I swapped the SSD for an older 160GB HDD because I returned my previous build to bare metal Windows 10. I started the array with this configuration, and disk1 mounted fine with the new cache. Moved the 3 drives and expansion card over to the new build, and disk1 hasn't mounted since. I appreciate the help so far. I think I'll add the 160GB to the array & recalculate parity just to change the UUID on the parity. If that's how it works. I have no idea how the UUID is generated, I'm just inferring based on johnnie.black's post: Edit: here's the diagnostics for tonight. I'm seeing errors... Aug 31 18:55:13 Tower kernel: XFS (md1): Corruption warning: Metadata has LSN (1:445683) ahead of current LSN (1:445198). Please unmount and run xfs_repair (>= v4.3) to resolve. Aug 31 18:55:13 Tower kernel: XFS (md1): log mount/recovery failed: error -22 Aug 31 18:55:13 Tower kernel: XFS (md1): log mount failed Aug 31 18:55:13 Tower root: mount: wrong fs type, bad option, bad superblock on /dev/md1, Aug 31 18:55:13 Tower root: missing codepage or helper program, or other error Aug 31 18:55:13 Tower root: Aug 31 18:55:13 Tower root: In some cases useful info is found in syslog - try Aug 31 18:55:13 Tower root: dmesg | tail or so. Aug 31 18:55:13 Tower emhttp: shcmd: shcmd (1473): exit status: 32 Aug 31 18:55:13 Tower emhttp: mount error: No file system (32) The worst part is that I cannot create a share with disk1 emulated. Anything I name a share just displays a page "Share <name> has been deleted." There are certain files I really want to recover, and would be easy if I could simply browse there from windows file explorer like I always have. tower-diagnostics-20160831-1900.zip

Popped the flash drive over to my other pc. Checkdisk reports no issues. Created a new folder named unraid.6.1.3 and moved the flash contents into the folder. Downloaded unraid 6.2.0-rc4 & extracted to flash. Booted, assigned drives, checked "parity is already valid," and disk1 still fails to mount. I snagged this motherboard for $30 back on black friday, 2014. Asus has released 6 firmware updates since then. I don't have time tonight, but that's up next unless there's a better suggestion. I need disk1 & parity... could easily remove the cache disk during troubleshooting as I only wanted it for docker & eventually openelec.

Rebuild finished. I stopped the array, unassigned parity, started, and disk1 still doesn't mount. Screenshot attached. Going to try a new config. Edit: now I'm more concerned. New config, checked "parity is already valid," started the array, disk1 still didn't mount but unraid began a parity check with "write corrections to parity disk." I stopped the check after a few seconds. Just can't figure out if this is hardware related or not.

root@Tower:~# blkid /dev/sd*1 /dev/sda1: LABEL="UNRAID" UUID="CE45-A118" TYPE="vfat" /dev/sdb1: UUID="6a1758ff-eb08-4b30-a6bc-00192450707d" TYPE="xfs" /dev/sdc1: UUID="70633c45-30d2-418e-84d6-982261f0f9c3" TYPE="xfs" /dev/sdd1: UUID="70633c45-30d2-418e-84d6-982261f0f9c3" TYPE="xfs" Odd... why is disk 1 (ending in f9c3) showing up as sdc1 and sdd1? edit: rebuild is at 96.7% so I'll have to wait until this evening to play with it more. I didn't want to try a new config once the rebuild had started.

I'm afraid I did something wrong...running 6.1.3 if it matters. Was running 3 disks - parity, disk 1, and cache. Wasn't happy with the performance of BF4 in my Windows 10 VM, so I built a separate box for unraid. Asus A78M-E and an A8 7600. Transferred these 3 disks and the USB key. Booted fine. The array looked exactly like it did on my i5 machine. But after starting the array, disk 1 was shown unmountable. I stopped the array, removed isolcpus from my syslinux config (wasn't needed anymore), and rebooted. Same issue. Unassigned disk 1, started the array, and the emulated disk was also labeled unmountable. Stopped, reassigned disk 1, started, and now it's running a data-rebuild. Even though it says "device contents emulated," my share isn't present in the webUI. What did I break? Thanks in advance tower-diagnostics-20160830-0533.zip

Very neat. Any chance you had DPC latency measurements before & after the kernel change? Obviously your situation improved, but numbers always help illustrate the point. I run a single gaming VM with isolcpus. Obviously if I ever wanted to run another on my i5 I'm really stuck, not enough cores. Throwing more hardware at the problem isn't practical (League of Legends & such just isn't that intensive) so a new kernel would be nice

Did you pass through the HDMI Audio while setting up the VM in the web UI? List your PCI devices and iommu groups, and you will find that the video card is actually 2 pcie devices. The drivers won't work without the audio portion of the card, even if you don't intend to use it.

I've learned, with Windows 10, NOT to use the nvidia install package yourself because Windows is retrieving the version IT decided you should be running That said, you've tested the card in 2 machines and had issues. Sounds hardware related. Though GPU's do run hot, so hot to the touch isn't always a sign of a problem.

My Windows 10 VM is using a 770GTX, OVMF and i440. It's worth trying. I didn't document the issues I experienced with Seabios, but I certainly had more than one forced parity check during my tinkering. I feel your pain. Are you using the "latest" or "stable" virtio drivers? The unraid documentation says use "stable," but with Windows 10, I had to move to a newer version. However, the biggest improvement on my build was eliminating USB passthrough. Correctly passing through a PCIe - USB3 card seemed to solve issues with Windows Update, rebooting, and latency. You probably won't find a newer card that doesn't support HDMI these days... Or at least I don't see why you'd want to. The fact is it's such a pervasive standard (even if it's sole purpose is Holywood's DRM) that it just makes sense to support it. What exactly prevents you from passing through a sound card in addition to the HDMI audio? Just click the green + in the webUI to add a "2nd sound card." IF that sound card is in an iommu grouo with another device, ACS override MAY be a work around for you - but that's totally unrelated to the HDMI audio.

On March 4th I wrote that the 610 will probably not work without the HDMI audio passed through as well. Doesn't matter if you intend to use it or not, it needs passed through. With the iommu groups and devices you posted, this should work (you mentioned a conflict with a sound card - that doesn't make sense given the groups & devices you posted originally). Something else must be going on. It's not impossible that your specific 610 just doesn't like resetting properly and you'll need to move on to a 3rd gpu... Did you physically remove all other pcie cards to troubleshoot just the 610? And I know you're frustrated and say you've tried everything. Does that include bios updates? All the combos of Seabios+I440, Seabios+Q35, OVMF+i440? ACS override (if, for example, your sound card ended up grouped with another device)? Last I read, OVMF+Q35 had known issues. It took over a month to get my system "right." I was having issues that the general population didn't seem to experience. Once we got it, though, it really is quite enjoyable.

01:00.0 VGA 01:00.1 HDMI Audio Try a new VM using the web UI and make sure to pass both of these devices through. Passing a nvidia VGA controller without the associated audio device has caused problems for several of us. Sorry if you've already tried this - hard to read your xml on my phone...

For what it's worth, I solved a multitude of issues purchasing a pcie USB3 controller from amazon and passing that through to Windows 10. Now hot plugging works, usb audio isn't garbage, I don't have to manually browse to bootx64 after every server reboot, and Windows Updates no longer fail. Something about usb device passthrough and my hardware combination just didn't get along well.

The only thing that ended up fixing my usb headset was purchasing a PCIe USB 3 card and passing that through. Works like a charm, and supports hot plugging. I didn't want to do the trial & error in bios trying to split up the onboard controllers. Despite having 4 usb buses listed, every port (front panel and on the motherboard, usb2 and usb3) was showing up on the same bus as the unraid flash drive.

My original intent with this build was to pass through a 2 port controller with SSD and Bluray drive to a Windows 10 VM. I gave up, using the wonderful makemkv docker for the Bluray and ssd as cache (though I also played with the SSD mounted outside the array with the Unassigned devices plugin).

Since you're having passthrough issues with SeaBIOS, try OVMF And see Jonp's post: After powering off or rebooting the server, my VM lands at the efi shell instead of booting Windows 10. The steps to launch bootx64.efi jonp shared are the only way I can boot Windows 10. I think in another thread it was pointed out that Windows 7 doesn't support UEFI, hence won't work in OVMF. Last tip that has come up in 2 recent threads - be sure to pass through BOTH the HDMI Audio and Video portions of the 960. Others confirmed it does not work passing through only the video portion of the card.

Excellent! Is everything still running now that it's been a couple of days?

I would definitely pass through the entire card. Your card is identified just like mine: 01:00.0 VGA 01:00.1 Audio device But Now that I looked at your IOMMU groups, it might not help at all. Group 1 contains both entries above PLUS a SATA controller and a pair of PCI bridges: 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06) 00:01.1 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x8 Controller (rev 06) 02:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9230 PCIe SATA 6Gb/s Controller (rev 11) Without ACS Override or getting the GPU in another IOMMU group, everything I've read says passthrough won't work. Saarg already nailed it regarding the SATA controller - might need another motherboard. Keep digging in BIOS, but if you can't break group 1 up, I don't think you can proceed.

This may make no difference at all, but check to see if your 970 is listed a separate video and audio devices in the webUI. My 770 is. It just seems unintuitive (to me) to pass through the video-only portion of an HDMI device - who knows what the nVidia drivers expect to see. I doubt they considered the possibility of having access to part of the device blocked by the host environment. You should be able to add the onboard audio passthrough after passing the entire video card through.

Just throwing in that upgrading builds in Windows 10 guests has not worked for me either. It happened twice so far that upon guest reboot the keyboard was no longer passed through, unraid locked up, and I was forced to do a hard reset & parity check. Windows 10 also won't accept changes to processor count.

Yep. Clearly don't know what I'm doing here. Tried SeaBios instead of OVFM, and besides being very slow to boot windows setup, Windows would not install to the SSD, saying it the "system did not support booting from this disk" and to "check that the controller is enabled in bios" Am I not able to pass a SATA controller through and boot from the attached SSD?

In my case, isolcpus reduced DPC latency and fixed the video & hdmi audio stutter, but my USB headset was still a no-go. After removing it, DPC improved just a little more. There's some overhead to the virtual usb controller, and rather than troubleshoot it, I've got a pcie USB controller on the way... Going to pass that through to Windows. I might suggest removing any non-essential accessories (like a headset/DAC) or trying different keyboard/mouse, just to see if anything changes. Better yet, if you've got more than one controller available, pass it through to the VM & retest. Also, verify both VM's have each display adapter (and it's audio device) using Messaged Signaled Interrupts. My 770 required a registry edit & guest reboot. By default it was supported but not enabled. Others call it the MSI Audio Fix, but it can't hurt to test here...