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...