Re: [net-next-2.6 PATCH] infiniband: convert to use netdev_for_each_mc_addr

2010-02-25 Thread Jiri Pirko
Thu, Feb 25, 2010 at 09:00:07AM CET, ogerl...@voltaire.com wrote:
Jiri Pirko wrote:
 --- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
 +++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
 @@ -767,11 +767,8 @@ void ipoib_mcast_dev_flush(struct net_device *dev)
 -static int ipoib_mcast_addr_is_valid(const u8 *addr, unsigned int addrlen,
 - const u8 *broadcast)
 +static int ipoib_mcast_addr_is_valid(const u8 *addr, const u8 *broadcast)
  {
 -if (addrlen != INFINIBAND_ALEN)
 -return 0;

This check was added by commit 5e47596b IPoIB: Check multicast address 
format, may I ask what is the reason for removing it now?

Yes, at this very moment the check is not needless but it will be in a brief
future. dev_mc_add will look very similar like dev_unicast_add. But ok. Here's
patch adding the check in dev_mc_add right now to correct this state. Thanks Or.

Subject: [net-next-2.6 PATCH] net: add addr len check to dev_mc_add

Signed-off-by: Jiri Pirko jpi...@redhat.com

diff --git a/net/core/dev_mcast.c b/net/core/dev_mcast.c
index 9e2fa39..fd91569 100644
--- a/net/core/dev_mcast.c
+++ b/net/core/dev_mcast.c
@@ -96,6 +96,8 @@ int dev_mc_add(struct net_device *dev, void *addr, int alen, 
int glbl)
int err;
 
netif_addr_lock_bh(dev);
+   if (alen != dev-addr_len)
+   return -EINVAL;
err = __dev_addr_add(dev-mc_list, dev-mc_count, addr, alen, glbl);
if (!err)
__dev_set_rx_mode(dev);
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[ANNOUNCE] OFED 1.5.1 rc2 release is available

2010-02-25 Thread Tziporet Koren
OFED 1.5.1-rc2 is available

Notes:

The tarball is available on:
http://www.openfabrics.org/downloads/OFED/ofed-1.5.1/OFED-1.5.1-rc2.tgz



To get BUILD_ID run ofed_info

Please report any issues in bugzilla https://bugs.openfabrics.org/ for OFED 
1.5.1

Vladimir  Tziporet


Supported Platforms and Operating Systems
-
o   CPU architectures:
  - x86_64
  - x86
  - ppc64
  - ia64

o   Linux Operating Systems:
  - RedHat EL4 up72.6.9-78.ELsmp
  - RedHat EL4 up82.6.9-89.ELsmp
  - RedHat EL5 up32.6.18-128.el5
  - RedHat EL5 up42.6.18-164.el5
  - SLES10 SP22.6.16.60-0.21-smp
  - SLES10 SP32.6.16.60-0.54-smp
  - SLES112.6.27.19-5-default
  - OEL 4 up7 2.6.9-78.ELsmp
  - OEL 4 up8 2.6.9-89.ELsmp
  - CentOS5.3 2.6.18-128.el5
  - CentOS5.4 2.6.18-164.el5
  - Fedora Core12 2.6.31.5-127.fc12*
  - OpenSuSE 11.2 2.6.31.5-0.1-default *
  - kernel.org2.6.29, 2.6.30,
  2.6.31 and 2.6.32*

* Minimal QA for these versions

Main changes from 1.5.1-rc1:
===
1. Updated packages:
- DAPL (compat-dapl-1.2.16, dapl-2.0.27)
- ibutils: ibutils-1.5.2
- ib-bonding: ib-bonding-0.9.0-42
- libnes: libnes-1.0.0-0.1.g9b5f558
- libsdp: libsdp-1.1.100-0.1.g920ea31
- management: updated to the latest build
- iSER: Added RHEL5.4 support   
- MPI:
  mvapich-1.2.0-3635
  mvapich2-1.4-3.20100222svn3774
2. Bug fixes





commit bb30f640fd973d48686e1663afbab67b23fa1c09
Merge: 03a9f17 329fbc0
Author: Vladimir Sokolovsky v...@mellanox.co.il
Date:   Wed Feb 24 08:47:38 2010 +0200

Merge branch 'code-drop/20100223' of 
git://git.openfabrics.org/~agrover/ofed_1_5/linux-2.6 into ofed_kernel_1_5

commit 03a9f17215dde8a49c8da22be88a8e1dc69ba754
Merge: cff66e5 19d717c
Author: Vladimir Sokolovsky v...@mellanox.co.il
Date:   Wed Feb 24 08:40:15 2010 +0200

Merge branch 'ofed_kernel_1_5' of 
ssh://sofa.openfabrics.org/home/ctung/scm/ofed-1.5 into ofed_kernel_1_5

commit 329fbc005ecf6307377158aec7a7ce54c70777a9
Author: Tina Yang tina.y...@oracle.com
Date:   Fri Feb 19 16:53:00 2010 -0800

RDS: Fix locking in rds_send_drop_to()

Signed-off-by: Tina Yang tina.y...@oracle.com
Signed-off-by: Andy Grover andy.gro...@oracle.com

commit 02955868562b143e4f81929275793bfa6c5b0ce7
Author: Andy Grover andy.gro...@oracle.com
Date:   Tue Feb 16 15:41:15 2010 -0800

RDS: Turn down alarming reconnect messages

RDS's error messages when a connection goes down are a little
extreme. A connection may go down, and it will be re-established,
and everything is fine. This patch links these messages through
rdsdebug(), instead of to printk directly.

Signed-off-by: Andy Grover andy.gro...@oracle.com

commit 3e7b1a2efceab7a4090fe8cbf5b8c2e2c67e7529
Author: Andy Grover andy.gro...@oracle.com
Date:   Tue Feb 16 13:54:12 2010 -0800

RDS: Workaround for in-use MRs on close causing crash

if a machine is shut down without closing sockets properly, and
freeing all MRs, then a BUG_ON will bring it down. This patch
changes these to WARN_ONs -- leaking MRs is not fatal (although
not ideal, and there is more work to do here for a proper fix.)

Signed-off-by: Andy Grover andy.gro...@oracle.com

commit 19d717c18ee40ca830bfed01839913329c548ed1
Author: Chien Tung chien.tin.t...@intel.com
Date:   Tue Feb 23 12:20:54 2010 -0600

RDMA/nes: add kernel_patches/fixes/nes_0027_kr.patch

add support for KR device id 0x0110.
nes_init_phy clean up.
Deprecate NES_PHY_TYPE_IRIS.

Signed-off-by: Chien Tung chien.tin.t...@intel.com

commit cff66e5d6f3cb6dbd3ae68b7cbfd017a89833fa5
Merge: 464df47 51dbf00
Author: Vladimir Sokolovsky v...@mellanox.co.il
Date:   Tue Feb 23 17:38:33 2010 +0200

Merge remote branch 'amirv/ofed_kernel_1_5' into ofed_kernel_1_5

commit 51dbf00d8b656eaa89b95db86faa42f2106109c8
Author: Amir Vadai am...@mellanox.co.il
Date:   Tue Feb 23 10:02:59 2010 +0200

sdp: Prevent kernel crash if device init fails (plus bonus fix)

If sdp_add_device() fails, there is no client data stored in the IB device,
leading to a kernel crash when a connection is being established. Fix this
by rejecting connections when the device is not initialized.

Also, fix a bad goto target in an error case early in sdp_init_qp().

Signed-off-by: Joachim Fenkes fen...@de.ibm.com
Signed-off-by: Amir Vadai am...@mellanox.co.il

commit 464df477da4cb5996fdc39b95340b63797ed210b
Author: Eli Cohen e...@mellanox.co.il
Date:   Tue Feb 23 14:23:55 

Re: Oops in iscsi_conn_failure()

2010-02-25 Thread Roman Kononov

On 2010-02-25 02:06 Or Gerlitz said the following:
Can you elaborate what does it take to reproduce that? 


I am not sure. I am writing custom scripts for a Linux cluster of iSCSI 
targets and initiators. I start and kill (including SIGKILL) iscsid, 
start and kill (including SIGKILL), add and remove targets using tgtadm, 
login and logout using iscsi_adm in some [random] order. Everything is 
done from the user space.


Thanks.

Roman
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: link width question / opensm

2010-02-25 Thread Dries Kimpe

* Hal Rosenstock hal.rosenst...@gmail.com [2010-02-25 09:45:04]:

 The link won't renegotiate automatically. The link needs to be reset
 after updating the speed/width enabled values. Was that done ?

I assumed OpenSM was resetting the link. Are you saying I need to run
ibportstate reset in addition to running a modified opensm?
(Or, using only ibportstate using ibportstate speed followed by a
ibportstate reset?)

  - Is there another way to get what I want (control over link width+speed)?

 The latest ibportstate can do this.

I installed the latest version, and it indeed has width and speed.
However, it doesn't seem to have any effect:


[dki...@f28]~% sudo /usr/sbin/ibportstate 232 1 query
PortInfo:
# Port info: Lid 232 port 1
LinkState:...Active
PhysLinkState:...LinkUp
LinkWidthSupported:..1X or 4X
LinkWidthEnabled:1X or 4X
LinkWidthActive:.4X
LinkSpeedSupported:..2.5 Gbps or 5.0 Gbps or 10.0 Gbps
LinkSpeedEnabled:2.5 Gbps or 5.0 Gbps or 10.0 Gbps
LinkSpeedActive:.10.0 Gbps

[dki...@f28]~% sudo /usr/sbin/ibportstate 232 1 speed 1
Initial PortInfo:
# Port info: Lid 232 port 1
LinkSpeedEnabled:2.5 Gbps or 5.0 Gbps or 10.0 Gbps

After PortInfo set:
# Port info: Lid 232 port 1
LinkSpeedEnabled:2.5 Gbps
[dki...@f28]~% sudo /usr/sbin/ibportstate 232 1 query  
PortInfo:
# Port info: Lid 232 port 1
LinkState:...Active
PhysLinkState:...LinkUp
LinkWidthSupported:..1X or 4X
LinkWidthEnabled:1X or 4X
LinkWidthActive:.4X
LinkSpeedSupported:..2.5 Gbps or 5.0 Gbps or 10.0 Gbps
LinkSpeedEnabled:2.5 Gbps
LinkSpeedActive:.10.0 Gbps

[dki...@f28]~% sudo /usr/sbin/ibportstate 232 1 reset
ibportstate: iberror: failed: smp query nodeinfo: Node type not switch


  Thanks,
  Dries


pgpmlcOhhKkab.pgp
Description: PGP signature


RE: [PATCH] RDMA/nes: add support for KR device id 0x0110

2010-02-25 Thread Tung, Chien Tin
  Iris is an XFP card.  NetEffect didn't make that many and maybe a few
  were given out as evals.  The biggest reason for removing the support
  is I don't have a card to test code changes.  There are other cards that
  I am supporting even though we no longer make them as Intel.  I will
  keep those around as long as I have cards, in a secret hiding place. :-)

