bungee91 Posted June 17, 2015 Share Posted June 17, 2015 I have a tuner card passed into a W8.1 VM that works very well when it is available within the VM. From a complete off state, power on my server, load VM, all is well! I can reboot the VM, and all is well. I cannot shutdown the VM and power it back up, that specific device will not show up in the device manager of the VM. I do not receive any errors from starting the VM, such as device not available, etc... I do believe I have seen an error message before if I edit the VM and then try to start it (when the device is at that point in this odd state). The only thing I can do to fix it (reset it) is a complete power down of the server, drain the power (switch off supply), wait, boot up. So, the device is likely hanging on once the VM shuts down, and will not reset when it comes back up. I assume this is an issue as the device does not support FLReset (function level reset) and I just have to live with it.... However neither does the NIC that I am passing through,and works every time! Device info on the tuner card in question: 06:00.0 Multimedia controller: Philips Semiconductors SAA7160 (rev 01) Subsystem: Avermedia Technologies Inc Device 1e55 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, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at f6e00000 (64-bit, non-prefetchable) [size=1M] Capabilities: [40] MSI: Enable- Count=1/32 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [50] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <4us, L1 <64us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt- Capabilities: [74] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] Vendor Specific Information: Len=50 <?> Capabilities: [100 v1] Vendor Specific Information: ID=0000 Rev=0 Len=088 <?> Kernel driver in use: vfio-pci Device info on the NIC I pass which works great!: 09:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) Subsystem: Intel Corporation PRO/1000 PT Server Adapter 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, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 48 Region 0: Memory at f6b40000 (32-bit, non-prefetchable) [size=128K] Region 1: Memory at f6b20000 (32-bit, non-prefetchable) [size=128K] Region 2: I/O ports at 9000 [disabled] [size=32] Expansion ROM at f6b00000 [disabled] [size=128K] Capabilities: [c8] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME- Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee00618 Data: 0000 Capabilities: [e0] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- 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, Latency L0 <4us, L1 <64us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- 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] Device Serial Number 00-15-17-ff-ff-c0-48-03 Kernel driver in use: vfio-pci Kernel modules: e1000e I do see the NIC has a "Kernel modules: e1000e" listed where the tuner does not.. Maybe there is just that much better support for the NIC that it works well?.. If there is anything I can force in the XML for this to reset, that'd be fantastic. Link to comment
archedraft Posted June 17, 2015 Share Posted June 17, 2015 I assume this is an issue as the device does not support FLReset (function level reset) and I just have to live with it.... However neither does the NIC that I am passing through,and works every time! I was going to post the same assumption. Have you tried adding the vfio-bind command to unRAID's "go" file so that the tv tuner isn't seen by unRAID? I doubt this would fix it but it is certainly worth trying. Should add something like this to your "go" file but change the "0000:01:00.0" to match your tv tuner's ID -> toolts -> system devices /usr/local/sbin/vfio-bind 0000:01:00.0 Link to comment
bungee91 Posted June 17, 2015 Author Share Posted June 17, 2015 I assume this is an issue as the device does not support FLReset (function level reset) and I just have to live with it.... However neither does the NIC that I am passing through,and works every time! I was going to post the same assumption. Have you tried adding the vfio-bind command to unRAID's "go" file so that the tv tuner isn't seen by unRAID? I doubt this would fix it but it is certainly worth trying. Should add something like this to your "go" file but change the "0000:01:00.0" to match your tv tuner's ID -> toolts -> system devices /usr/local/sbin/vfio-bind 0000:01:00.0 I can try it, I do like how the VM manager (however it does it) automatically binds it for you now, however if it is causing an issue it is dead to me!.. I could stub it so that unRaid really doesn't see it, however it shouldn't bind this type of adapter regardless (certainly had to do that with the NIC, which as mentioned works very well). I know in the XEN days (here, not in general) that with GPU pass you could eject it prior to shutdown, which would help this kind of situation, however that was specific to GPU's, and no clue if it is even helpful under KVM. Link to comment
jonp Posted June 17, 2015 Share Posted June 17, 2015 The best thing you should try is to disable fast boot from within the Windows 8 VM. http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html See if that changes anything for you. FYI, vfio-bind scripts are absolutely and positively not necessary anymore. Never ever ever manually put them in anymore. They truly are not needed. Link to comment
bungee91 Posted June 17, 2015 Author Share Posted June 17, 2015 The best thing you should try is to disable fast boot from within the Windows 8 VM. http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html See if that changes anything for you. FYI, vfio-bind scripts are absolutely and positively not necessary anymore. Never ever ever manually put them in anymore. They truly are not needed. Will give it a shot, thanks for the feedback today!. I would think this would be more helpful for reboots than complete off/on conditions, however will certainly try it out. Link to comment
jonp Posted June 19, 2015 Share Posted June 19, 2015 The best thing you should try is to disable fast boot from within the Windows 8 VM. http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html See if that changes anything for you. FYI, vfio-bind scripts are absolutely and positively not necessary anymore. Never ever ever manually put them in anymore. They truly are not needed. Will give it a shot, thanks for the feedback today!. I would think this would be more helpful for reboots than complete off/on conditions, however will certainly try it out. Actually the reverse is true. Fastboot is utilized on power off / on like a hibernate feature almost, but when you do a reboot in windows, it doesn't take affect. Link to comment
bungee91 Posted June 19, 2015 Author Share Posted June 19, 2015 The best thing you should try is to disable fast boot from within the Windows 8 VM. http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html See if that changes anything for you. FYI, vfio-bind scripts are absolutely and positively not necessary anymore. Never ever ever manually put them in anymore. They truly are not needed. Will give it a shot, thanks for the feedback today!. I would think this would be more helpful for reboots than complete off/on conditions, however will certainly try it out. Actually the reverse is true. Fastboot is utilized on power off / on like a hibernate feature almost, but when you do a reboot in windows, it doesn't take affect. Yeah, actually reading it and NOT assuming would have been helpful prior to posting!.. I'm certain I will try this in the coming weekend along with my other list of nagging issues. I'll share my experiences. Quick question: I can technically install the VM outside of the array and leave the array stopped in order to play with GPU pass, correct? This way if things lock up (which for me is more likely than not) a parity check is not needed after I power off/up. Link to comment
archedraft Posted June 19, 2015 Share Posted June 19, 2015 FYI, vfio-bind scripts are absolutely and positively not necessary anymore. Never ever ever manually put them in anymore. They truly are not needed. So the I do not need to bind my GPU's anymore? I'm assuming I still need to bind my dual Ethernet NIC for pfsense, correct? Link to comment
bungee91 Posted June 19, 2015 Author Share Posted June 19, 2015 So the I do not need to bind my GPU's anymore? I'm assuming I still need to bind my dual Ethernet NIC for pfsense, correct? I have a 2nd NIC passed to a VM, no need for any manual binding, just have to stub it. Link to comment
jonp Posted June 20, 2015 Share Posted June 20, 2015 So the I do not need to bind my GPU's anymore? I'm assuming I still need to bind my dual Ethernet NIC for pfsense, correct? I have a 2nd NIC passed to a VM, no need for any manual binding, just have to stub it. Bungee is correct. When the VM is started, the bindings to vfio-pci occur automatically now. Link to comment
archedraft Posted June 20, 2015 Share Posted June 20, 2015 So the I do not need to bind my GPU's anymore? I'm assuming I still need to bind my dual Ethernet NIC for pfsense, correct? I have a 2nd NIC passed to a VM, no need for any manual binding, just have to stub it. Bungee is correct. When the VM is started, the bindings to vfio-pci occur automatically now. Well then... UnRAID got all fancy without me knowing Link to comment
bungee91 Posted June 20, 2015 Author Share Posted June 20, 2015 The best thing you should try is to disable fast boot from within the Windows 8 VM. http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html See if that changes anything for you. FYI, vfio-bind scripts are absolutely and positively not necessary anymore. Never ever ever manually put them in anymore. They truly are not needed. This fixed my issue, if it isn't already, I'd recommend adding this somewhere in the wiki (hopefully people actually read it, lots of good info!). Thanks for the tip, would have never thought of this! You can mark this as solved! Link to comment
jonp Posted June 20, 2015 Share Posted June 20, 2015 The best thing you should try is to disable fast boot from within the Windows 8 VM. http://www.eightforums.com/tutorials/6320-fast-startup-turn-off-windows-8-a.html See if that changes anything for you. FYI, vfio-bind scripts are absolutely and positively not necessary anymore. Never ever ever manually put them in anymore. They truly are not needed. This fixed my issue, if it isn't already, I'd recommend adding this somewhere in the wiki (hopefully people actually read it, lots of good info!). Thanks for the tip, would have never thought of this! Will do and good call! Link to comment
archedraft Posted June 20, 2015 Share Posted June 20, 2015 So the I do not need to bind my GPU's anymore? I'm assuming I still need to bind my dual Ethernet NIC for pfsense, correct? I have a 2nd NIC passed to a VM, no need for any manual binding, just have to stub it. Bungee is correct. When the VM is started, the bindings to vfio-pci occur automatically now. I removed all the vifo bind lines from my "go" file and everything booted up just fine! Pretty cool stuff. EDIT: I removed a USB device from my windows VM that has an entire controller passed through and the VM freaked out! Then the graphics started blinking randomly... So I added the vifo bind lines back and everything is happy again. **if it ain't broke... Link to comment
jonp Posted June 20, 2015 Share Posted June 20, 2015 So the I do not need to bind my GPU's anymore? I'm assuming I still need to bind my dual Ethernet NIC for pfsense, correct? I have a 2nd NIC passed to a VM, no need for any manual binding, just have to stub it. Bungee is correct. When the VM is started, the bindings to vfio-pci occur automatically now. I removed all the vifo bind lines from my "go" file and everything booted up just fine! Pretty cool stuff. EDIT: I removed a USB device from my windows VM that has an entire controller passed through and the VM freaked out! Then the graphics started blinking randomly... So I added the vifo bind lines back and everything is happy again. **if it ain't broke... I can guarantee you that the vfio bind doesn't have anything to do with it, but it doesn't hurt to do what you're doing either, so if it makes you feel better, why not! Link to comment
bungee91 Posted June 29, 2015 Author Share Posted June 29, 2015 Quick update/observation. I can reboot the VM and shut it down just fine, card works without issues (which is great, as the removal of fastboot fixed the shutdown problem), however I cannot reboot the server and expect the card to work in the VM afterwards. I just installed 6.0.1, told it to reboot, and no card available after bootup (VM loads without any error, it's just not in device manager/etc...). Power down completely, drain power (switch off at PSU, wait), power back on, all is well.... So at least I know I cannot reboot the server in order for it to continue to work, and I suppose that's good enough considering. Link to comment
jonp Posted June 29, 2015 Share Posted June 29, 2015 Quick update/observation. I can reboot the VM and shut it down just fine, card works without issues (which is great, as the removal of fastboot fixed the shutdown problem), however I cannot reboot the server and expect the card to work in the VM afterwards. I just installed 6.0.1, told it to reboot, and no card available after bootup (VM loads without any error, it's just not in device manager/etc...). Power down completely, drain power (switch off at PSU, wait), power back on, all is well.... So at least I know I cannot reboot the server in order for it to continue to work, and I suppose that's good enough considering. This definitely sounds like a device-specific issue. I've never witnessed such behavior with any of my VMs. Link to comment
bungee91 Posted June 29, 2015 Author Share Posted June 29, 2015 Yeah, seems like it, as the NIC I pass doesn't have this issue at all.. Oh well, it works, it's just picky. =) Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.