Hello John,Attached is a tarball 'igbPnioInfo.tgz' (13824 bytes) that contains five text files:
lspci.txt: Updated lspci info (lspci -vv, -n, and -nn), the previous lspci data was limited because I forgot to run as root.
ethtool.noPromisc: Output from 'ethtool -d' with promiscuous mode disabled. The output from ethtool was captured once a second for approx 15 seconds while the PNIO devices were trying to connect.
ethtool.withPromisc: Output from 'ethtool -d' as promiscuous mode was enabled and the PNIO devices were able to connect. The output from ethtool was captured once a second for approx 20 seconds. Initially, promiscuous mode is not enabled (first 3-5 seconds), then enabled and wait until all connections completed successfully.
netstat.noPromisc: Output from 'netstat -s --raw' with promiscuous mode disabled. The output from netstat was captured once a second for approx 20 seconds while the PNIO devices were trying to connect.
netstat.withPromisc: Output from 'netstat -s --raw' as promiscuous mode was enabled and the PNIO devices were able to connect. The output was captured once a second for approx 20 seconds. Initially, promiscuous mode is not enabled (first 3-5 seconds), then enabled and wait until all connections completed successfully.
Greg Hupf [email protected] Command and Control Technologies www.cctcorp.com 1425 Chaffee Drive, Suite 1 (321) 264-1193 x121 Titusville, Florida 32780 (321) 383-5096 fax On 6/27/2011 12:36 PM, Greg Hupf wrote:
Hello John, Thanks for the reply. The attached file 'lspci.txt' contains the outputs from 'lspci -vv' and 'lspci -nn'. The '-vv' output is first, followed by the vendor and device codes. I'll send the ethtool and netstat next. Thanks, Greg -- Greg Hupf [email protected] Command and Control Technologies www.cctcorp.com 1425 Chaffee Drive, Suite 1 (321) 264-1193 x121 Titusville, Florida 32780 (321) 383-5096 fax On 6/27/2011 12:26 PM, Ronciak, John wrote:OK, please get us the 'lspci -nn' data. The output from the both the ethtool and netstat commands would also help. We just want to see how the HW and stack see these non-ip packets. Thanks. Cheers, John-----Original Message----- From: Greg Hupf [mailto:[email protected]] Sent: Monday, June 27, 2011 9:22 AM To: Ronciak, John Cc: [email protected] Subject: Re: [E1000-devel] Intel(R) Gigabit ET Quad Port Server Adapter does not work with PROFINET Hello John, I ran 'ethtool -S' and 'netstat -s' in an attempt to determine where the packets are being dropped. When the packets are being dropped the ethtool packet counts are less than 10 per second and the netstat packet counts are less than 1 per second. When I enable promiscuous mode the ethtool packet counts increased significantly to almost 100 per second. Initially, when the mode changed, I did see an increase of a dozen or so packets via netstat (probably from the two PNIO devices that were finally able to connect), but there was no change in the steady- state/periodic 'netstat' statistics. Note that the PNIO protocol primarily consists of non-IP packets. This is a private physical network so almost all the traffic is PROFINET related (i.e. other than a few RSTP, MCAST, etc. packets broadcast from the managed switches). Let me know if this is the information you need, or if there is anything else I can do to help further troubleshoot this issue. Thanks, Greg -- Greg Hupf [email protected] Command and Control Technologies www.cctcorp.com 1425 Chaffee Drive, Suite 1 (321) 264-1193 x121 Titusville, Florida 32780 (321) 383-5096 fax On 6/24/2011 7:05 PM, Greg Hupf wrote:Hello John, Thanks for the reply. The device ID is 'E1G44ETBLK' (i.e. Intel Gigabit ET Quad Port Server Adapter E1G44ET with the 82576 controller). We are also having the same problem with the Intel adapters located on the motherboard (with the 82575EB controller). All the packets are received correctly in promiscuous mode. But without promiscuous mode some of the PROFINET packets are dropped (e.g. packets from managed PROFINET switches are received correctly, but packets from PROFINET bus couplers are dropped). We only seem to have this problem with Intel NICs that use the'82575/6'controller and/or the 'igb' driver. We tried to do some investigation using wireshark. I can provide capture files if you think it would be helpful. Otherwise, I'll see if I can determine if it is the HW orthestack that is dropping/filtering the packets. Thanks for the help, I appreciate your cooperation. Thanks, Greg -- Greg Hupf [email protected] Command and Control Technologies www.cctcorp.com 1425 Chaffee Drive, Suite 1 (321) 264-1193 x121 Titusville, Florida 32780 (321) 383-5096 fax On 6/24/2011 4:48 PM, Ronciak, John wrote:Sorry to hear of you issue. We need the exact device ID for theNIC'sto start with. So you are saying that even in promiscuous mode the packets are not received correct? Where are the packets beingdropped?By the HW or by the stack? You can use ethtool and netstat to see where they are being dropped. Let us know about the ID and if you can find where the packets are being dropped. Thanks. Cheers, John-----Original Message----- From: Greg Hupf [mailto:[email protected]] Sent: Friday, June 24, 2011 11:30 AM To: [email protected] Subject: [E1000-devel] Intel(R) Gigabit ET Quad Port Server Adapter does not work with PROFINET Customer_type: Developer/Designer Product: Intel(R) Gigabit ET Quad Port Server Adapter OS: Red Hat Enterprise Linux 5.0* Kernel: linux-2.6.18-128.el5PAE Distribution_Version: Red Hat Enterprise Linux Server release 5.3 (Tikanga) Issue_Other_Versions: Yes Driver_Version: igb-3.0.22 Issue: We recently purchased two 'Intel(R) Gigabit ET Quad Port Svr Adptr' cards for a large industrial control system. The NIC works fine for most ethernet traffic, but rejects certain PROFINET packets. These packets can only be received if 'promiscuous' modeisenabled. The packets that are rejected are less than 200 bytes, but do use the standard PROFINET VLAN field. Other PROFINET packets arereceived fine.The network is private and dedicated to PROFINET traffic. Theserverdoes not need a VLAN configuration. We replaced the card with an older single-port PRO/1000 NIC (i.e. uses the e1000e driver) andtheproblem disappears. Other 3-Com and Broadcom NICs also work correctly. We need to get this driver fixed, or get the cards replaced with PRO/1000 based Quad-port NICs. Let me know if youneed more information.Thanks, Greg -- Greg Hupf [email protected] Command and Control Technologies www.cctcorp.com 1425 Chaffee Drive, Suite 1 (321) 264-1193 x121 Titusville, Florida 32780 (321) 383-5096 fax ----------------------------------------------------------------------- ------- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Commonsense..http://p.sf.net/sfu/splunk-d2d-c1 _______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
igbPnioInfo.tgz
Description: Binary data
------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________ E1000-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