OK, if you're comfortable that no one is still using such cards then
it's fine with me to remove the support.

Thanks.

Chien


--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] IB/ipoib: fix dangling pointer references to ipoib_neigh and ipoib_path

2010-02-25 Thread Arthur Kepner
On Thu, Feb 25, 2010 at 11:29:02AM -0800, Ralph Campbell wrote:
  

I haven't looked carefully at the whole patch, but this bit 
looks wrong:

 @@ -848,61 +823,112 @@ static void ipoib_neigh_cleanup(struct neighbour *n)
   struct ipoib_neigh *neigh;
   struct ipoib_dev_priv *priv = netdev_priv(n-dev);
   unsigned long flags;
 - struct ipoib_ah *ah = NULL;
 +
 + spin_lock_irqsave(priv-lock, flags);
  
   neigh = *to_ipoib_neigh(n);
 - if (neigh)
 - priv = netdev_priv(neigh-dev);
 - else
 + if (neigh) {

Should this be if (!neigh) ?

 + spin_unlock_irqrestore(priv-lock, flags);
   return;
 + }
 + *to_ipoib_neigh(n) = NULL;
 + neigh-neighbour = NULL;
 +

-- 
Arthur

--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: The SRP initiator and the endianness of tags in SRP information units

2010-02-25 Thread Roland Dreier
  I have a question about the SRP initiator available in the Linux
  kernel. While consulting the SRP spec (r16a) I noticed that all
  multi-byte integer fields of SRP information units must be sent using
  the big endian byte order. This holds e.g. for the 64-bit tag fields
  present in several information units. So I was expecting these tags to
  be declared as __be64. However, in the header file scsi/srp.h these
  tags are declared as type u64, that is, being stored in CPU order. As
  a result, the byte order of the tags sent by the SRP initiator will
  depend on the endianness of the CPU the SRP initiator is running on
  (e.g. little endian on Intel CPU's, big endian on PowerPC CPU's).
  While this doesn't harm -- an SRP target must send back the same tag
  it received -- I found this confusing. Is this the intended behavior
  of the SRP initiator ?

