tinimun

What directory were you in when you ran the patch?

Have you tried patching and recompiling your kernel as suggested in this thread?

Do you still need help with this passthrough?

Make sure you're running patch from the root directory of the Linux kernel source tree.

Read up on recompiling your kernel. I don't actually use unraid (I'm on arch), but my patch should get you half of the way there. I'm still running it successfully on Linux 4.9. The patch incantation I used in the Linux kernel source tree (once you've downloaded the file in my gist) was: patch -Np1 -i /path/to/0001-Add-quirks-for-Yuan-Yuan-Enterprises-capture-cards.patch The other half is setting an option for vfio-pci (specifically, the disable_idle_d3=1 one). @allanp81 - you might not need the kernel patch if the card is recognized in the VM. No guarantee that disable_idle_d3 will fix your case, but it's worth trying.

I'm very happy to report that today's work has paid off. Everything works! Not bad for a Saturday. Here's a picture of my Wii U's output displaying on the Elgato application in a GPU passthrough Windows guest on the right, with the hypervisor's GPU on the left. The HDMI output from the card also works flawlessly, so you can mirror it on an external monitor as Elgato intended. http://i.imgur.com/nrbZssD.jpg Here's the kernel patch you need (tested against 4.4.5): https://gist.github.com/numinit/40fc5ad96fd0990b0a63 Raw URL: https://gist.githubusercontent.com/numinit/40fc5ad96fd0990b0a63/raw/de80ac51ba846b733968ddcac56f71e4dc070206/0001-Add-quirks-for-Yuan-Yuan-Enterprises-capture-cards.patch And, in /etc/modprobe.d/vfio.conf or similar: options vfio-pci ids=12ab:0380 disable_idle_d3=1 Essentially, idle d3 and bus resets are what hose the card. I'm going to see if I can get my patch merged into mainline.

For some reason, the card enumerates, but stays on "No Signal." Looking into this. I think bus resets are what breaks it, so keeping that quirk and removing the PM reset quirk.

Progress. Enabled both quirk_no_pm_reset and quirk_no_bus_reset for this device, and it enumerates in the Windows guest. Here is a very high-resolution picture of the board after removing the cover. The actual SoC used (chip on the right) is the Mozart 395S combo PCIe controller/H.264 encoder. Here is the specsheet. http://i.imgur.com/JMdBp2h.jpg Finally, a kernel patch: https://gist.github.com/numinit/40fc5ad96fd0990b0a63/ I will keep this thread updated. Somehow managed to screw up my Windows user account during this process.

I will try rebuilding the kernel with quirk_no_pm_reset set for this device and report back.

I'm using an Asus X99-A motherboard with a Core i7-5930K. Isn't iommu=pt usually for AMD hardware? In any case, I tried that (with unsafe interrupts enabled), and don't think unsafe interrupts are the issue. The device is instantly being taken over by vfio-pci at boot, and issues seem to arise when a PCI reset occurs. Here's the -vvv output for lspci on that device, at a fresh boot of the hypervisor: 07:00.0 Non-VGA unclassified device: Yuan Yuan Enterprise Co., Ltd. Device 0380 Subsystem: Device 1cfa:0003 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 18 NUMA node: 0 Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=32M] Region 4: I/O ports at 0000 Region 5: Memory at f8000000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 3 Flags: PMEClk- DSI- D1+ D2- AuxCurrent=375mA PME(D0+,D1+,D2-,D3hot+,D3cold-) Status: D3 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [70] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <1us, L1 <8us ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset- SlotPowerLimit 0.000W DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <512ns, L1 <16us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Capabilities: [140 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- Kernel driver in use: vfio-pci In this state, /sys/kernel/iommu_groups/34/devices/0000:07:00.0/config seems to contain useful data when I look at it with hexdump. And, after booting the guest OS: 07:00.0 Non-VGA unclassified device: Yuan Yuan Enterprise Co., Ltd. Device 0380 (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: vfio-pci A hexdump of the config in this state contains all ff. If I run: echo 1 > /sys/kernel/iommu_groups/34/devices/0000:07:00.0/remove ... the device is removed, but: echo 1 > /sys/bus/pci/rescan doesn't make it come back. Maybe this device is broken when PCI resets happen?

Currently in the same situation with vfio-pci. lspci -vnn output: 07:00.0 Non-VGA unclassified device [0000]: Yuan Yuan Enterprise Co., Ltd. Device [12ab:0380] Subsystem: Device [1cfa:0003] Flags: bus master, fast devsel, latency 0, IRQ 18, NUMA node 0 Memory at f6000000 (32-bit, non-prefetchable) [size=32M] I/O ports at 0000 Memory at f8000000 (32-bit, non-prefetchable) [size=4K] Capabilities: [40] Power Management version 3 Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Endpoint, MSI 00 Capabilities: [100] Advanced Error Reporting Capabilities: [140] Virtual Channel Kernel driver in use: vfio-pci