[E1000-devel] Las mejores ofertas de Mundo Villamorra te están esperando
Si no visualiza correctamente este E-Mail haga (Link-http://v2.envialosimple.com/campaign/htmlversion?AdministratorID=20023CampaignID=1StatisticID=1MemberID=6267s=14767a3c19522ca75f0cbc46ea6c4da2isDemo=0) (Link-http://www.mundovillamorra.com.py) Para desuscribirse de nuestra lista haga Click aquí (Link-http://v2.envialosimple.com/member/publicunsubscribe?AdministratorID=20023MemberID=6267StatisticID=1CampaignID=1isDemo=0MailListsIds[]=2MailListsIds[]=3s=d40e083b166867021cd387a939e39f3f)-- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
I'm very sorry for delayed reply.now SR-IOV works for me in Centos 6.3,thank all of you. On Fri, Nov 9, 2012 at 11:26 PM, Bjorn Helgaas bhelg...@google.com wrote: Linux normally uses the resource assignments done by the BIOS, but it is possible for the kernel to reassign those. We don't have good automatic support for that yet, but on a recent upstream kernel, you can try pci=realloc. I doubt this option is in CentOS 6.3, though Thank you very much,I try pci=realloc in Centos 6.3,and now it works for me. On Sat, Nov 10, 2012 at 2:08 AM, Li, Sibai sibai...@intel.com wrote: DellR710 with the latest BIOS should work fine for SR-IOV. My BIOS is v.6.3.0 and release date is 07/24/2012 Please check if you configured intel_iommu=on in the grub.conf file. If you did, check your kernel .config file under Device Drivers- IOMMU Hardware support-enable Support for Intel IOMMU using DMA remapping Devices, enable Intel DMA Remapping Devices by Default, enable Support for Interrupt Remapping. thank you Sibai,Our server Dell R710,its BIOS version is just v.6.3.0 and release date is 07/24/2012,and I also configured intel_iommu=on in the grub.conf file,but I can't find these IOMMU options in Device Drivers in my kernel(2.6.32-279) .config file , btw my os is Centos 6.3(RHEL6.3),although the problem solved,I'd like to know what's your os version ,kernel version? -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] Q. Default VLAN erroneous behaviour?
We're using Fedora 3.4.2-1.fc16.x86_64 Clarification on our interface (not using eth0). p19p1 Link encap:Ethernet HWaddr 00:80:50:05:23:64 inet addr:192.168.240.2 Bcast:192.168.240.255 Mask:255.255.255.0 inet6 addr: fe80::280:50ff:fe05:2364/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6452445 errors:0 dropped:2518 overruns:0 frame:0 TX packets:5863768 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:491128699 (468.3 MiB) TX bytes:553181059 (527.5 MiB) p19p1.3 Link encap:Ethernet HWaddr 00:80:50:05:23:64 inet addr:10.91.0.230 Bcast:10.91.1.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:848556 errors:0 dropped:0 overruns:0 frame:0 TX packets:488415 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:75929558 (72.4 MiB) TX bytes:181253808 (172.8 MiB) ]# ethtool -i p19p1 driver: ixgbe version: 3.11.33 firmware-version: 0x835b bus-info: :01:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes ]# ethtool -i p19p1.3 driver: 802.1Q VLAN Support version: 1.8 firmware-version: N/A bus-info: supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no We've created interface p19p1 as our main ethernet connection. This is supposed to be our default vlan: vlan 1. We have then also created other vlans such as p19p1.3 for some management messages. When I monitor vlan 3 traffic on p19p1.3 using tcpdump, I see the correct messaging with the (tag stripped) vlan 3 traffic. That's good. When I monitor p19p1 using tcpdump (non promisc), I see the untagged traffic as expected, but I also see the vlan traffic destined to p19p1.3 with the 802.1q ethernet tag. When we test leaking TIPC packets into vlan 3, we get error messages that suggest that these vlan 3 destined packets are actually be processed by our TIPC processes bound to p19p1. The problem is not restricted to TIPC, but any packets that are vlan tagged. My question to the group was, how can I tell that these vlan tagged packets are not being delivered to the processes bound to the p19p1 interface? I'm hoping that I've configured the tcpdump wrong, but when looking at the driver code, it's not clear to me where the traffic for the default vlan is being handled. We also have an older platform, not using this driver, that behaves as I expect i.e. no vlan traffic on eth0. Reading how other O/S use the interface (e.g. Cisco), it seems that they are able to specifically define the PVID/native/default VLAN. In Fedora we assume that our main ethernet connection p19p1. It seems to be correct when I look at other examples on the web or in the 802.1q standard. It's just a little fuzzy since there is no specific way of defining the native vlan. Mike Beavington Performance Technologies +1-613-287-5364 mbeav...@pt.com 40 Hines Rd, Suite 500, Ottawa, ON K2K 2M5 From: Tantilov, Emil S emil.s.tanti...@intel.com To: Michael Beavington mbeav...@pt.com, e1000-devel@lists.sourceforge.net e1000-devel@lists.sourceforge.net Date: 11/12/2012 09:26 PM Subject:RE: [E1000-devel] Q. Default VLAN erroneous behaviour? -Original Message- From: Michael Beavington [mailto:mbeav...@pt.com] Sent: Sunday, November 11, 2012 8:56 AM To: e1000-devel@lists.sourceforge.net Subject: [E1000-devel] Q. Default VLAN erroneous behaviour? I've done a tcpdump -p (non promisc) and was looking at the packets coming in on the main interface (eth0). What I was seeing was all the packets, including the vlan tagged packets for vlans 4, 5. This didn't seem right. When I tcpdumped, the vlan interfaces, I received the correct stripped packets. I'm not sure I understand what the nature of the problem is. Are you saying that the interface is receiving vlan packets meant for other interfaces, or that the vlan tags are not being stripped. It would help if you can provide more information about your setup. Where (on which interface) are vlans 4 and 5 (from your example above) configured? Thanks, Emil I was wondering if I should see those packets on eth0 for the other vlans when I execute tcpdump in the non-promiscuous mode? I was looking at the code to see where the packets are being stripped out, but it's not clear where that's happening. We're worried that packets leaking out of a different system might be impacting our own system even though the default interface should not be processing tagged packets. ixgbe 3.11.33 (we also saw this on 3.8) Mike Beavington Performance Technologies +1-613-287-5364 mbeav...@pt.com 40 Hines Rd, Suite 500, Ottawa, ON K2K 2M5 -- Monitor your physical, virtual and cloud
Re: [E1000-devel] SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
On Tue, Nov 13, 2012 at 8:04 AM, Li, Sibai sibai...@intel.com wrote: Thank you very much,I try pci=realloc in Centos 6.3,and now it works for me. thank you Sibai,Our server Dell R710,its BIOS version is just v.6.3.0 and release date is 07/24/2012,and I also configured intel_iommu=on in the grub.conf file,but I can't find these IOMMU options in Device Drivers in my kernel(2.6.32-279) .config file , btw my os is Centos 6.3(RHEL6.3),although the problem solved,I'd like to know what's your os version ,kernel version? I am using RHEL6.3 with unstable kernel 3.7.0-rc that means that config has CONFIG_PCI_REALLOC_ENABLE_AUTO=y So you don't need to append pci=realloc Yinghai -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
-Original Message- From: yhlu.ker...@gmail.com [mailto:yhlu.ker...@gmail.com] On Behalf Of Yinghai Lu Sent: Tuesday, November 13, 2012 10:17 AM To: Li, Sibai Cc: Jason Gao; bhelg...@google.com; Rose, Gregory V; ddut...@redhat.com; Kirsher, Jeffrey T; linux-kernel; netdev; kvm; e1000-devel@lists.sourceforge.net; linux-...@vger.kernel.org Subject: Re: SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV) On Tue, Nov 13, 2012 at 8:04 AM, Li, Sibai sibai...@intel.com wrote: Thank you very much,I try pci=realloc in Centos 6.3,and now it works for me. thank you Sibai,Our server Dell R710,its BIOS version is just v.6.3.0 and release date is 07/24/2012,and I also configured intel_iommu=on in the grub.conf file,but I can't find these IOMMU options in Device Drivers in my kernel(2.6.32-279) .config file , btw my os is Centos 6.3(RHEL6.3),although the problem solved,I'd like to know what's your os version ,kernel version? I am using RHEL6.3 with unstable kernel 3.7.0-rc that means that config has CONFIG_PCI_REALLOC_ENABLE_AUTO=y So you don't need to append pci=realloc Yinghai Never append pci=realloc for both kernel 2.6.32.279 and kernel 3.5.0 above. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] SR-IOV problem with Intel 82599EB (not enough MMIO resources for SR-IOV)
On Tue, Nov 13, 2012 at 10:25 AM, Li, Sibai sibai...@intel.com wrote: Never append pci=realloc for both kernel 2.6.32.279 and kernel 3.5.0 above. well, can you both post boot log with debug ignore_loglevel ? -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000e on DH55HC stalling and kernel panic in 3.6.6
-Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Denys Fedoryshchenko Sent: Tuesday, November 13, 2012 5:59 AM To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny, Carolyn; Skidmore, Donald C; Rose, Gregory V; Waskiewicz Jr, Peter P; Duyck, Alexander H; Ronciak, John; e1000-devel@lists.sourceforge.net; net...@vger.kernel.org; linux-ker...@vger.kernel.org Subject: e1000e on DH55HC stalling and kernel panic in 3.6.6 Hi I just tried to run latest kernel on my DH55HC motherboard latest kernel 3.6.6 and got various network problems, such as network traffic are stopping, and sometimes i am getting kernel panic. When traffic are stopping, ethtool -r eth0 sometimes helps. When i do ethtool -G eth0 rx NNN , sometimes it will give kernel panic, but it is hard to reproduce. I tried to capture panic on pictures, so will try to decode on what i got photo, it is a nightmare, but sadly i dont have serial in hands to get data over it. skbuff: skb_over_panic: text:f86fc769 len:25807 put:25807 head:c1da1800 data:c1da1840 tail:0xc1da7d0f end:c1da1f40 dev:eth0 kernel BUG at net/core/skbuff.c:127 opcode: [#1] SMP Pid: 0 comm: swapper/6 Not tained 3.6.6-build-0063 #23 EIP: 0060:[c02e7980] EFLAGS: 00010296 CPU:6 EIP is at skb_put+0x83/0x8e There is registers and stack, let me know if you need specific fields Call trace: f86fc769 ? e1000_clean_rx_irq+0x1e1/0x2af [e1000e] f86fc769 e1000_clean_rx_irq+0x1e1/0x2af [e1000e] f86fcc73 e1000e_poll+0x6a/0x209 [e1000e] c02f1630 net_rx_action+0x90/0x15d c01302d5 __do_softirq+0x8a/-x13b c013024b ? local_bh_enable+0xd/0xd IRQ c0130504 irq_exit+0x41/0x91 c0102c37 do_IRQ+0x79/0x8d There is also more data, let me know if you need it. Yes, please send us the full dmesg log with error. Have you tried out-of-tree e1000e driver? -Tushar -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] e1000e on DH55HC stalling and kernel panic in 3.6.6
On 2012-11-13 21:41, Dave, Tushar N wrote: -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Denys Fedoryshchenko Sent: Tuesday, November 13, 2012 5:59 AM To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny, Carolyn; Skidmore, Donald C; Rose, Gregory V; Waskiewicz Jr, Peter P; Duyck, Alexander H; Ronciak, John; e1000-devel@lists.sourceforge.net; net...@vger.kernel.org; linux-ker...@vger.kernel.org Subject: e1000e on DH55HC stalling and kernel panic in 3.6.6 Hi I just tried to run latest kernel on my DH55HC motherboard latest kernel 3.6.6 and got various network problems, such as network traffic are stopping, and sometimes i am getting kernel panic. When traffic are stopping, ethtool -r eth0 sometimes helps. When i do ethtool -G eth0 rx NNN , sometimes it will give kernel panic, but it is hard to reproduce. I tried to capture panic on pictures, so will try to decode on what i got photo, it is a nightmare, but sadly i dont have serial in hands to get data over it. skbuff: skb_over_panic: text:f86fc769 len:25807 put:25807 head:c1da1800 data:c1da1840 tail:0xc1da7d0f end:c1da1f40 dev:eth0 kernel BUG at net/core/skbuff.c:127 opcode: [#1] SMP Pid: 0 comm: swapper/6 Not tained 3.6.6-build-0063 #23 EIP: 0060:[c02e7980] EFLAGS: 00010296 CPU:6 EIP is at skb_put+0x83/0x8e There is registers and stack, let me know if you need specific fields Call trace: f86fc769 ? e1000_clean_rx_irq+0x1e1/0x2af [e1000e] f86fc769 e1000_clean_rx_irq+0x1e1/0x2af [e1000e] f86fcc73 e1000e_poll+0x6a/0x209 [e1000e] c02f1630 net_rx_action+0x90/0x15d c01302d5 __do_softirq+0x8a/-x13b c013024b ? local_bh_enable+0xd/0xd IRQ c0130504 irq_exit+0x41/0x91 c0102c37 do_IRQ+0x79/0x8d There is also more data, let me know if you need it. Yes, please send us the full dmesg log with error. Have you tried out-of-tree e1000e driver? -Tushar It is kernel panic, and screen is not good that i am unable to get proper photo. Should i try to make photos and send them as pictures? I will try to get also tomorrow USB Serial, and probably i can output there panic message. I will try also out of tree e1000e tomorrow first. --- Denys Fedoryshchenko, Network Engineer, Virtual ISP S.A.L. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] Q. Default VLAN erroneous behaviour?
-Original Message- From: Michael Beavington [mailto:mbeav...@pt.com] Sent: Tuesday, November 13, 2012 6:02 AM To: e1000-devel@lists.sourceforge.net Subject: Re: [E1000-devel] Q. Default VLAN erroneous behaviour? We're using Fedora 3.4.2-1.fc16.x86_64 Clarification on our interface (not using eth0). p19p1 Link encap:Ethernet HWaddr 00:80:50:05:23:64 inet addr:192.168.240.2 Bcast:192.168.240.255 Mask:255.255.255.0 inet6 addr: fe80::280:50ff:fe05:2364/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6452445 errors:0 dropped:2518 overruns:0 frame:0 TX packets:5863768 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:491128699 (468.3 MiB) TX bytes:553181059 (527.5 MiB) p19p1.3 Link encap:Ethernet HWaddr 00:80:50:05:23:64 inet addr:10.91.0.230 Bcast:10.91.1.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:848556 errors:0 dropped:0 overruns:0 frame:0 TX packets:488415 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:75929558 (72.4 MiB) TX bytes:181253808 (172.8 MiB) ]# ethtool -i p19p1 driver: ixgbe version: 3.11.33 firmware-version: 0x835b bus-info: :01:00.1 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes ]# ethtool -i p19p1.3 driver: 802.1Q VLAN Support version: 1.8 firmware-version: N/A bus-info: supports-statistics: no supports-test: no supports-eeprom-access: no supports-register-dump: no We've created interface p19p1 as our main ethernet connection. This is supposed to be our default vlan: vlan 1. We have then also created other vlans such as p19p1.3 for some management messages. p19p1 is the interface attached to the physical device (as seen by ethtool -i it is controlled by the ixgbe driver not the 8021q driver). As such you will see all the traffic on that device. When I monitor vlan 3 traffic on p19p1.3 using tcpdump, I see the correct messaging with the (tag stripped) vlan 3 traffic. That's good. When I monitor p19p1 using tcpdump (non promisc), I see the untagged traffic as expected, but I also see the vlan traffic destined to p19p1.3 That is correct. It is my understanding that this is by design. Perhaps you should ask your question on the Linux netdev mailing list. I'm not an expert on the subject. with the 802.1q ethernet tag. When we test leaking TIPC packets into vlan 3, we get error messages that suggest that these vlan 3 destined packets are actually be processed by our TIPC processes bound to p19p1. The problem is not restricted to TIPC, but any packets that are vlan tagged. My question to the group was, how can I tell that these vlan tagged packets are not being delivered to the processes bound to the p19p1 interface? I'm hoping that I've configured the tcpdump wrong, but when If you open a raw socket yes, but that would require root access. looking at the driver code, it's not clear to me where the traffic for the default vlan is being handled. We also have an older platform, not using this driver, that behaves as I expect i.e. no vlan traffic on eth0. The driver does not strip the packets as you expect. It may strip the vlan tags from the packet. Which driver/HW behaves differently? Every driver I had seen works as you describe in this email. Thanks, Emil Reading how other O/S use the interface (e.g. Cisco), it seems that they are able to specifically define the PVID/native/default VLAN. In Fedora we assume that our main ethernet connection p19p1. It seems to be correct when I look at other examples on the web or in the 802.1q standard. It's just a little fuzzy since there is no specific way of defining the native vlan. Mike Beavington Performance Technologies +1-613-287-5364 mbeav...@pt.com 40 Hines Rd, Suite 500, Ottawa, ON K2K 2M5 From: Tantilov, Emil S emil.s.tanti...@intel.com To: Michael Beavington mbeav...@pt.com, e1000-devel@lists.sourceforge.net e1000-devel@lists.sourceforge.net Date: 11/12/2012 09:26 PM Subject:RE: [E1000-devel] Q. Default VLAN erroneous behaviour? -Original Message- From: Michael Beavington [mailto:mbeav...@pt.com] Sent: Sunday, November 11, 2012 8:56 AM To: e1000-devel@lists.sourceforge.net Subject: [E1000-devel] Q. Default VLAN erroneous behaviour? I've done a tcpdump -p (non promisc) and was looking at the packets coming in on the main interface (eth0). What I was seeing was all the packets, including the vlan tagged packets for vlans 4, 5. This didn't seem right. When I tcpdumped, the vlan interfaces, I received the correct stripped packets. I'm not sure I understand what the nature of the problem is. Are you saying that the interface is receiving vlan packets meant for other interfaces, or that the vlan tags are not being stripped. It would help if you can provide more
Re: [E1000-devel] BUG? strange behavior with vlans and virtual functions on i350
-Original Message- From: Chris Friesen [mailto:chris.frie...@genband.com] Sent: Thursday, November 08, 2012 1:43 PM To: Levy, Lior Cc: e1000-devel@lists.sourceforge.net; Allan, Bruce W; Brandeburg, Jesse; Ronciak, John Subject: Re: [E1000-devel] BUG? strange behavior with vlans and virtual functions on i350 On 11/08/2012 02:58 PM, Chris Friesen wrote: I tried using ethtool -K ethX rxvlan off but for some reason that option always showed as off even when CTRL.VME was actually set. This is not my main problem, but somewhat related. I think I found a flaw in the driver. If you have a kernel where HAVE_VLAN_RX_REGISTER is set (newer than 2.4.18) but where HAVE_NDO_SET_FEATURES is not set (older than 2.6.39), then it appears that ethtool -K ethX rxvlan off|on will not actually change the hardware settings. It will call igb_set_flags(), which will call ethtool_op_set_flags(), but nothing calls igb_vlan_mode() to actually change the hardware setting. Chris Chris, I took a look at this with Carolyn and I believe what you're seeing is the expected behavior. In these older kernels, there was no ethtool option to turn on and off VLAN stripping on the fly. If you look, the get_flags operation just calls ethtool_op_get_flags, which doesn't recognize ETH_FLAG_RXVLAN. If you're seeing issues with the functionality of VLANs with igb alone, let us know and we'll take a look at it. Cheers, Matthew Matthew Vick Linux Development LAN Access Division Intel Corporation -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] BUG? strange behavior with vlans and virtual functions on i350
-Original Message- From: Chris Friesen [mailto:chris.frie...@genband.com] Sent: Tuesday, November 13, 2012 3:31 PM To: Vick, Matthew Cc: e1000-devel@lists.sourceforge.net; Allan, Bruce W; Ronciak, John; Brandeburg, Jesse Subject: Re: [E1000-devel] BUG? strange behavior with vlans and virtual functions on i350 What about VLANs when mixing igb/igbvf? This shouldn't involve ethtool options. It appears that the design intent is that the hardware strips off the VLAN tag but passes the information through so that it can be passed up the stack on the receiver, but this doesn't seem to be working. With the older kernel but the latest igb/igbvf drivers we're having issues as follows: We can send vlan-tagged packets from a different system and they are received in the VMs just fine. However, if we try to send vlan-tagged packets from one VF to the other it appears that the hardware is stripping the VLAN tag information and not passing it through to the other VF. As per my previous emails I can edit the driver to force vlan stripping to be disabled and it seems to let it work in certain circumstances (and I could probably get it working reliably with a bit of debugging), but I shouldn't need to edit the driver to make it work. I'd appreciate it if you could try the following scenario: host using PF, two VMs each using a different VF from that PF. Everyone is using the same VLAN with hardware stripping enabled. Then test connectivity between the two VMs, between host and VM, and from the outside world (on the same VLAN) to both host and a VM. Thanks, Chris Hello Chris, We are a bit resource constrained on this particular topic. I will need to do some research and work on a repro in order to have some advice for you. Thanks for your patience, Carolyn -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
On 11/09/12 04:35, Dave, Tushar N wrote: All devices in path from root complex to 82571, should have *same* max payload size otherwise it can cause hang. Can you double check this? Hi Tushar, Checked with hardware vendor and they said no way to modify the max payload size from BIOS, can I modify it from driver side? Thanks, Joe -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
于 2012年11月09日 04:35, Dave, Tushar N 写道: -Original Message- From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On Behalf Of Joe Jin Sent: Wednesday, November 07, 2012 10:25 PM To: e1000-de...@lists.sf.net Cc: net...@vger.kernel.org; linux-ker...@vger.kernel.org; Mary Mcgrath Subject: 82571EB: Detected Hardware Unit Hang Hi list, IHAC reported 82571EB Detected Hardware Unit Hang on HP ProLiant DL360 G6, and have to reboot the server to recover: e1000e :06:00.1: eth3: Detected Hardware Unit Hang: TDH 1a TDT 1a next_to_use 1a next_to_clean18 buffer_info[next_to_clean]: time_stamp 10047a74e next_to_watch18 jiffies 10047a88c next_to_watch.status 1 MAC Status 80383 PHY Status 792d PHY 1000BASE-T Status 3800 PHY Extended Status3000 PCI Status 10 With newer kernel 2.0.0.1 the issue still reproducible. Device info: 06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) 06:00.1 0200: 8086:10bc (rev 06) I compared lspci output before and after the issue, different as below: 06:00.1 Ethernet controller: Intel Corporation 82571EB Gigabit Ethernet Controller (Copper) (rev 06) Subsystem: Hewlett-Packard Company NC364T PCI Express Quad Port Gigabit 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- +Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- +TAbort- MAbort- SERR- PERR- INTx+ Are you sure this is not similar issue as before that you reported. i.e. On Mon, 2012-07-09 at 16:51 +0800, Joe Jin wrote: I'm seeing a Unit Hang even with the latest e1000e driver 2.0.0 when doing scp test. this issue is easy do reproduced on SUN FIRE X2270 M2, just copy a big file (500M) from another server will hit it at once. All devices in path from root complex to 82571, should have *same* max payload size otherwise it can cause hang. Can you double check this? We also found such hang problem on 82599EB (ixgbe driver) in RHEL6.3 kernel, we ever tried to upgrade to latest version (3.8.21 or 3.10.17), but it still happens. Is it probably also due to wrong max payload size set in BIOS? Thanks Yu -Tushar -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
-Original Message- From: Joe Jin [mailto:joe@oracle.com] Sent: Tuesday, November 13, 2012 6:48 PM To: Dave, Tushar N Cc: e1000-de...@lists.sf.net; net...@vger.kernel.org; linux- ker...@vger.kernel.org; Mary Mcgrath Subject: Re: 82571EB: Detected Hardware Unit Hang On 11/09/12 04:35, Dave, Tushar N wrote: All devices in path from root complex to 82571, should have *same* max payload size otherwise it can cause hang. Can you double check this? Hi Tushar, Checked with hardware vendor and they said no way to modify the max payload size from BIOS, can I modify it from driver side? If you want to change value for 82571 device you can do it from eeprom but for other upstream devices I am not sure. I will check with my team. -Tushar -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
Re: [E1000-devel] BUG? strange behavior with vlans and virtual functions on i350
On 11/13/2012 05:53 PM, Wyborny, Carolyn wrote: From: Chris Friesen [mailto:chris.frie...@genband.com] With the older kernel but the latest igb/igbvf drivers we're having issues as follows: We can send vlan-tagged packets from a different system and they are received in the VMs just fine. However, if we try to send vlan-tagged packets from one VF to the other it appears that the hardware is stripping the VLAN tag information and not passing it through to the other VF. Hello Chris, We are a bit resource constrained on this particular topic. I will need to do some research and work on a repro in order to have some advice for you. Thanks for your patience, No problem, I know it goes. Any assistance you can provide would be appreciated. Worst case I may end up patching the driver to disable hardware VLAN tag stripping. Chris -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel#174; Ethernet, visit http://communities.intel.com/community/wired