Didn't reply before... sorry.

Anyway my view is that since tags are just an opaque 64-bit quantity, it
doesn't really make sense to worry about endianness.  You wouldn't
byte-swap a field that was an 8-byte string, and the tag is essentially
the same thing.

 - R.
-- 
Roland Dreier  rola...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add new device IDs for ConnectX VPI HCAs

2010-02-25 Thread Eli Cohen
On Wed, Feb 24, 2010 at 02:07:20PM -0800, Roland Dreier wrote:
   +  HCA(MELLANOX, 0x6746),  /* MT26438 ConnectX VPI PCIe 2.0 5GT/s - IB QDR 
 / 10GigE Virt+ */
 
 The kernel calls this device ID MT26438 ConnectX EN 40GigE PCIe gen2
 5GT/s.  Maybe we should just delete these comments, since we can't seem
 to get them right?

I guess it would be best if we take the description from
http://pciids.sourceforge.net/v2.2/pci.ids
 
   +  HCA(MELLANOX, 0x6778),  /* MT26488 ConnectX VPI PCIe 2.0 5GT/s - IB DDR 
 / 10GigE Virt+ */
 
 Are we missing a kernel patch?  I don't see this device ID in the kernel
 driver.

Looks like it is missing.

If we agree on this, we'll send two patches - one for kernel and one
for libmlx4 to sync all device IDs with descriptions from the
mentioned url.


