Re: svn commit: r209611 - head/sys/dev/e1000
On 18 August 2010 14:52, pluknet pluk...@gmail.com wrote: On 17 August 2010 20:27, Jack Vogel jfvo...@gmail.com wrote: Cool the first person to actually try and use it :) Yes, there's one key thing you have to do right now that's not documented, because of the simplistic PCI structure the guest has the kernel blacklists it from using MSIX. SO, what you need to do is set the honor_blacklist (that's not the complete string, use sysctl -a |grep blacklist to find it) and set that to 0. It needs to be set at boot. That should get you running. Jack Nice, thanks! It works! By the way, Sometimes after boot I have to kldreload if_igb.ko several times until watchdog go to sleep, so traffic starts flowing. igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 1, hw tdt = 1 igb0: TX(0) desc avail = 1023,Next TX to Clean = 0 igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 3, hw tdt = 3 igb0: TX(0) desc avail = 1021,Next TX to Clean = 0 igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 6, hw tdt = 6 igb0: TX(0) desc avail = 1018,Next TX to Clean = 0 igb0: detached igb0: Intel(R) PRO/1000 Network Connection version - 2.0.1 mem 0xf202-0xf2023fff,0xf2024000-0xf2027fff at device 4.0 on pci0 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 76:99:ea:b0:e0:eb igb0: link state changed to UP stray irq0 stray irq0 igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 3, hw tdt = 3 igb0: TX(0) desc avail = 1021,Next TX to Clean = 0 stray irq0 stray irq0 too many stray irq 0's: not logging anymore igb0: promiscuous mode enabled igb0: Watchdog timeout -- resetting igb0: Queue(0) tdh = 28, hw tdt = 28 igb0: TX(0) desc avail = 996,Next TX to Clean = 0 igb0: promiscuous mode disabled igb0: detached igb0: Intel(R) PRO/1000 Network Connection version - 2.0.1 mem 0xf202-0xf2023fff,0xf2024000-0xf2027fff at device 4.0 on pci0 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 76:99:ea:b0:e0:eb igb0: link state changed to UP dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.1 dev.igb.0.%driver: igb dev.igb.0.%location: slot=4 function=0 handle=\_SB_.PCI0.S4__ dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10ca subvendor=0x8086 subdevice=0xa03c class=0x02 dev.igb.0.%parent: pci0 dev.igb.0.nvm: -1 dev.igb.0.flow_control: 3 dev.igb.0.enable_aim: 1 dev.igb.0.rx_processing_limit: 100 dev.igb.0.link_irq: 0 dev.igb.0.dropped: 0 dev.igb.0.tx_dma_fail: 0 dev.igb.0.device_control: 0 dev.igb.0.rx_control: 0 dev.igb.0.interrupt_mask: 0 dev.igb.0.extended_int_mask: 0 dev.igb.0.tx_buf_alloc: 0 dev.igb.0.rx_buf_alloc: 0 dev.igb.0.fc_high_water: 58976 dev.igb.0.fc_low_water: 58960 dev.igb.0.queue0.txd_head: 424 dev.igb.0.queue0.txd_tail: 424 dev.igb.0.queue0.no_desc_avail: 0 dev.igb.0.queue0.tx_packets: 186 dev.igb.0.queue0.rxd_head: 758 dev.igb.0.queue0.rxd_tail: 758 dev.igb.0.queue0.rx_packets: 4855 dev.igb.0.queue0.rx_bytes: 316295 dev.igb.0.queue0.lro_queued: 0 dev.igb.0.queue0.lro_flushed: 0 dev.igb.0.queue1.txd_head: 0 dev.igb.0.queue1.txd_tail: 0 dev.igb.0.queue1.no_desc_avail: 0 dev.igb.0.queue1.tx_packets: 0 dev.igb.0.queue1.rxd_head: 0 dev.igb.0.queue1.rxd_tail: 1023 dev.igb.0.queue1.rx_packets: 0 dev.igb.0.queue1.rx_bytes: 0 dev.igb.0.queue1.lro_queued: 0 dev.igb.0.queue1.lro_flushed: 0 dev.igb.0.mac_stats.good_pkts_recvd: 0 dev.igb.0.mac_stats.good_pkts_txd: 0 dev.igb.0.mac_stats.good_octets_recvd: 0 dev.igb.0.mac_stats.good_octest_txd: 0 dev.igb.0.mac_stats.mcast_pkts_recvd: 0 -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn commit: r209611 - head/sys/dev/e1000
On Thu, Aug 19, 2010 at 2:45 AM, pluknet pluk...@gmail.com wrote: By the way, Sometimes after boot I have to kldreload if_igb.ko several times until watchdog go to sleep, so traffic starts flowing. Hmmm, the intention is that the VF always be single queue, but I see the code I used to limit it is broken, so you are getting two queues. For now near the top of if_igb.c set igb_num_queues = 1; I believe that will get rid of the watchdogs. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn commit: r209611 - head/sys/dev/e1000
On 17 August 2010 20:27, Jack Vogel jfvo...@gmail.com wrote: Cool the first person to actually try and use it :) Yes, there's one key thing you have to do right now that's not documented, because of the simplistic PCI structure the guest has the kernel blacklists it from using MSIX. SO, what you need to do is set the honor_blacklist (that's not the complete string, use sysctl -a |grep blacklist to find it) and set that to 0. It needs to be set at boot. That should get you running. Jack Nice, thanks! It works! On Tue, Aug 17, 2010 at 8:18 AM, pluknet pluk...@gmail.com wrote: Hi, Jack. I set up qemu-kvm on openSUSE 11.3 with 82576 PCI device as you described. Guest fails to attach with: igb0: Intel(R) PRO/1000 Network Connection version - 2.0.1 mem 0xf206-0xf2063fff,0xf2064000-0xf2067fff at device 5.0 on pci0 igb0: Unable to allocate bus resource: interrupt device_attach: igb0 attach returned 6 i...@pci0:0:5:0: class=0x02 card=0xa03c8086 chip=0x10ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 11[40] = MSI-X supports 3 messages in map 0x1c Did I missed something? -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn commit: r209611 - head/sys/dev/e1000
On 1 July 2010 02:13, Jack Vogel jfvo...@gmail.com wrote: On Wed, Jun 30, 2010 at 2:50 PM, Julian Elischer jul...@elischer.orgwrote: On 6/30/10 10:26 AM, Jack F Vogel wrote: Author: jfv Date: Wed Jun 30 17:26:47 2010 New Revision: 209611 URL: http://svn.freebsd.org/changeset/base/209611 Log: SR-IOV support added to igb What this provides is support for the 'virtual function' interface that a FreeBSD VM may be assigned from a host like KVM on Linux, or newer versions of Xen with such support. When the guest is set up with the capability, a special limited function 82576 PCI device is present in its virtual PCI space, so with this driver installed in the guest that device will be detected and function nearly like the bare metal, as it were. The interface is only allowed a single queue in this configuration however initial performance tests have looked very good. Enjoy!! do these extra devices turn up in a standard ifconfig output? in other words, can we assign them to jails using vimage? They only show up if configured in the PF host, for instance if using Linux and KVM (I did develop and test with Fedora 13) you must load the igb driver there specifying that you want vf's created and how many. Next in the management of the guest you need to assign one of these vf devices to the guest. After you do all that and load this igb driver then yes, it will look just like a standard igbX device. Hi, Jack. I set up qemu-kvm on openSUSE 11.3 with 82576 PCI device as you described. Guest fails to attach with: igb0: Intel(R) PRO/1000 Network Connection version - 2.0.1 mem 0xf206-0xf2063fff,0xf2064000-0xf2067fff at device 5.0 on pci0 igb0: Unable to allocate bus resource: interrupt device_attach: igb0 attach returned 6 i...@pci0:0:5:0:class=0x02 card=0xa03c8086 chip=0x10ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 11[40] = MSI-X supports 3 messages in map 0x1c Did I missed something? -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn commit: r209611 - head/sys/dev/e1000
Cool the first person to actually try and use it :) Yes, there's one key thing you have to do right now that's not documented, because of the simplistic PCI structure the guest has the kernel blacklists it from using MSIX. SO, what you need to do is set the honor_blacklist (that's not the complete string, use sysctl -a |grep blacklist to find it) and set that to 0. It needs to be set at boot. That should get you running. Jack On Tue, Aug 17, 2010 at 8:18 AM, pluknet pluk...@gmail.com wrote: On 1 July 2010 02:13, Jack Vogel jfvo...@gmail.com wrote: On Wed, Jun 30, 2010 at 2:50 PM, Julian Elischer jul...@elischer.org wrote: On 6/30/10 10:26 AM, Jack F Vogel wrote: Author: jfv Date: Wed Jun 30 17:26:47 2010 New Revision: 209611 URL: http://svn.freebsd.org/changeset/base/209611 Log: SR-IOV support added to igb What this provides is support for the 'virtual function' interface that a FreeBSD VM may be assigned from a host like KVM on Linux, or newer versions of Xen with such support. When the guest is set up with the capability, a special limited function 82576 PCI device is present in its virtual PCI space, so with this driver installed in the guest that device will be detected and function nearly like the bare metal, as it were. The interface is only allowed a single queue in this configuration however initial performance tests have looked very good. Enjoy!! do these extra devices turn up in a standard ifconfig output? in other words, can we assign them to jails using vimage? They only show up if configured in the PF host, for instance if using Linux and KVM (I did develop and test with Fedora 13) you must load the igb driver there specifying that you want vf's created and how many. Next in the management of the guest you need to assign one of these vf devices to the guest. After you do all that and load this igb driver then yes, it will look just like a standard igbX device. Hi, Jack. I set up qemu-kvm on openSUSE 11.3 with 82576 PCI device as you described. Guest fails to attach with: igb0: Intel(R) PRO/1000 Network Connection version - 2.0.1 mem 0xf206-0xf2063fff,0xf2064000-0xf2067fff at device 5.0 on pci0 igb0: Unable to allocate bus resource: interrupt device_attach: igb0 attach returned 6 i...@pci0:0:5:0:class=0x02 card=0xa03c8086 chip=0x10ca8086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 11[40] = MSI-X supports 3 messages in map 0x1c Did I missed something? -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
