Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
On 11/28/12 02:10, Ben Hutchings wrote: On Tue, 2012-11-27 at 17:32 +, Fujinaka, Todd wrote: Forgive me if I'm being too repetitious as I think some of this has been mentioned in the past. We (and by we I mean the Ethernet part and driver) can only change the advertised availability of a larger MaxPayloadSize. The size is negotiated by both sides of the link when the link is established. The driver should not change the size of the link as it would be poking at registers outside of its scope and is controlled by the upstream bridge (not us). [...] MaxPayloadSize (MPS) is not negotiated between devices but is programmed by the system firmware (at least for devices present at boot - the kernel may be responsible in case of hotplug). You can use the kernel parameter 'pci=pcie_bus_perf' (or one of several others) to set a policy that overrides this, but no policy will allow setting MPS above the device's MaxPayloadSizeSupported (MPSS). Ben, Unfortunately I'm using 3.0.x kernel and this is not included in the kernel. So I'm trying to use ethtool modify it from eeprom to see if help or no. Todd, I'll review all MaxPayload for all devices, but need to say if it mismatch, customer could not modify it from BIOS for there was not entry at there, to test it, we have to find how to verify if this is the root cause, so still need to find the offset in eeprom. Thanks in advance, Joe -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ 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
[E1000-devel] Connecting only RX for passive monitoring
Hello, we have an X520-SR2 adapter that we are trying to use for passive monitoring. What we want to do is to use an optical splitter and connect the output from this splitter to the RX connectors on the X520-SR2 and leave the TX connectors unconnected. If we try this we are not able to get a link up and I assume this is because the nic is waiting for autoneg? As far as I can tell ethtool does not allow us to turn of autoneg on this adapter, so is there anything else we can try to get this setup to work? Best regards, Arne -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ 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
[E1000-devel] Ethernet driver on top of shared memory
Hi Folks, I have two machines A and B. And I have a shared memory system so A can read/write B's RAM and vice versa. On top of this shared memory system I plan to develop a Ethernet-like driver running on A and B so that each can talk to the other using IP/socket API. There will be no real Ethernet card in my system. At first, this looks like RDMA over Ethernet. However, it's the inverse. The shared memory system acts like RDMA underneath, and the Ethernet-like driver running on top of it. So the TX/RX ring actually becomes just a pie of memory in RAM. Sorry this may not be a directly related question to Intel's Ethernet driver. I hope someone can give me some pointers or related open source projects about this kind of driver. Regards, William Tu Stony Brook University -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ 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
[E1000-devel] [netdev-next:master 1/7] drivers/net/ethernet/intel/igbvf/netdev.c:115:31: sparse: cast to restricted __be16
tree: git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next.git master head: 14a8d4bb5675b5ff854bb2536b0371f3b261136e commit: 2c1a10196511a2c1af612a59aa1e5385afca0533 [1/7] igbvf: work around i350 erratum sparse warnings: + drivers/net/ethernet/intel/igbvf/netdev.c:115:31: sparse: cast to restricted __be16 + drivers/net/ethernet/intel/igbvf/netdev.c:115:31: sparse: cast to restricted __be16 + drivers/net/ethernet/intel/igbvf/netdev.c:115:31: sparse: cast to restricted __be16 + drivers/net/ethernet/intel/igbvf/netdev.c:115:31: sparse: cast to restricted __be16 drivers/net/ethernet/intel/igbvf/netdev.c:117:31: sparse: cast to restricted __le16 drivers/net/ethernet/intel/igbvf/netdev.c:224:48: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:224:48:expected unsigned long long [unsigned] [usertype] pkt_addr drivers/net/ethernet/intel/igbvf/netdev.c:224:48:got restricted __le64 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:226:48: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:226:48:expected unsigned long long [unsigned] [usertype] hdr_addr drivers/net/ethernet/intel/igbvf/netdev.c:226:48:got restricted __le64 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:228:48: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:228:48:expected unsigned long long [unsigned] [usertype] pkt_addr drivers/net/ethernet/intel/igbvf/netdev.c:228:48:got restricted __le64 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:280:19: sparse: cast to restricted __le32 drivers/net/ethernet/intel/igbvf/netdev.c:295:25: sparse: cast to restricted __le16 drivers/net/ethernet/intel/igbvf/netdev.c:300:26: sparse: cast to restricted __le16 drivers/net/ethernet/intel/igbvf/netdev.c:388:27: sparse: cast to restricted __le32 drivers/net/ethernet/intel/igbvf/netdev.c:807:39: sparse: restricted __le32 degrades to integer drivers/net/ethernet/intel/igbvf/netdev.c:1948:39: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:1948:39:expected unsigned int [unsigned] [usertype] vlan_macip_lens drivers/net/ethernet/intel/igbvf/netdev.c:1948:39:got restricted __le32 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:1957:39: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:1957:39:expected unsigned int [unsigned] [usertype] type_tucmd_mlhl drivers/net/ethernet/intel/igbvf/netdev.c:1957:39:got restricted __le32 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:1963:37: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:1963:37:expected unsigned int [unsigned] [usertype] mss_l4len_idx drivers/net/ethernet/intel/igbvf/netdev.c:1963:37:got restricted __le32 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:2002:47: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:2002:47:expected unsigned int [unsigned] [usertype] vlan_macip_lens drivers/net/ethernet/intel/igbvf/netdev.c:2002:47:got restricted __le32 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:2022:47: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:2022:47:expected unsigned int [unsigned] [usertype] type_tucmd_mlhl drivers/net/ethernet/intel/igbvf/netdev.c:2022:47:got restricted __le32 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:2179:43: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:2179:43:expected unsigned long long [unsigned] [usertype] buffer_addr drivers/net/ethernet/intel/igbvf/netdev.c:2179:43:got restricted __le64 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:2180:44: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:2180:44:expected unsigned int [unsigned] [usertype] cmd_type_len drivers/net/ethernet/intel/igbvf/netdev.c:2180:44:got restricted __le32 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:2182:45: sparse: incorrect type in assignment (different base types) drivers/net/ethernet/intel/igbvf/netdev.c:2182:45:expected unsigned int [unsigned] [usertype] olinfo_status drivers/net/ethernet/intel/igbvf/netdev.c:2182:45:got restricted __le32 [usertype] noident drivers/net/ethernet/intel/igbvf/netdev.c:2188:36: sparse: invalid assignment: |= drivers/net/ethernet/intel/igbvf/netdev.c:2188:36:left side has type unsigned int drivers/net/ethernet/intel/igbvf/netdev.c:2188:36:right side has type restricted __le32 vim +115 drivers/net/ethernet/intel/igbvf/netdev.c d4e0fe01 drivers/net/igbvf/netdev.c
Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang
The only EEPROM I know about or can speak to is the one attached to the 82571 and it doesn't set the MaxPayloadSize. That's done by the BIOS. Todd Fujinaka Technical Marketing Engineer LAN Access Division (LAD) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -Original Message- From: Joe Jin [mailto:joe@oracle.com] Sent: Wednesday, November 28, 2012 12:31 AM To: Ben Hutchings Cc: Fujinaka, Todd; Mary Mcgrath; net...@vger.kernel.org; e1000-de...@lists.sf.net; linux-ker...@vger.kernel.org; linux-pci Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang On 11/28/12 02:10, Ben Hutchings wrote: On Tue, 2012-11-27 at 17:32 +, Fujinaka, Todd wrote: Forgive me if I'm being too repetitious as I think some of this has been mentioned in the past. We (and by we I mean the Ethernet part and driver) can only change the advertised availability of a larger MaxPayloadSize. The size is negotiated by both sides of the link when the link is established. The driver should not change the size of the link as it would be poking at registers outside of its scope and is controlled by the upstream bridge (not us). [...] MaxPayloadSize (MPS) is not negotiated between devices but is programmed by the system firmware (at least for devices present at boot - the kernel may be responsible in case of hotplug). You can use the kernel parameter 'pci=pcie_bus_perf' (or one of several others) to set a policy that overrides this, but no policy will allow setting MPS above the device's MaxPayloadSizeSupported (MPSS). Ben, Unfortunately I'm using 3.0.x kernel and this is not included in the kernel. So I'm trying to use ethtool modify it from eeprom to see if help or no. Todd, I'll review all MaxPayload for all devices, but need to say if it mismatch, customer could not modify it from BIOS for there was not entry at there, to test it, we have to find how to verify if this is the root cause, so still need to find the offset in eeprom. Thanks in advance, Joe -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ 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] ixgbe with X520-DA2 problem
Thanks, also can you please confirm that the module is the Juniper SKU? Stephen -Original Message- From: Paweł Gołaszewski [mailto:bl...@gda.pl] Sent: Tuesday, November 27, 2012 10:16 PM To: Ko, Stephen S Cc: 'e1000-devel@lists.sourceforge.net' Subject: RE: [E1000-devel] ixgbe with X520-DA2 problem On Tue, 27 Nov 2012, Ko, Stephen S wrote: We may be able to take a look. Could you please double check your module model? We could not find any data on SP-SM31010-GB (only -GP came up.) yep, my fault: GBC Photonics SP-SM31010-GP -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ 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
[E1000-devel] Fwd: Your Photos
Hello, your photoshttp://up.busanilbo.com/upload.htm -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ 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] ixgbe with X520-DA2 problem
On Wed, 28 Nov 2012, Ko, Stephen S wrote: We may be able to take a look. Could you please double check your module model? We could not find any data on SP-SM31010-GB (only -GP came up.) yep, my fault: GBC Photonics SP-SM31010-GP Thanks, also can you please confirm that the module is the Juniper SKU? Yes, the module is Juniper-compatible. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.-- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net___ 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
[E1000-devel] Ethernet driver on top of shared memory
-Original Message- From: William Tu [mailto:u9012...@gmail.com] Sent: Wednesday, November 28, 2012 6:02 AM To: e1000-devel@lists.sourceforge.net Subject: [E1000-devel] Ethernet driver on top of shared memory Hi Folks, I have two machines A and B. And I have a shared memory system so A can read/write B's RAM and vice versa. On top of this shared memory system I plan to develop a Ethernet-like driver running on A and B so that each can talk to the other using IP/socket API. There will be no real Ethernet card in my system. At first, this looks like RDMA over Ethernet. However, it's the inverse. The shared memory system acts like RDMA underneath, and the Ethernet-like driver running on top of it. So the TX/RX ring actually becomes just a pie of memory in RAM. Sorry this may not be a directly related question to Intel's Ethernet driver. I hope someone can give me some pointers or related open source projects about this kind of driver. If you want to do a little bit of hacking you can probably modify the NTB driver I have submitted to Linux for your usage. NTB is a PCI-E Non-transparent bridge, which communicates with a remote system via mirroring writes to MMIO windows into a predefined memory space on the remote system. This could be modified to suit your needs by faking out the NTB hardware. You could then use the existing NTB Transport layer and NTB virtual ethernet device on top of your NTB-shared mem code. Thanks, Jon Regards, William Tu Stony Brook University -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ 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 -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ 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
Joe, Possibly your customer is running a kernel without source code on a platform whose vendor wouldn't like to fix BIOS issue( Is that a HP/Dell server ?). Anyway, to see if is a payload issue or, you could change the payload size with setpci tool to those devices and set the link retrain bit to trigger the link retraining to debug the issue and identity the root cause. I thinks it is much easier than modify the BIOS or eeprom of NIC. e.g. set device control register to 0f 00 (128 bytes payload size) # setpci -v -s 00:02.0 98.w=000f set device link control register to 60h (retrain the link) # setpci -v -s 00:02.0 a0.b=60 Hope it works, Just my 2 cents. ethan.z...@oracle.com On Wed, Nov 28, 2012 at 11:53 PM, Fujinaka, Todd todd.fujin...@intel.com wrote: The only EEPROM I know about or can speak to is the one attached to the 82571 and it doesn't set the MaxPayloadSize. That's done by the BIOS. Todd Fujinaka Technical Marketing Engineer LAN Access Division (LAD) Intel Corporation todd.fujin...@intel.com (503) 712-4565 -Original Message- From: Joe Jin [mailto:joe@oracle.com] Sent: Wednesday, November 28, 2012 12:31 AM To: Ben Hutchings Cc: Fujinaka, Todd; Mary Mcgrath; net...@vger.kernel.org; e1000-de...@lists.sf.net; linux-ker...@vger.kernel.org; linux-pci Subject: Re: [E1000-devel] 82571EB: Detected Hardware Unit Hang On 11/28/12 02:10, Ben Hutchings wrote: On Tue, 2012-11-27 at 17:32 +, Fujinaka, Todd wrote: Forgive me if I'm being too repetitious as I think some of this has been mentioned in the past. We (and by we I mean the Ethernet part and driver) can only change the advertised availability of a larger MaxPayloadSize. The size is negotiated by both sides of the link when the link is established. The driver should not change the size of the link as it would be poking at registers outside of its scope and is controlled by the upstream bridge (not us). [...] MaxPayloadSize (MPS) is not negotiated between devices but is programmed by the system firmware (at least for devices present at boot - the kernel may be responsible in case of hotplug). You can use the kernel parameter 'pci=pcie_bus_perf' (or one of several others) to set a policy that overrides this, but no policy will allow setting MPS above the device's MaxPayloadSizeSupported (MPSS). Ben, Unfortunately I'm using 3.0.x kernel and this is not included in the kernel. So I'm trying to use ethtool modify it from eeprom to see if help or no. Todd, I'll review all MaxPayload for all devices, but need to say if it mismatch, customer could not modify it from BIOS for there was not entry at there, to test it, we have to find how to verify if this is the root cause, so still need to find the offset in eeprom. Thanks in advance, Joe -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ 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] ixgbe with X520-DA2 problem
The module's 10GBASE-LR, can you make sure the link partner is also LR and connected w/ single mode fiber cable? We are wondering if the other modules worked because they were SR. -Original Message- From: Paweł Gołaszewski [mailto:bl...@gda.pl] Sent: Wednesday, November 28, 2012 12:09 PM To: Ko, Stephen S Cc: 'e1000-devel@lists.sourceforge.net' Subject: RE: [E1000-devel] ixgbe with X520-DA2 problem On Wed, 28 Nov 2012, Ko, Stephen S wrote: We may be able to take a look. Could you please double check your module model? We could not find any data on SP-SM31010-GB (only -GP came up.) yep, my fault: GBC Photonics SP-SM31010-GP Thanks, also can you please confirm that the module is the Juniper SKU? Yes, the module is Juniper-compatible. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free. -- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net ___ 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] ixgbe with X520-DA2 problem
On Thu, 29 Nov 2012, Ko, Stephen S wrote: We may be able to take a look. Could you please double check your module model? We could not find any data on SP-SM31010-GB (only -GP came up.) yep, my fault: GBC Photonics SP-SM31010-GP Thanks, also can you please confirm that the module is the Juniper SKU? Yes, the module is Juniper-compatible. The module's 10GBASE-LR, can you make sure the link partner is also LR and connected w/ single mode fiber cable? Yes, I'm pretty sure :) We are wondering if the other modules worked because they were SR. You mean LR? It also came to my mind but I don't think so. I have these modules working in distances 10m (this particular link is 15m long). Anyway - before my initial report I tried to add 5, 10 and 15dB attenuator. There was no change. If I have flapping:: [147097.691968] ixgbe :07:00.0: eth2: Reset adapter I can unplug fiber cable - the reseting still occurs. -- pozdr. Paweł Gołaszewski jid:bluesatjabberdotgdadotpl -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Pro-Logic Surround Sound with Bass Boost and all the music is free.-- Keep yourself connected to Go Parallel: VERIFY Test and improve your parallel project with help from experts and peers. http://goparallel.sourceforge.net___ 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