--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] Add new device IDs for ConnectX VPI HCAs

2010-02-25 Thread Roland Dreier
   The kernel calls this device ID MT26438 ConnectX EN 40GigE PCIe gen2
   5GT/s.  Maybe we should just delete these comments, since we can't seem
   to get them right?
  
  I guess it would be best if we take the description from
  http://pciids.sourceforge.net/v2.2/pci.ids

I wonder whether it's really worth having the text at all.  Maybe it's a
bit useful, I'm not sure.  But the pciids text could probably use some
cleaning up, eg:

634a  MT25418 [ConnectX VPI PCIe 2.0 2.5GT/s - IB DDR / 10GigE]
6368  MT25448 [ConnectX EN 10GigE, PCIe 2.0 2.5GT/s]

it would be nice to decide on a standard order of whether the PCIe or
the network info comes first.

And then to make things even better we have:

103c 3313  HP NC542m Dual Port Flex-10 10GbE BLc Adapter

so we can't even decide on 10GigE vs. 10GbE.

But yeah, patches to get the ID list into shape with at least the right
list of device IDs for kernel and userspace would be welcome.
-- 
Roland Dreier  rola...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH V2 2/2] mlx4/IB: Add support for enhanced atomic operations

2010-02-25 Thread Roland Dreier
  | atomic_response = *va
  | if (((cmp XOR *va) AND cmp_mask) is ZERO) then
  | *va = (*va AND NOT(swap_mask)) OR (swap AND swap_mask)
  |
  | return atomic_response

This is a great, terse description of the masked compare and swap
operation.  Do you think it would be more readable with C operations (ie
^ for XOR,  for AND, ~ for NOT, and | for OR)?  Also, I think it would
be good to use the exact field names as the work request field you add
(ie compare_add and compare_add_mask instead of cmp and cmp_mask).

(And as I said before, this belongs with the generic patch, not the mlx4
patch description)

  Masked Fetch and Add (MFetchAdd)
  The MFetchAdd Atomic operation extends the functionality of the standard IB
  FetchAdd by allowing the user to split the target into multiple fields of
  selectable length. The atomic add is done independently on each one of this
  fields. A bit set in the field_boundary parameter specifies the field
  boundaries. The pseudo code below describes the operation:

This is a bit harder to read, but I guess the operation is harder to
describe.  But what is really missing is the statement that the relevant
fields in the wr are compare_add and compare_add_mask.  Failing that,
it's really hard to know how to use this operation without looking at
the mlx4 source code.

  +props-device_cap_flags |= IB_DEVICE_MASKED_ATOMIC;

Is there no firmware dependency here?  If this really should be set
unconditionally, then please just roll it into the other flags that get
set for all devices.
-- 
Roland Dreier  rola...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--
To unsubscribe from this list: send the line unsubscribe linux-rdma in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


linux-next: manual merge of the infiniband tree with the vfs tree

2010-02-25 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the infiniband tree got a conflict in
drivers/infiniband/core/uverbs_main.c between commit
ce916e2b935f8b3402da1457ff23b9f9f786c09b (switch infiniband uverbs to
anon_inodes) from the vfs tree and commit
4169c4a9735d6434c9e39fa81ae5517e3afd4cd8 (IB/uverbs: Use anon_inodes
instead of private infinibandeventfs) from the infiniband tree.

These two commits purport to do something similar.  Someone should look
at them both and decide which one is right.  For now I have used the
version from the vfs tree - with the addition of the part from the
infiniband tree version that selects ANON_INODES in the Kconfig file.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgpTYxtornmxT.pgp
Description: PGP signature