Re: [openib-general] [PATCH] IB/ipoib: Fix ipoib handling for pkey reordering
On 2/19/07, Moni Levy <[EMAIL PROTECTED]> wrote:
> This issue was found during partitioning & SM fail over testing. The fix was
> tested for 24
> hours with pkey reshuffling every few seconds. The patch applies to Roland's
> master
> branch.
I found an issue with that patch, I'll post an updated one soon.
-- Moni
>
> SM reconfiguration or failover possibly causes a shuffling of the values in
> the port pkey
> table. The current implementation only queries for the index of the pkey
> once, when it
> creates the device QP and after that moves it into working state, and hence
> does not
> address this scenario. Fix this by using the PKEY_CHANGE event as a trigger to
> reconfigure the device QP.
>
> Signed-off-by: Moni Levy <[EMAIL PROTECTED]>
> ---
> ipoib.h |2 ++
> ipoib_ib.c| 22 --
> ipoib_main.c |1 +
> ipoib_verbs.c |4 +++-
> 4 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h
> b/drivers/infiniband/ulp/ipoib/ipoib.h
> index 07deee8..ed854e8 100644
> --- a/drivers/infiniband/ulp/ipoib/ipoib.h
> +++ b/drivers/infiniband/ulp/ipoib/ipoib.h
> @@ -139,6 +139,7 @@ struct ipoib_dev_priv {
> struct delayed_work pkey_task;
> struct delayed_work mcast_task;
> struct work_struct flush_task;
> + struct work_struct flush_restart_qp_task;
> struct work_struct restart_task;
> struct delayed_work ah_reap_task;
>
> @@ -261,6 +262,7 @@ struct ipoib_dev_priv *ipoib_intf_alloc(
>
> int ipoib_ib_dev_init(struct net_device *dev, struct ib_device *ca, int
> port);
> void ipoib_ib_dev_flush(struct work_struct *work);
> +void ipoib_ib_dev_flush_restart_qp(struct work_struct *work);
> void ipoib_ib_dev_cleanup(struct net_device *dev);
>
> int ipoib_ib_dev_open(struct net_device *dev);
> diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
> b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
> index 59d9594..5e2ada9 100644
> --- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
> @@ -611,7 +611,7 @@ int ipoib_ib_dev_init(struct net_device
> return 0;
> }
>
> -void ipoib_ib_dev_flush(struct work_struct *work)
> +static void __ipoib_ib_dev_flush(struct work_struct *work, int restart_qp)
> {
> struct ipoib_dev_priv *cpriv, *priv =
> container_of(work, struct ipoib_dev_priv, flush_task);
> @@ -630,6 +630,12 @@ void ipoib_ib_dev_flush(struct work_stru
> ipoib_dbg(priv, "flushing\n");
>
> ipoib_ib_dev_down(dev, 0);
> +
> + if (restart_qp) {
> + ipoib_dbg(priv, "restarting the device QP\n");
> + ipoib_ib_dev_stop(dev);
> + ipoib_ib_dev_open(dev);
> + }
>
> /*
> * The device could have been brought down between the start and when
> @@ -644,11 +650,23 @@ void ipoib_ib_dev_flush(struct work_stru
>
> /* Flush any child interfaces too */
> list_for_each_entry(cpriv, &priv->child_intfs, list)
> - ipoib_ib_dev_flush(&cpriv->flush_task);
> + __ipoib_ib_dev_flush(&cpriv->flush_task, restart_qp);
>
> mutex_unlock(&priv->vlan_mutex);
> }
>
> +void ipoib_ib_dev_flush(struct work_struct *work)
> +{
> + /* We only restart the QP in case of PKEY change event */
> + __ipoib_ib_dev_flush(work, 0);
> +}
> +
> +void ipoib_ib_dev_flush_restart_qp(struct work_struct *work)
> +{
> + /* We only restart the QP in case of PKEY change event */
> + __ipoib_ib_dev_flush(work, 1);
> +}
> +
> void ipoib_ib_dev_cleanup(struct net_device *dev)
> {
> struct ipoib_dev_priv *priv = netdev_priv(dev);
> diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
> b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> index 705eb1d..da46b79 100644
> --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
> @@ -942,6 +942,7 @@ static void ipoib_setup(struct net_devic
> INIT_DELAYED_WORK(&priv->pkey_task,ipoib_pkey_poll);
> INIT_DELAYED_WORK(&priv->mcast_task, ipoib_mcast_join_task);
> INIT_WORK(&priv->flush_task, ipoib_ib_dev_flush);
> + INIT_WORK(&priv->flush_restart_qp_task,
> ipoib_ib_dev_flush_restart_qp);
> INIT_WORK(&priv->restart_task, ipoib_mcast_restart_task);
> INIT_DELAYED_WORK(&priv->ah_reap_task, ipoib_reap_ah);
> }
> diff --git a/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
> b/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
> index 7b717c6..c249915 100644
> --- a/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
> @@ -252,12 +252,14 @@ void ipoib_event(struct ib_event_handler
> container_of(handler, struct ipoib_dev_priv, event_handler);
>
> if (record->event == IB_EVENT_PORT_ERR||
> - record->event == IB_EVENT_PKEY_CHANGE ||
> record->event == IB_EVENT_PORT_ACTIVE ||
> record->event ==
Re: [openib-general] [2.6 patch] infiniband/hw/mthca/mthca_mr.c: make 2 functions static
Queued for my next merge, thanks. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] uDAPL: RDMA Write example
Christian, dtest is a simple dapl test with snd/rcv and rdma write/read examples. http://www.openfabrics.org/git/?p=~ardavis/dapl.git;a=blob;f=test/dtest/ dtest.c -arlin ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [2.6 patch] infiniband/hw/mthca/mthca_mr.c: make 2 functions static
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/mthca/mthca_mr.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
--- linux-2.6.20-mm1/drivers/infiniband/hw/mthca/mthca_mr.c.old 2007-02-17
17:41:39.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/mthca/mthca_mr.c 2007-02-17
17:42:22.0 +0100
@@ -310,8 +310,9 @@
return mthca_is_memfree(dev) ? (PAGE_SIZE / sizeof (u64)) : 0x7ff;
}
-void mthca_tavor_write_mtt_seg(struct mthca_dev *dev, struct mthca_mtt *mtt,
- int start_index, u64 *buffer_list, int list_len)
+static void mthca_tavor_write_mtt_seg(struct mthca_dev *dev,
+ struct mthca_mtt *mtt, int start_index,
+ u64 *buffer_list, int list_len)
{
u64 __iomem *mtts;
int i;
@@ -323,8 +324,9 @@
mtts + i);
}
-void mthca_arbel_write_mtt_seg(struct mthca_dev *dev, struct mthca_mtt *mtt,
- int start_index, u64 *buffer_list, int list_len)
+static void mthca_arbel_write_mtt_seg(struct mthca_dev *dev,
+ struct mthca_mtt *mtt, int start_index,
+ u64 *buffer_list, int list_len)
{
__be64 *mtts;
dma_addr_t dma_handle;
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [2.6 patch] drivers/infiniband/hw/cxgb3/: possible cleanups
This patch contains the following possible cleanups:
- don't mark static functions in C files as inline - gcc should know
best whether inlining makes sense
- never compile the unused cxio_dbg.c
- make the following needlessly global functions static:
- cxio_hal.c: cxio_hal_clear_qp_ctx()
- iwch_provider.c: iwch_get_qp()
- #if 0 the following unused global functions:
- cxio_hal.c: cxio_allocate_stag()
- cxio_resource.: cxio_hal_get_rhdl()
- cxio_resource.: cxio_hal_put_rhdl()
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/cxgb3/Makefile|1
drivers/infiniband/hw/cxgb3/cxio_hal.c | 22 +++
drivers/infiniband/hw/cxgb3/cxio_hal.h |5 ---
drivers/infiniband/hw/cxgb3/cxio_resource.c |8 -
drivers/infiniband/hw/cxgb3/iwch_cm.c |5 +--
drivers/infiniband/hw/cxgb3/iwch_provider.c |2 -
drivers/infiniband/hw/cxgb3/iwch_provider.h |1
drivers/infiniband/hw/cxgb3/iwch_qp.c | 29
8 files changed, 33 insertions(+), 40 deletions(-)
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/Makefile.old 2007-02-17
17:21:03.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/Makefile 2007-02-17
17:21:08.0 +0100
@@ -8,5 +8,4 @@
ifdef CONFIG_INFINIBAND_CXGB3_DEBUG
EXTRA_CFLAGS += -DDEBUG
-iw_cxgb3-y += cxio_dbg.o
endif
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/cxio_hal.h.old 2007-02-17
17:22:53.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/cxio_hal.h 2007-02-17
17:25:08.0 +0100
@@ -144,7 +144,6 @@
void cxio_rdev_close(struct cxio_rdev *rdev);
int cxio_hal_cq_op(struct cxio_rdev *rdev, struct t3_cq *cq,
enum t3_cq_opcode op, u32 credit);
-int cxio_hal_clear_qp_ctx(struct cxio_rdev *rdev, u32 qpid);
int cxio_create_cq(struct cxio_rdev *rdev, struct t3_cq *cq);
int cxio_destroy_cq(struct cxio_rdev *rdev, struct t3_cq *cq);
int cxio_resize_cq(struct cxio_rdev *rdev, struct t3_cq *cq);
@@ -155,8 +154,6 @@
int cxio_destroy_qp(struct cxio_rdev *rdev, struct t3_wq *wq,
struct cxio_ucontext *uctx);
int cxio_peek_cq(struct t3_wq *wr, struct t3_cq *cq, int opcode);
-int cxio_allocate_stag(struct cxio_rdev *rdev, u32 * stag, u32 pdid,
- enum tpt_mem_perm perm, u32 * pbl_size, u32 * pbl_addr);
int cxio_register_phys_mem(struct cxio_rdev *rdev, u32 * stag, u32 pdid,
enum tpt_mem_perm perm, u32 zbva, u64 to, u32 len,
u8 page_size, __be64 *pbl, u32 *pbl_size,
@@ -172,8 +169,6 @@
int cxio_rdma_init(struct cxio_rdev *rdev, struct t3_rdma_init_attr *attr);
void cxio_register_ev_cb(cxio_hal_ev_callback_func_t ev_cb);
void cxio_unregister_ev_cb(cxio_hal_ev_callback_func_t ev_cb);
-u32 cxio_hal_get_rhdl(void);
-void cxio_hal_put_rhdl(u32 rhdl);
u32 cxio_hal_get_pdid(struct cxio_hal_resource *rscp);
void cxio_hal_put_pdid(struct cxio_hal_resource *rscp, u32 pdid);
int __init cxio_hal_init(void);
--- linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/cxio_hal.c.old 2007-02-17
17:23:11.0 +0100
+++ linux-2.6.20-mm1/drivers/infiniband/hw/cxgb3/cxio_hal.c 2007-02-17
17:36:40.0 +0100
@@ -46,7 +46,7 @@
static LIST_HEAD(rdev_list);
static cxio_hal_ev_callback_func_t cxio_ev_cb = NULL;
-static inline struct cxio_rdev *cxio_hal_find_rdev_by_name(char *dev_name)
+static struct cxio_rdev *cxio_hal_find_rdev_by_name(char *dev_name)
{
struct cxio_rdev *rdev;
@@ -56,8 +56,7 @@
return NULL;
}
-static inline struct cxio_rdev *cxio_hal_find_rdev_by_t3cdev(struct t3cdev
-*tdev)
+static struct cxio_rdev *cxio_hal_find_rdev_by_t3cdev(struct t3cdev *tdev)
{
struct cxio_rdev *rdev;
@@ -119,7 +118,7 @@
return 0;
}
-static inline int cxio_hal_clear_cq_ctx(struct cxio_rdev *rdev_p, u32 cqid)
+static int cxio_hal_clear_cq_ctx(struct cxio_rdev *rdev_p, u32 cqid)
{
struct rdma_cq_setup setup;
setup.id = cqid;
@@ -131,7 +130,7 @@
return (rdev_p->t3cdev_p->ctl(rdev_p->t3cdev_p, RDMA_CQ_SETUP, &setup));
}
-int cxio_hal_clear_qp_ctx(struct cxio_rdev *rdev_p, u32 qpid)
+static int cxio_hal_clear_qp_ctx(struct cxio_rdev *rdev_p, u32 qpid)
{
u64 sge_cmd;
struct t3_modify_qp_wr *wqe;
@@ -426,7 +425,7 @@
}
}
-static inline int cqe_completes_wr(struct t3_cqe *cqe, struct t3_wq *wq)
+static int cqe_completes_wr(struct t3_cqe *cqe, struct t3_wq *wq)
{
if (CQE_OPCODE(*cqe) == T3_TERMINATE)
return 0;
@@ -761,6 +760,7 @@
return err;
}
+#if 0
/* IN : stag key, pdid, pbl_size
* Out: stag index, actaul pbl_size, and pbl_addr allocated.
*/
@@ -771,6 +771,7 @@
return (__cxio_tpt_op(rdev_p, 0, stag, 0, pdid, TPT_NON_SHARED_MR,
perm, 0, 0ULL, 0, 0, NULL, pbl_size, pbl_addr));
}
+#endif /* 0 */
int cxio_registe
Re: [openib-general] OFA 1.2 tarball creation
Steve Wise wrote: > The ofed_1_2 tree has the 2.6.20 drivers/modules in drivers/infiniband. > They are, I think, the stock 2.6.20 drivers and modules. If there are > fixes to any driver post 2.6.20, then patches get created in > kernel_patches/fixes directory. These are applied as part of the > configuration process when the tree is being built. Look in there to > see if your change is in the form of a patch file. > > So you can't necessarily look at ofed_1_2/drivers/infiniband/core for > the exact code, because it may get modified/patched as part of the > configure done on the kernel tree during build/installation. Note in > addition to patches from kernel_patches/fixes, there are other patches > applied based on the kernel version (backports). Thanks for the information. I found what I'm after in 'merged_sean_rdma_dev_ofed_1_2.patch' -- should have found that on my own. It's good to know this is going into the builds though, that wasn't obvious to me. Andrew ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] OFA 1.2 tarball creation
On Mon, 2007-02-19 at 14:38 -0800, Sean Hefty wrote: > >How exactly is various developers' source code pulled together to create > >the nightly OFA tarballs at www.openfabrics.org/builds (could this be > >put on the wiki somewhere?)? I went looking to see if some of Sean's > >work on RDMA CM had made it into these tarballs, and am not seeing code > >with the patches I'm looking for. > > I do not know how OFED creates their tarballs or manages their source. > > >The exact patch I'm after was 'rdma_cm: allow joins to return a unique > >address'. I remember seeing this patch on the ofed_1_2 branch in Sean's > >rdma-dev git repository about two weeks ago, though I don't see the > >ofed_1_2 branch anymore (the patch does exist on the multicast branch). > > Sean, was this patch supposed to make it to the nightly 1.2 tarballs? > > Assuming that ~vlad/ofed_1_2.git is the OFED kernel tree, then this patch does > not appear to be included. I was asked by OFED to publish an ofed_1_2 branch, > which I did, but I do not know if it was used in constructing the OFED tree. > The patch was intended to go into OFED. > The ofed_1_2 tree has the 2.6.20 drivers/modules in drivers/infiniband. They are, I think, the stock 2.6.20 drivers and modules. If there are fixes to any driver post 2.6.20, then patches get created in kernel_patches/fixes directory. These are applied as part of the configuration process when the tree is being built. Look in there to see if your change is in the form of a patch file. So you can't necessarily look at ofed_1_2/drivers/infiniband/core for the exact code, because it may get modified/patched as part of the configure done on the kernel tree during build/installation. Note in addition to patches from kernel_patches/fixes, there are other patches applied based on the kernel version (backports). Also, Sean: If you have changes that you want in OFED 1.2, you need to explicitly post patches to vlad and cc the group. They don't, by process, go pull your kernel tree to get the latest. This is different from the user libs which they pull each time they create a user package. Vlad/Michael, correct me if I'm wrong here. This all took me some time to understand and perhaps documenting this would help folks... Steve. > - Sean > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] ibutils/ibis: compilation fixes
This adds needed header file inclusions. Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]> --- Those compilation failures was detected during ibutils/ibmgtsim build. ibis/src/ibbbm.h |1 + ibis/src/ibis_gsi_mad_ctrl.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/ibis/src/ibbbm.h b/ibis/src/ibbbm.h index d998179..026a49c 100644 --- a/ibis/src/ibbbm.h +++ b/ibis/src/ibbbm.h @@ -50,6 +50,7 @@ #include #include #include +#include #include #include #include diff --git a/ibis/src/ibis_gsi_mad_ctrl.c b/ibis/src/ibis_gsi_mad_ctrl.c index a147642..3c7ea86 100644 --- a/ibis/src/ibis_gsi_mad_ctrl.c +++ b/ibis/src/ibis_gsi_mad_ctrl.c @@ -48,6 +48,7 @@ #include #include #include +#include #include #include "ibis_gsi_mad_ctrl.h" #include "ibis.h" -- 1.5.0.1.40.gb40d ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] osm/libvendor: compilation fixes
This adds needed header files inclusion to prevent compilation failures. Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]> --- Those compilation failures was detected during ibutils/ibmgtsim build. osm/libvendor/osm_vendor_mlx_sa.c |1 + osm/libvendor/osm_vendor_mlx_sim.c |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/osm/libvendor/osm_vendor_mlx_sa.c b/osm/libvendor/osm_vendor_mlx_sa.c index ab37adb..37fa618 100644 --- a/osm/libvendor/osm_vendor_mlx_sa.c +++ b/osm/libvendor/osm_vendor_mlx_sa.c @@ -43,6 +43,7 @@ #include #include #include +#include #include #include diff --git a/osm/libvendor/osm_vendor_mlx_sim.c b/osm/libvendor/osm_vendor_mlx_sim.c index d3e6eeb..bcd2bdc 100644 --- a/osm/libvendor/osm_vendor_mlx_sim.c +++ b/osm/libvendor/osm_vendor_mlx_sim.c @@ -57,6 +57,7 @@ #include #include #include +#include /* the simulator messages definition */ #include -- 1.5.0.1.40.gb40d ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] complib: thread_pool rework
This reworks complib's thread_pool implementation (used by opensm
dispatcher). Prevents events signaling merges, termination races,
eliminates using of broken cl_atomic stuff, reduces memory allocations
and code complexity.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
osm/complib/cl_async_proc.c |1 -
osm/complib/cl_dispatcher.c |2 +-
osm/complib/cl_thread.c | 13 --
osm/complib/cl_threadpool.c | 208 +++---
osm/complib/libosmcomp.map |1 -
osm/include/complib/cl_thread.h | 16 ---
osm/include/complib/cl_threadpool.h | 84 --
osm/osmtest/osmt_multicast.c|1 +
8 files changed, 92 insertions(+), 234 deletions(-)
diff --git a/osm/complib/cl_async_proc.c b/osm/complib/cl_async_proc.c
index 51561af..7ac96bb 100644
--- a/osm/complib/cl_async_proc.c
+++ b/osm/complib/cl_async_proc.c
@@ -55,7 +55,6 @@ cl_async_proc_construct(
cl_qlist_init( &p_async_proc->item_queue );
cl_spinlock_construct( &p_async_proc->lock );
- cl_thread_pool_construct( &p_async_proc->thread_pool );
}
cl_status_t
diff --git a/osm/complib/cl_dispatcher.c b/osm/complib/cl_dispatcher.c
index a7c0ac7..4a1960c 100644
--- a/osm/complib/cl_dispatcher.c
+++ b/osm/complib/cl_dispatcher.c
@@ -49,6 +49,7 @@
#include
#include
+#include
#include
/* give some guidance when we build our cl_pool of messages */
@@ -132,7 +133,6 @@ cl_disp_construct(
cl_qlist_init( &p_disp->reg_list );
cl_ptr_vector_construct( &p_disp->reg_vec );
- cl_thread_pool_construct( &p_disp->worker_threads );
cl_qlist_init( &p_disp->msg_fifo );
cl_spinlock_construct( &p_disp->lock );
cl_qpool_construct( &p_disp->msg_pool );
diff --git a/osm/complib/cl_thread.c b/osm/complib/cl_thread.c
index f131480..eecc7d6 100644
--- a/osm/complib/cl_thread.c
+++ b/osm/complib/cl_thread.c
@@ -39,7 +39,6 @@
#include
#include
-#include
#include
/*
@@ -129,18 +128,6 @@ cl_thread_stall(
usleep( pause_us );
}
-uint32_t
-cl_proc_count( void )
-{
- uint32_t ret;
-
- ret = get_nprocs();
- if( !ret)
- return 1;/* Workaround for PPC where get_nprocs() returns 0 */
-
- return ret;
-}
-
boolean_t
cl_is_current_thread(
IN const cl_thread_t* constp_thread )
diff --git a/osm/complib/cl_threadpool.c b/osm/complib/cl_threadpool.c
index ff8bf90..ca4e261 100644
--- a/osm/complib/cl_threadpool.c
+++ b/osm/complib/cl_threadpool.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2004-2006 Voltaire, Inc. All rights reserved.
+ * Copyright (c) 2004-2007 Voltaire, Inc. All rights reserved.
* Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights reserved.
* Copyright (c) 1996-2003 Intel Corporation. All rights reserved.
*
@@ -49,134 +49,85 @@
#include
#include
+#include
+#include
#include
-#include
-void
-__cl_thread_pool_routine(
- IN void* const context )
+static int proc_count( void )
{
- cl_status_t status = CL_SUCCESS;
- cl_thread_pool_t*p_thread_pool = (cl_thread_pool_t*)context;
-
- /* Continue looping until signalled to end. */
- while( !p_thread_pool->exit )
- {
- /* Wait for the specified event to occur. */
- status = cl_event_wait_on( &p_thread_pool->wakeup_event,
- EVENT_NO_TIMEOUT, TRUE
);
-
- /* See if we've been signalled to end execution. */
- if( (p_thread_pool->exit) || (status == CL_NOT_DONE) )
- break;
-
- /* The event has been signalled. Invoke the callback. */
- (*p_thread_pool->pfn_callback)( (void*)p_thread_pool->context );
- }
+ int ret = get_nprocs();
+ if (!ret)
+ return 1;/* Workaround for PPC where get_nprocs() returns 0 */
+ return ret;
+}
- /*
-* Decrement the running count to notify the destroying thread
-* that the event was received and processed.
-*/
- cl_atomic_dec( &p_thread_pool->running_count );
- cl_event_signal( &p_thread_pool->destroy_event );
+static void cleanup_mutex(void *arg)
+{
+ pthread_mutex_unlock(&((cl_thread_pool_t *)arg)->mutex);
}
-void
-cl_thread_pool_construct(
- IN cl_thread_pool_t* const p_thread_pool )
+static void *thread_pool_routine(void* context)
{
- CL_ASSERT( p_thread_pool);
+ cl_thread_pool_t *p_thread_pool = (cl_thread_pool_t*)context;
+
+ do {
+ pthread_mutex_lock(&p_thread_pool->mutex);
+ pthread_cleanup_push(cleanup_mutex, p_thread_pool);
+ while(!p_thread_pool->events)
+ pthread_cond_wait(&p_thread_pool->cond,
+ &p_thread_pool->mutex);
+ p_thread_pool->events--;
+ pthread_cleanup_pop(1)
Re: [openib-general] OFA 1.2 tarball creation
>How exactly is various developers' source code pulled together to create >the nightly OFA tarballs at www.openfabrics.org/builds (could this be >put on the wiki somewhere?)? I went looking to see if some of Sean's >work on RDMA CM had made it into these tarballs, and am not seeing code >with the patches I'm looking for. I do not know how OFED creates their tarballs or manages their source. >The exact patch I'm after was 'rdma_cm: allow joins to return a unique >address'. I remember seeing this patch on the ofed_1_2 branch in Sean's >rdma-dev git repository about two weeks ago, though I don't see the >ofed_1_2 branch anymore (the patch does exist on the multicast branch). > Sean, was this patch supposed to make it to the nightly 1.2 tarballs? Assuming that ~vlad/ofed_1_2.git is the OFED kernel tree, then this patch does not appear to be included. I was asked by OFED to publish an ofed_1_2 branch, which I did, but I do not know if it was used in constructing the OFED tree. The patch was intended to go into OFED. - Sean ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Fwd: [ANNOUNCE] GIT 1.5.0
On 17:50 Sun 18 Feb , Sasha Khapyorsky wrote: > On 09:15 Thu 15 Feb , Michael S. Tsirkin wrote: > > FYI. > > I suggest we update git on the openfabrics server to 1.5.0: > > "Detached HEAD" feature will be useful for nightly build scripts. > > Sasha? > > git-1.5.0 feature list looks fine for me. But let's wait with upgrade a > couple of days for 1.5.0.1. Upgraded to git-1.5.0.1. Sasha ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] osm_vendor_ibumad: termination crash fix
When OpenSM is terminated umad_receiver thread still running even after
the structures are destroyed and freed, this causes to random (but easily
reproducible) crashes. The reason is that osm_vendor_delete() does not
care about thread termination. This patch adds the receiver thread
cancellation (by using pthread_cancel() and pthread_join()) and cares to
keep have all mutexes unlocked upon termination. There is also minor
termination code consolidation - osm_vendor_port_close() function.
Signed-off-by: Sasha Khapyorsky <[EMAIL PROTECTED]>
---
osm/include/vendor/osm_vendor_ibumad.h |6 +-
osm/libvendor/osm_vendor_ibumad.c | 157 +++-
osm/libvendor/osm_vendor_ibumad_sa.c |3 +-
3 files changed, 77 insertions(+), 89 deletions(-)
diff --git a/osm/include/vendor/osm_vendor_ibumad.h
b/osm/include/vendor/osm_vendor_ibumad.h
index 4cbd59f..f6e3d69 100644
--- a/osm/include/vendor/osm_vendor_ibumad.h
+++ b/osm/include/vendor/osm_vendor_ibumad.h
@@ -39,7 +39,6 @@
#include
#include
-#include
#include
#include
@@ -87,7 +86,6 @@ typedef struct _osm_ca_info
ib_net64_t guid;
size_t attr_size;
ib_ca_attr_t*p_attr;
-
} osm_ca_info_t;
/*
* FIELDS
@@ -170,8 +168,8 @@ typedef struct _osm_vendor
vendor_match_tbl_t mtbl;
umad_ca_t umad_ca;
umad_port_t umad_port;
- cl_spinlock_t cb_lock;
- cl_spinlock_t match_tbl_lock;
+ pthread_mutex_t cb_mutex;
+ pthread_mutex_t match_tbl_mutex;
int umad_port_id;
void *receiver;
int issmfd;
diff --git a/osm/libvendor/osm_vendor_ibumad.c
b/osm/libvendor/osm_vendor_ibumad.c
index 35f127a..7320738 100644
--- a/osm/libvendor/osm_vendor_ibumad.c
+++ b/osm/libvendor/osm_vendor_ibumad.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2004-2006 Voltaire, Inc. All rights reserved.
+ * Copyright (c) 2004-2007 Voltaire, Inc. All rights reserved.
* Copyright (c) 2002-2005 Mellanox Technologies LTD. All rights reserved.
* Copyright (c) 1996-2003 Intel Corporation. All rights reserved.
*
@@ -58,13 +58,11 @@
#include
#include
-#include
#include
#include
#include
#include
-#include
#include
#include
#include
@@ -97,12 +95,13 @@ typedef struct _osm_umad_bind_info
typedef struct _umad_receiver
{
- cl_event_t signal;
- cl_thread_t receiver;
- osm_vendor_t*p_vend;
- osm_log_t *p_log;
+ pthread_t tid;
+ osm_vendor_t*p_vend;
+ osm_log_t *p_log;
} umad_receiver_t;
+static void osm_vendor_close_port(osm_vendor_t* const p_vend);
+
static void
clear_madw(osm_vendor_t *p_vend)
{
@@ -110,7 +109,7 @@ clear_madw(osm_vendor_t *p_vend)
ib_net64_t old_tid;
OSM_LOG_ENTER( p_vend->p_log, clear_madw );
- cl_spinlock_acquire( &p_vend->match_tbl_lock );
+ pthread_mutex_lock(&p_vend->match_tbl_mutex);
for (m = p_vend->mtbl.tbl, e = m + p_vend->mtbl.max; m < e; m++) {
if (m->tid) {
old_m = m;
@@ -119,7 +118,7 @@ clear_madw(osm_vendor_t *p_vend)
osm_mad_pool_put(
((osm_umad_bind_info_t *)((osm_madw_t
*)m->v)->h_bind)->p_mad_pool,
m->v);
- cl_spinlock_release( &p_vend->match_tbl_lock );
+ pthread_mutex_unlock(&p_vend->match_tbl_mutex);
osm_log(p_vend->p_log, OSM_LOG_ERROR,
"clear_madw: ERR 5401: "
"evicting entry %p (tid was 0x%"PRIx64")\n",
@@ -127,7 +126,7 @@ clear_madw(osm_vendor_t *p_vend)
goto Exit;
}
}
- cl_spinlock_release( &p_vend->match_tbl_lock );
+ pthread_mutex_unlock(&p_vend->match_tbl_mutex);
Exit:
OSM_LOG_EXIT( p_vend->p_log );
@@ -147,18 +146,18 @@ get_madw(osm_vendor_t *p_vend, ib_net64_t *tid)
if (mtid == 0)
return 0;
- cl_spinlock_acquire( &p_vend->match_tbl_lock );
+ pthread_mutex_lock(&p_vend->match_tbl_mutex);
for (m = p_vend->mtbl.tbl, e = m + p_vend->mtbl.max; m < e; m++) {
if (m->tid == mtid) {
m->tid = 0;
*tid = mtid;
res = m->v;
- cl_spinlock_release( &p_vend->match_tbl_lock );
+ pthread_mutex_unlock(&p_vend->match_tbl_mutex);
return res;
}
}
- cl_spinlock_release( &p_vend->match_tbl_lock );
+ pthread_mutex_unlock(&p_vend->match_tbl_mutex);
return 0;
}
@@ -171,13 +170,13 @@ put_madw(osm_vendor_t *p_vend, osm_madw_t *p_madw,
ib_net64_t *tid)
ib_net64_t old_tid;
uint32_t oldest = ~0;
- cl_spinlock_acquire( &p_vend->match_tbl_lock );
+ pt
[openib-general] Port error rate detection
I have a Nagios module that alerts on connectivity, port errors, speed/width problems. I would like to give it the ability to change the severity of the alert depending on whether errors are just present or if they are increasing faster than a specified rate. The intent is to equip the module to keep the state of the last query and possibly history, but I wanted to make sure that I was not re-inventing the wheel first. Is there an attribute or utility that I am overlooking that will help me do this? Thanks, Steven. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [ewg] Re: Address List Change for Friday, 2/23/2007
Greg, Yes, it was a typo. It's been taken care of now. Michael -Original Message- From: [EMAIL PROTECTED] on behalf of Greg Lindahl Sent: Mon 2/19/2007 11:28 AM To: openib-general@openib.org; [EMAIL PROTECTED] Subject: [ewg] Re: [openib-general] Address List Change for Friday, 2/23/2007 I see that the EWG list is now calling itself the Engineering Working Group, has it been renamed from the Enterprise Working Group? If so, did the nature of the list change? Or was it a typo? -- greg ___ ewg mailing list [EMAIL PROTECTED] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [ewg] Re: Address List Change for Friday, 2/23/2007
Heh. Probably a typo in the transition to the new server. Michael -- can you fix? On Feb 19, 2007, at 2:28 PM, Greg Lindahl wrote: > I see that the EWG list is now calling itself the Engineering Working > Group, has it been renamed from the Enterprise Working Group? If so, > did the nature of the list change? Or was it a typo? > > -- greg > > ___ > ewg mailing list > [EMAIL PROTECTED] > http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg -- Jeff Squyres Server Virtualization Business Unit Cisco Systems ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Address List Change for Friday, 2/23/2007
I see that the EWG list is now calling itself the Engineering Working Group, has it been renamed from the Enterprise Working Group? If so, did the nature of the list change? Or was it a typo? -- greg ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] uDAPL: RDMA Write example
Caitlin Bestler schrieb: > [EMAIL PROTECTED] wrote: > >> Hello, >> >> I'm trying to find a small sample program, that uses RDMA >> Write instead of Send/Recv. In the sources there is no single >> uDAPL example program and on the net neither. >> Could someone please help me to find something useful? >> >> Thanks! >> Christian >> >> > With uDAPL, you don't use RDMA Write "instead of" Send/Recv, you use > it in addition to Send/Recv. The Send/Recv is still required for > synchronization. > > So you put a Send/Recv before and after the dat_ep_post_rdma_write()? I tried it once with a zero byte Send/Recv but I had the impression that it doesn't work so that I have to do a one byte Send/Recv? ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] uDAPL: RDMA Write example
We are working on a new provider support for uDAPL. So we don't use verbs and rdmacm. Your example is ok but not what I was looking for. I am searching for a really small programm, that does RDMA with uDAPL in a few lines (I know a few lines is impossible but a few hundred lines). The dapltest suite is not really small. Christian Or Gerlitz schrieb: > Christian Kaiser wrote: > >> I'm trying to find a small sample program, that uses RDMA Write instead >> of Send/Recv. In the sources there is no single uDAPL example program >> and on the net neither. >> Could someone please help me to find something useful? >> > > see http://dapl.svn.sourceforge.net/viewvc/dapl/trunk/test/dapltest > > Anyway, can you comment what using udapl buys you which you don't get > from coding to the verbs (libibverbs) and rdmacm (librdmacm) ??? > > Or. > > > ___ > openib-general mailing list > openib-general@openib.org > http://openib.org/mailman/listinfo/openib-general > > To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general > > > ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Fork issues with simple MPI program
We are seeing some fork issues with a simple MPI program (attached) running on
a 2.6.16+ kernels and
OFED 1.1. We have tried both Intel MPI and mvapich2 with the same results:
t_fork> mpiexec -n 2 t_system_fork
parent process
[0] started child process with pid=31552
send desc error
parent process
[0] Abort: [] Got completion with error 1, vendor code=69, dest rank=1
at line 540 in file ibv_channel_manager.c
[1] I am child process with pid=25437
[1] started child process with pid=25437
[0] I am child process with pid=31552
child process
[1] finished pid=25437
child process
[0] finished pid=31552
rank 0 in job 2 svlmpicl400_32925 caused collective abort of all ranks
exit status of rank 0: return code 252
If you run mvapich2 for uDAPL, it hangs before second MPI_Barrier() just like
Intel MPI. If you use
the I_MPI_RDMA_USE_EVD_FALLBACK=1 option with Intel MPI you get the following
error similar to
mvapich2:
parent process
parent process
[0] I am child process with pid=9596
[0] started child process with pid=9596
[1] I am child process with pid=11477
[1] started child process with pid=11477
[0][rdma_iba.c:1007] Intel MPI fatal error: DTO operation completed with error.
status=0x2.
cookie=0x1
[1][rdma_iba.c:1007] Intel MPI fatal error: DTO operation completed with error.
status=0x2.
cookie=0x1
child process
[1] finished pid=11477
child process
[0] finished pid=9596
rank 0 in job 8 cst-19_54707 caused collective abort of all ranks
exit status of rank 0: return code 255
Any insight would be greatly appreciated. It was our assumption that the parent
process can continue
to use IB resources after the fixes went into 2.6.16 and OFED 1.1. Is this
true?
Thanks,
-arlin
#include "mpi.h"
#include
#include
int main(int argc,char *argv[])
{
int myid, numprocs;
pid_t pid;
MPI_Init(&argc,&argv);
MPI_Comm_size(MPI_COMM_WORLD,&numprocs);
MPI_Comm_rank(MPI_COMM_WORLD,&myid);
MPI_Barrier(MPI_COMM_WORLD);
system("echo parent process");
pid = fork();
if( pid == 0)
{
pid = getpid();
printf("[%d] I am child process with pid=%d\n", myid, pid);
system("echo child process");
} else
{
printf("[%d] started child process with pid=%d\n", myid, pid);
MPI_Barrier(MPI_COMM_WORLD);
MPI_Finalize();
pid = getpid();
}
printf("[%d] finished pid=%d\n", myid, pid);
return 0;
}
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] OFA 1.2 tarball creation
How exactly is various developers' source code pulled together to create the nightly OFA tarballs at www.openfabrics.org/builds (could this be put on the wiki somewhere?)? I went looking to see if some of Sean's work on RDMA CM had made it into these tarballs, and am not seeing code with the patches I'm looking for. The exact patch I'm after was 'rdma_cm: allow joins to return a unique address'. I remember seeing this patch on the ofed_1_2 branch in Sean's rdma-dev git repository about two weeks ago, though I don't see the ofed_1_2 branch anymore (the patch does exist on the multicast branch). Sean, was this patch supposed to make it to the nightly 1.2 tarballs? I'm trying to avoid having to figure out how to build source from git into suitable RPM's for RHEL4; documentation on that would be great too :) Andrew ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] uDAPL: RDMA Write example
[EMAIL PROTECTED] wrote: > Hello, > > I'm trying to find a small sample program, that uses RDMA > Write instead of Send/Recv. In the sources there is no single > uDAPL example program and on the net neither. > Could someone please help me to find something useful? > > Thanks! > Christian > With uDAPL, you don't use RDMA Write "instead of" Send/Recv, you use it in addition to Send/Recv. The Send/Recv is still required for synchronization. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Minor correction regarding list migration
Sorry for the follow-up, but I made a minor error in the previous e-mail. The reference to "openib-promoters" should have been "openib-general." So just to reiterate: openib-general will become [EMAIL PROTECTED] this Friday, 2/23/2007 Thanks, Michael ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] Address List Change for Friday, 2/23/2007
We're in the process of migrating the maillists from the old openib.org server to the new lists.openfabrics.org machine. The list openib-promoters will be moved this Friday, February 23, 2007. The new address for the maillist will be [EMAIL PROTECTED] What this means is that messages will come from [EMAIL PROTECTED] Conversely, replies should be made to this address as well. Messages will also have a new subject line prefix of [OFA General]. If you have configured your e-mail client to filter based on maillist address or subject headers, you may need to make some adjustments for filtering. However, for the sake of transition, messages sent to the previous maillist address on the old server will forward to the new server. This forward will remain in place until the old server is taken offline and final DNS changes are made. We expect the old server to go offline sometime in early March. The web archives will also be migrated to the new web address shortly, http://lists.openfabrics.org. If you have any questions, please don't hesitate to contact me at [EMAIL PROTECTED] Regards, Michael Lee ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] 32-bit build for ppc64 is required
On Thursday 15 February 2007 20:30, Hoang-Nam Nguyen wrote: > > > Yuk. I suppose I could write one, but I don't (and can't) use any of > > > the OFED supplied build scripts in our build system, so it's hard for > me > > > to test since our build system is the only way I have to access > > > ppc/ppc64 hardware. > > Oh, well. > > Other takers? > OK, I've no choice to say no. Haven't look at the scripts yet. But will do > in next couple of days! > Nam > > Hi, Did I interpret the conclusion of this thread correctly? Nam will create a patch against the OFED1.2 build scripts, which provides 32 and 64 bit binaries for ppc. Do you agree? regards Stefan ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] [PATCH] librdmacm: fix bug causing failure to work with partial membership pkey
Or,
On 2/19/07, Or Gerlitz <[EMAIL PROTECTED]> wrote:
> Hi Sean,
>
> this fixes a bug which did not allow to run librdmacm apps over a node
> which is partial member of a partition. The patch takes the approach of the
> kernel ib_find_cached_pkey implementation.
>
> If you approve this, i suggest pushing it also into OFED 1.2 as a bug fix.
>
> Or.
>
> --
> The pkey extracted by the RDMA CM from the IPoIB device hardware address
> always
> has the full membership bit set. However, when looking in the pkey table the
> search must mask out the full membership bit.
>
> Signed-off-by: Or Gerlitz <[EMAIL PROTECTED]>
> Signed-off-by: Olga Shern <[EMAIL PROTECTED]>
>
> diff --git a/src/cma.c b/src/cma.c
> index c5f8cd9..9c24c6a 100644
> --- a/src/cma.c
> +++ b/src/cma.c
> @@ -661,7 +661,7 @@ static int ucma_find_pkey(struct cma_dev
>
> for (i = 0, ret = 0; !ret; i++) {
> ret = ibv_query_pkey(cma_dev->verbs, port_num, i, &chk_pkey);
> - if (!ret && pkey == chk_pkey) {
> + if ((!ret && pkey == chk_pkey) || (!ret && htons(ntohs(pkey)
> & 0x7fff) == chk_pkey)) {
What about just using:
if (!ret && pkey | 0x8000 == chk_pkey | 0x8000) {
even if not there is no need to check the ret twice in case of limited
membership
-- Moni
> *pkey_index = (uint16_t) i;
> return 0;
> }
>
> ___
> openib-general mailing list
> openib-general@openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
>
>
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [PATCH] IB/ipoib: Fix ipoib handling for pkey reordering
This issue was found during partitioning & SM fail over testing. The fix was
tested for 24 hours with pkey reshuffling every few seconds. The patch applies
to Roland's master branch.
SM reconfiguration or failover possibly causes a shuffling of the values in the
port pkey table. The current implementation only queries for the index of the
pkey once, when it creates the device QP and after that moves it into working
state, and hence does not address this scenario. Fix this by using the
PKEY_CHANGE event as a trigger to reconfigure the device QP.
Signed-off-by: Moni Levy <[EMAIL PROTECTED]>
---
ipoib.h |2 ++
ipoib_ib.c| 22 --
ipoib_main.c |1 +
ipoib_verbs.c |4 +++-
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/infiniband/ulp/ipoib/ipoib.h
b/drivers/infiniband/ulp/ipoib/ipoib.h
index 07deee8..ed854e8 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib.h
+++ b/drivers/infiniband/ulp/ipoib/ipoib.h
@@ -139,6 +139,7 @@ struct ipoib_dev_priv {
struct delayed_work pkey_task;
struct delayed_work mcast_task;
struct work_struct flush_task;
+ struct work_struct flush_restart_qp_task;
struct work_struct restart_task;
struct delayed_work ah_reap_task;
@@ -261,6 +262,7 @@ struct ipoib_dev_priv *ipoib_intf_alloc(
int ipoib_ib_dev_init(struct net_device *dev, struct ib_device *ca, int port);
void ipoib_ib_dev_flush(struct work_struct *work);
+void ipoib_ib_dev_flush_restart_qp(struct work_struct *work);
void ipoib_ib_dev_cleanup(struct net_device *dev);
int ipoib_ib_dev_open(struct net_device *dev);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
index 59d9594..5e2ada9 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_ib.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_ib.c
@@ -611,7 +611,7 @@ int ipoib_ib_dev_init(struct net_device
return 0;
}
-void ipoib_ib_dev_flush(struct work_struct *work)
+static void __ipoib_ib_dev_flush(struct work_struct *work, int restart_qp)
{
struct ipoib_dev_priv *cpriv, *priv =
container_of(work, struct ipoib_dev_priv, flush_task);
@@ -630,6 +630,12 @@ void ipoib_ib_dev_flush(struct work_stru
ipoib_dbg(priv, "flushing\n");
ipoib_ib_dev_down(dev, 0);
+
+ if (restart_qp) {
+ ipoib_dbg(priv, "restarting the device QP\n");
+ ipoib_ib_dev_stop(dev);
+ ipoib_ib_dev_open(dev);
+ }
/*
* The device could have been brought down between the start and when
@@ -644,11 +650,23 @@ void ipoib_ib_dev_flush(struct work_stru
/* Flush any child interfaces too */
list_for_each_entry(cpriv, &priv->child_intfs, list)
- ipoib_ib_dev_flush(&cpriv->flush_task);
+ __ipoib_ib_dev_flush(&cpriv->flush_task, restart_qp);
mutex_unlock(&priv->vlan_mutex);
}
+void ipoib_ib_dev_flush(struct work_struct *work)
+{
+ /* We only restart the QP in case of PKEY change event */
+ __ipoib_ib_dev_flush(work, 0);
+}
+
+void ipoib_ib_dev_flush_restart_qp(struct work_struct *work)
+{
+ /* We only restart the QP in case of PKEY change event */
+ __ipoib_ib_dev_flush(work, 1);
+}
+
void ipoib_ib_dev_cleanup(struct net_device *dev)
{
struct ipoib_dev_priv *priv = netdev_priv(dev);
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_main.c
b/drivers/infiniband/ulp/ipoib/ipoib_main.c
index 705eb1d..da46b79 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_main.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c
@@ -942,6 +942,7 @@ static void ipoib_setup(struct net_devic
INIT_DELAYED_WORK(&priv->pkey_task,ipoib_pkey_poll);
INIT_DELAYED_WORK(&priv->mcast_task, ipoib_mcast_join_task);
INIT_WORK(&priv->flush_task, ipoib_ib_dev_flush);
+ INIT_WORK(&priv->flush_restart_qp_task, ipoib_ib_dev_flush_restart_qp);
INIT_WORK(&priv->restart_task, ipoib_mcast_restart_task);
INIT_DELAYED_WORK(&priv->ah_reap_task, ipoib_reap_ah);
}
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
b/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
index 7b717c6..c249915 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_verbs.c
@@ -252,12 +252,14 @@ void ipoib_event(struct ib_event_handler
container_of(handler, struct ipoib_dev_priv, event_handler);
if (record->event == IB_EVENT_PORT_ERR||
- record->event == IB_EVENT_PKEY_CHANGE ||
record->event == IB_EVENT_PORT_ACTIVE ||
record->event == IB_EVENT_LID_CHANGE ||
record->event == IB_EVENT_SM_CHANGE ||
record->event == IB_EVENT_CLIENT_REREGISTER) {
ipoib_dbg(priv, "Port state change event\n");
queue_work(ipoib_workqueue, &priv->flush_task);
+ } else if (record->event == IB_EVENT_PKEY_CHANGE) {
+
[openib-general] [Bug 371] IPoIB HA not working properly with OFED1.2-alpha
https://bugs.openfabrics.org/show_bug.cgi?id=371 --- Comment #1 from [EMAIL PROTECTED] 2007-02-19 03:56 --- It is working fine on SLES10 systems. -- Configure bugmail: https://bugs.openfabrics.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
Re: [openib-general] Problem with SRP with 512 byte sector size with > 2 TB LUNs
Hello, I also contacted DDN about that problem and am still waiting for a response. I cannot test this DDN target over fibre channel, because you can only connect over IB to it. I have the same impression, that the DDN target somehow does not handle READ CAPACITY(16) properly. Best regards, Thomas Großmann On Wednesday 07 February 2007 18:58, you wrote: > > Is it possible to add LUNs with > 2 TB and 512 byte sectors ? > > Why does the READ CAPACITY(16) comand fail ? > > It seems that the DDN target is not reporting good information -- I > don't see anything obviously wrong in what the kernel is doing (now > that SRP sends a READ CAPACITY command). Do you know if the same type > of config works over fibre channel? > > - R. -- Thomas Großmann High Performance Computing Center Stuttgart (HLRS) Allmandring 30 70550 Stuttgart, Germany E-Mail: [EMAIL PROTECTED] Phone: ++49-711-685-65529 Fax : ++49-711-685-65832 ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] ofa_1_2_kernel 20070219-0200 daily build status
This email was generated automatically, please do not reply Common build parameters: --with-ipoib-mod --with-sdp-mod --with-srp-mod --with-user_mad-mod --with-user_access-mod --with-mthca-mod --with-core-mod --with-addr_trans-mod --with-cxgb3-mod Passed: Passed on i686 with 2.6.15-23-server Passed on i686 with linux-2.6.17 Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.15 Passed on i686 with linux-2.6.14 Passed on i686 with linux-2.6.13 Passed on i686 with linux-2.6.12 Passed on i686 with linux-2.6.16 Passed on i686 with linux-2.6.19 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.19 Passed on powerpc with linux-2.6.17 Passed on powerpc with linux-2.6.19 Passed on x86_64 with linux-2.6.12 Passed on x86_64 with linux-2.6.17 Passed on powerpc with linux-2.6.18 Passed on x86_64 with linux-2.6.16 Passed on x86_64 with linux-2.6.15 Passed on x86_64 with linux-2.6.14 Passed on x86_64 with linux-2.6.13 Passed on ppc64 with linux-2.6.19 Passed on powerpc with linux-2.6.15 Passed on ia64 with linux-2.6.19 Passed on powerpc with linux-2.6.16 Passed on ppc64 with linux-2.6.15 Passed on powerpc with linux-2.6.12 Passed on ppc64 with linux-2.6.16 Passed on powerpc with linux-2.6.13 Passed on powerpc with linux-2.6.14 Passed on ppc64 with linux-2.6.13 Passed on ppc64 with linux-2.6.17 Passed on ppc64 with linux-2.6.18 Passed on ppc64 with linux-2.6.14 Passed on ppc64 with linux-2.6.12 Passed on ia64 with linux-2.6.16 Passed on ia64 with linux-2.6.15 Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.12 Passed on ia64 with linux-2.6.17 Passed on ia64 with linux-2.6.14 Passed on ia64 with linux-2.6.13 Failed: ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
[openib-general] [Bug 371] New: IPoIB HA not working properly with OFED1.2-alpha
https://bugs.openfabrics.org/show_bug.cgi?id=371 Summary: IPoIB HA not working properly with OFED1.2-alpha Product: OpenFabrics Linux Version: 1.2alpha1 Platform: X86-64 OS/Version: RHEL 4 Status: NEW Severity: major Priority: P2 Component: IPoIB AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I configured IPoIB HA with OFED1.2-alpha release and it is not working for me. I have configured IPoIB HA on a RHEL4up4 machine with both ports up. Before configuring IPoIB HA, both IB interfaces are able to ping the other machine. Then I executed ipoib_ha.pl script and configured ib0 as primary and ib1 as secondary interface. The ip address of ib1 interface has gone and till this point the things seems to be working fine. The problem starts when I pulled the IB cable connecting port1. I can see ib0 interface going down and ib1 interface taking IP address of ib0 interface but ping doesn't work after that. Even if I reinsert the cable in port1, ping is not working. I have attached some logs below. [EMAIL PROTECTED] ~]# ibv_devinfo hca_id: mthca0 fw_ver: 5.1.400 node_guid: 0006:6a00:9800:6b90 sys_image_guid: 0006:6a00:9800:6b90 vendor_id: 0x066a vendor_part_id: 25218 hw_ver: 0xA0 board_id: SS_02 phys_port_cnt: 2 port: 1 state: PORT_ACTIVE (4) max_mtu:2048 (4) active_mtu: 2048 (4) sm_lid: 6 port_lid: 2 port_lmc: 0x00 port: 2 state: PORT_ACTIVE (4) max_mtu:2048 (4) active_mtu: 2048 (4) sm_lid: 6 port_lid: 3 port_lmc: 0x00 [EMAIL PROTECTED] ~]# ifconfig eth0 Link encap:Ethernet HWaddr 00:A0:D1:E4:53:DA inet addr:172.20.50.227 Bcast:172.20.50.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:d1ff:fee4:53da/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:125 errors:0 dropped:0 overruns:0 frame:0 TX packets:115 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:17236 (16.8 KiB) TX bytes:15347 (14.9 KiB) Interrupt:201 ib0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:172.20.51.227 Bcast:172.20.51.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:2044 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:128 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) ib1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:172.20.52.227 Bcast:172.20.52.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:2044 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:128 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1543 errors:0 dropped:0 overruns:0 frame:0 TX packets:1543 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1648528 (1.5 MiB) TX bytes:1648528 (1.5 MiB) [EMAIL PROTECTED] ~]# ping 172.20.51.226 -c 1 PING 172.20.51.226 (172.20.51.226) 56(84) bytes of data. 64 bytes from 172.20.51.226: icmp_seq=0 ttl=64 time=1.44 ms --- 172.20.51.226 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.442/1.442/1.442/0.000 ms, pipe 2 [EMAIL PROTECTED] ~]# ping 172.20.52.226 -c 1 PING 172.20.52.226 (172.20.52.226) 56(84) bytes of data. 64 bytes from 172.20.52.226: icmp_seq=0 ttl=64 time=1.67 ms --- 172.20.52.226 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 1.671/1.671/1.671/0.000 ms, pipe 2 [EMAIL PROTECTED] ~]# [EMAIL PROTECTED] ~]# ipoib_ha.pl -p ib0 -s ib1 --with-arping -vv get_cfg: Got /etc/sysconfig/network-scripts/ifcfg-ib0 Date:Mon Feb 19 02:32:22 2007 ib0:
Re: [openib-general] [openfabrics-ewg] OFED 1.2 alpha release
Tziporet Koren wrote: > Regarding RHEL4 U4 and IPoIB bug - Or just prepared a patch that should > fix it. We will merge it and test for the beta. The patch will only fix the bug for RDMA CM multicast consumers, since unlike IPoIB who gets the (wrong in the RH4 U4 case) L2 multicast address from the stack, the rdma cm has the multicast IP address and is able to compute the correct L2 address. This is confusing, i know... ___ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
