Recently upgraded to r297351, once running iovctl -C -f /etc/iovctl.conf everything appears to work as it should. The main network interface ramains connected and pinging works fine. iovctl.conf PF { device : ix1; num_vfs : 31; } DEFAULT { passthrough : true; } VF-0 { passthrough : false; } VF-1 { passthrough : false; } Once vf's have been initialized, I have found none-passthrough vf's are unusable. # devctl attach pci0:129:0:129 devctl: Failed to attach pci0:129:0:129: Input/output error The dmesg spits out the same error as before, so it appears that the errors I was mentioning before is actually the none-passthrough vf's attempting to attach, but fails. /var/log/messages: ixv0: <Intel(R) PRO/10GbE Virtual Function Network Driver, Version - 1.4.6-k> at device 0.131 on pci12 ixv0: Using MSIX interrupts with 2 vectors ixv0: ixgbe_reset_hw() failed with error -100 device_attach: ixv0 attach returned 5 ixv0: <Intel(R) PRO/10GbE Virtual Function Network Driver, Version - 1.4.6-k> at device 0.129 on pci12 ixv0: Using MSIX interrupts with 2 vectors ixv0: ixgbe_reset_hw() failed with error -100 device_attach: ixv0 attach returned 5 On Wed, Mar 9, 2016 at 5:36 PM, Ultima <ultima1252_at_gmail.com> wrote: > I have been interested in this when I first read about it in 2012. =] > > Can this be done in loader.conf? I have vmm_load="YES" > > I'm not sure if the vf's are usable, I have not actually tested the vf's. > The parent ix1 still shows no response. > > kldunload vmm > > kenv hw.vmm.force_iommu=1 > > kldload vmm > > iovctl -Cf /etc/iovctl.conf > > The same error messages appear, I currently on hmm i'm not sure, I > upgraded with git and it doesn't show rev(last time I use git for > source?) 8b372d1(master) > > On Wed, Mar 9, 2016 at 5:00 PM, Eric Joyner <ricera10_at_gmail.com> wrote: > >> I don't know if you're still interested in this, but did you do "kenv >> hw.vmm.force_iommu=1" before loading the vmm module? I think that might be >> necessary. >> >> On Wed, Feb 24, 2016 at 5:12 PM Ultima <ultima1252_at_gmail.com> wrote: >> >>> Yeah, still getting the -100 error, I do have sendmail disabled. I just >>> tested with sendmail up and running then add the VF's and it still shows >>> the error message. >>> >>> On Wed, Feb 24, 2016 at 8:04 PM, Eric Joyner <ricera10_at_gmail.com> wrote: >>> >>>> Are you still getting the -100 errors when trying to load the VF driver? >>>> >>>> I've tried SR-IOV on a system here, and I can confirm that traffic >>>> stops passing on the PF interface when you create a VF interface. That >>>> didn't used to happen, so I'm investigating why that is right now. >>>> >>>> On Wed, Feb 24, 2016 at 8:09 AM Ultima <ultima1252_at_gmail.com> wrote: >>>> >>>>> Decided to do some more tests, I actually have a second board with >>>>> sr-iov >>>>> capabilities that I used for awhile with vmware esxi. I decided to test >>>>> this out and unfortunately it won't activate, it is giving the no space >>>>> left on device error message. I double checked bios and all VT-d >>>>> related >>>>> options are enabled and have hw.ix.num_queues="4" in >>>>> /boot/loader.conf. Is >>>>> there anything else that may need to be set? .(It did work on vmware) >>>>> >>>>> For my second test, I moved the X540-AT1 to the board with the >>>>> X540-AT2. >>>>> It functioned with the same issues as the AT2 tho. >>>>> >>>>> >>>>> I don't think I listed the motherboards in question yet so ill list >>>>> them >>>>> now. >>>>> >>>>> S1200BTLRM - >>>>> >>>>> http://ark.intel.com/products/69633/Intel-Server-Board-S1200BTLRM?q=S1200BTLRM >>>>> MD80-TM0 >>>>> <http://ark.intel.com/products/69633/Intel-Server-Board-S1200BTLRM?q=S1200BTLRMMD80-TM0> >>>>> - http://b2b.gigabyte.com/products/product-page.aspx?pid=5146#ov >>>>> >>>>> I'm not sure if it will be of any help tho. >>>>> >>>>> Ultima >>>>> _______________________________________________ >>>>> freebsd-current_at_freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to " >>>>> freebsd-current-unsubscribe_at_freebsd.org" >>>>> >>>> >>> >Received on Mon Mar 28 2016 - 15:29:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:03 UTC