[PATCH] IB/qib: Kernel BUG at include/linux/timer.h:82

2011-02-10 Thread Mike Marciniszyn
The following panic BUG_ON occurs during qib testing:

Kernel BUG at include/linux/timer.h:82

RIP  [881f7109] :ib_qib:start_timer+0x73/0x89
 RSP 80425bd0
 0Kernel panic - not syncing: Fatal exception
 0Dumping qib trace buffer from panic
qib_set_lid INFO: IB0:1 got a lid: 0xf8
Done dumping qib trace buffer
BUG: warning at kernel/panic.c:137/panic() (Tainted: G

The flaw is due to a missing state test when processing responses that results
in an add_timer() call when the same timer is already queued.  This code was
executing in parallel with a QP destroy on another CPU that had changed the 
state
to reset, but the missing test caused to response handling code to run on into
the panic.

Signed-off-by: Mike Marciniszyn mike.marcinis...@qlogic.com
---
 drivers/infiniband/hw/qib/qib_rc.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/infiniband/hw/qib/qib_rc.c 
b/drivers/infiniband/hw/qib/qib_rc.c
index 8245237..25ddb5b 100644
--- a/drivers/infiniband/hw/qib/qib_rc.c
+++ b/drivers/infiniband/hw/qib/qib_rc.c
@@ -1439,6 +1439,9 @@ static void qib_rc_rcv_resp(struct qib_ibport *ibp,
}
 
spin_lock_irqsave(qp-s_lock, flags);
+   if (!(ib_qib_state_ops[qp-state]  QIB_PROCESS_RECV_OK))
+   goto ack_done;
+
 
/* Ignore invalid responses. */
if (qib_cmp24(psn, qp-s_next_psn) = 0)

--
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/qib: Kernel BUG at include/linux/timer.h:82

2011-02-10 Thread Roland Dreier
Thanks, applied.
--
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


[PATCH] opensm.spec.in: Add in man5 for torus-2QoS.conf

2011-02-10 Thread Jim Schutt
From: Hal Rosenstock h...@mellanox.com

Signed-off-by: Hal Rosenstock h...@mellanox.com
Signed-off-by: Jim Schutt jasc...@sandia.gov
---
 opensm/opensm.spec.in |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/opensm/opensm.spec.in b/opensm/opensm.spec.in
index c541804..65e46c9 100644
--- a/opensm/opensm.spec.in
+++ b/opensm/opensm.spec.in
@@ -129,6 +129,7 @@ fi
 %{_sbindir}/opensm
 %{_sbindir}/osmtest
 %{_mandir}/man8/*
+%{_mandir}/man5/*
 %doc AUTHORS COPYING README doc/performance-manager-HOWTO.txt 
doc/QoS_management_in_OpenSM.txt doc/opensm_release_notes-3.3.txt
 %{_sysconfdir}/init.d/opensmd
 %{_sbindir}/sldd.sh
-- 
1.6.2.2


--
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


[opensm] RFC: new routing options (repost)

2011-02-10 Thread Albert Chu
[This is a repost from Oct 2010 with rebased patches]

We recently got a new cluster and I've been experimenting with some
routing changes to improve the average bandwidth of the cluster.  They
are attached as patches with description of the routing goals below.

We're using mpiGraph (http://sourceforge.net/projects/mpigraph/) to
measure min, peak, and average send/recv bandwidth across the cluster.
What we found with the original updn routing was an average of around
420 MB/s send bandwidth and 508 MB/s recv bandwidth.  The following two
patches were able to get the average send bandwidth up to 1045 MB/s and
recv bandwidth up to 1228 MB/s.

I'm sure this is only round 1 of the patches and I'm looking for
comments.  Many areas could be cleaned up w/ some rearchitecture, but I
elected to implement the most non-invasive implementation first.  I'm
also open to name changes on the options.

1) Port Shifting

This is similar to what was done with some of the LMC  0 code.
Congestion would occur due to alignment of routes w/ common traffic
patterns.  However, we found that it was also necessary for LMC=0 and
only for used-ports.  For example, lets say there are 4 ports (called A,
B, C, D) and we are routing lids 1-9 through them.  Suppose only routing
through A, B, and C will reach lids 1-9.

The LFT would normally be:

A: 1 4 7
B: 2 5 8
C: 3 6 9
D:

The Port Shifting option would make this:

A: 1 6 8
B: 2 4 9
C: 3 5 7
D:

This option by itself improved the mpiGraph average send/recv bandwidth
from 420 MB/s and 508 MB/s to to 991 MB/s and 1172 MB/s.

2) Remote Guid Sorting

Most core/spine switches we've seen thus far have had line boards
connected to spine boards in a consistent pattern.  However, we recently
got some Qlogic switches that connect from line/leaf boards to spine
boards in a (to the casual observer) random pattern.  I'm sure there was
a good electrical/board reason for this design, but it does hurt routing
b/c updn doesn't account for this.  Here's an output from iblinkinfo as
an example.

Switch 0x00066a00ec0029b8 ibcore1 L123:
 1801[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 254   19[  ] 
ibsw55 ( )
 1802[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 253   19[  ] 
ibsw56 ( )
 1803[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 258   19[  ] 
ibsw57 ( )
 1804[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 257   19[  ] 
ibsw58 ( )
 1805[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 256   19[  ] 
ibsw59 ( )
 1806[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 255   19[  ] 
ibsw60 ( )
 1807[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 261   19[  ] 
ibsw61 ( )
 1808[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 262   19[  ] 
ibsw62 ( )
 1809[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 260   19[  ] 
ibsw63 ( )
 180   10[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 259   19[  ] 
ibsw64 ( )
 180   11[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 284   19[  ] 
ibsw65 ( )
 180   12[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 285   19[  ] 
ibsw66 ( )
 180   13[  ] ==( 4X 10.0 Gbps Active/  LinkUp)==2227   19[  ] 
ibsw67 ( )
 180   14[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 283   19[  ] 
ibsw68 ( )
 180   15[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 267   19[  ] 
ibsw69 ( )
 180   16[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 270   19[  ] 
ibsw70 ( )
 180   17[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 269   19[  ] 
ibsw71 ( )
 180   18[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 268   19[  ] 
ibsw72 ( )
 180   19[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 222   17[  ] 
ibcore1 S117B ( )
 180   20[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 209   19[  ] 
ibcore1 S211B ( )
 180   21[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 218   21[  ] 
ibcore1 S117A ( )
 180   22[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 192   23[  ] 
ibcore1 S215B ( )
 180   23[  ] ==( 4X 10.0 Gbps Active/  LinkUp)==  85   15[  ] 
ibcore1 S209A ( )
 180   24[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 182   13[  ] 
ibcore1 S215A ( )
 180   25[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 200   11[  ] 
ibcore1 S115B ( )
 180   26[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 129   25[  ] 
ibcore1 S209B ( )
 180   27[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 213   27[  ] 
ibcore1 S115A ( )
 180   28[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 197   29[  ] 
ibcore1 S213B ( )
 180   29[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 178   28[  ] 
ibcore1 S111A ( )
 180   30[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 2157[  ] 
ibcore1 S213A ( )
 180   31[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 2075[  ] 
ibcore1 S113B ( )
 180   32[  ] ==( 4X 10.0 Gbps Active/  LinkUp)== 2126[  ] 
ibcore1 S211A ( )
 180   33[  ] ==( 4X 10.0 Gbps