Re: [openib-general] [PATCH] osm: pkey manager fail to clear unused peer block
Hi Eitan, On Sat, 2006-07-01 at 16:21, Eitan Zahavi wrote: Hi Hal Similar to the failure to clear HCA port pkey block if it was empty. The code for peer port does depend on the neighbor HCA block to exist. So the fix is very similar: use an empty block for comparing with the current peer port in this case. Eitan Signed-off-by: Eitan Zahavi [EMAIL PROTECTED] Thanks. Applied. -- Hal ___ 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] ucma into kernel.org
Michael S. Tsirkin wrote: Quoting r. Sean Hefty [EMAIL PROTECTED]: Can you drive these enhancements only to 2.6.18. I would like these features in OFED 1.1 as well. However, there are no users of those new interfaces in 2.6.18 that would justify their inclusion. I think setting the number of retries and timeout in CMA might be useful for iSER as well. Or, what do you think? Currently i don't plan to have iSER use these APIs. Sean - looking on the cma/ucma APIs i see that the kernel APIs are not in place yet (eg the equivalent of rdma_set/get_options) or in the kernel the CMA consumer is expected to call directly the APIs exported by rdma_cm_ib.h? 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] [diags] compilation warning fix on 32 bit machines
Compilation warning on 32 bit machines was fixed.
Signed-off-by: Dotan Barak [EMAIL PROTECTED]
Index: last_stable/src/userspace/management/diags/src/grouping.c
===
--- last_stable.orig/src/userspace/management/diags/src/grouping.c 2006-07-02
18:09:41.0 +0300
+++ last_stable/src/userspace/management/diags/src/grouping.c 2006-07-03
11:50:18.0 +0300
@@ -93,7 +93,7 @@ static uint64_t topspin_chassisguid(uint
{
/* Byte 3 in system image GUID is chassis type, and */
/* Byte 4 is location ID (slot) so just mask off byte 4 */
- return guid 0x00ff;
+ return guid 0x00ffULL;
}
static uint64_t get_chassisguid(uint64_t guid, uint32_t vendid)
___
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] [diags] compilation warning fix on 32 bit machines
On Mon, 2006-07-03 at 05:57, Dotan Barak wrote: Compilation warning on 32 bit machines was fixed. Signed-off-by: Dotan Barak [EMAIL PROTECTED] Thanks. Applied. -- Hal ___ 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] design for communication established affiliated asynchronous event handling
Sean Hefty wrote: Rimmer, Todd wrote: The CM would open the CA, provide its async event callback routine and perform a special register_cm() verbs call. Of course most CM traffic would occur on the GSI QP, so this open CA instance was only for this purpose. This special verb was only available in kernel space (avoiding security issue of application stealing CM interface and because our CM was in the kernel anyway). Thanks for the info. I'm considering this sort of approach. OK, so you opt for a change that will have the whole solution running within the ibstack core (hw driver / core / cm) - the CM gets an async event which make it synthesize an RTU and act on it. So we went down from CMA level handling to CM level handling and it would work for both user and kernel consumers, this is in the price of having to change the verbs access layer for the CM to register on QP async events. Again, also with this solution the ULP has to be aware for CQ completions related to a QP on which ESTABLISHED event was not yet delivered on the associated CMA ID. Sound good, in fact our gen1 stack was using this solution as well, relying on the VAPI driver feature of delivering affiliated async events to all the kernel consumers (the async event ***handler*** was not associated with a specific QP) 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] [librdmacm] rping: compilation warning on 64 bit machines was fixed
Compilation warning on 64 bit machines was fixed.
Signed-off-by: Dotan Barak [EMAIL PROTECTED]
Index: last_stable/src/userspace/librdmacm/examples/rping.c
===
--- last_stable.orig/src/userspace/librdmacm/examples/rping.c 2006-07-02
18:09:41.0 +0300
+++ last_stable/src/userspace/librdmacm/examples/rping.c 2006-07-03
13:38:20.0 +0300
@@ -1025,7 +1025,7 @@ int main(int argc, char *argv[])
if ((cb-size RPING_MIN_BUFSIZE) ||
(cb-size (RPING_BUFSIZE - 1))) {
fprintf(stderr, Invalid size %d
- (valid range is %d to %d)\n,
+ (valid range is %Zd to %d)\n,
cb-size, RPING_MIN_BUFSIZE, RPING_BUFSIZE);
ret = EINVAL;
} else
___
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] OpenSM/osmtest: Fix display of key violation counters in osmtest_validate_port_data
OpenSM/osmtest: Fix display of key violation counters in osmtest_validate_port_data Signed-off-by: Hal Rosenstock [EMAIL PROTECTED] Index: osmtest/osmtest.c === --- osmtest/osmtest.c (revision 8335) +++ osmtest/osmtest.c (working copy) @@ -3919,8 +3919,8 @@ osmtest_validate_port_data( IN osmtest_t Field mismatch port LID 0x%X Num:0x%X\n \t\t\t\tExpected m_key_violations 0x%X, received 0x%X\n, cl_ntoh16( p_rec-lid ), p_rec-port_num, - p_port-rec.port_info.m_key_violations, - p_rec-port_info.m_key_violations ); + cl_ntoh16( p_port-rec.port_info.m_key_violations ), + cl_ntoh16( p_rec-port_info.m_key_violations ) ); status = IB_ERROR; goto Exit; } @@ -3933,8 +3933,8 @@ osmtest_validate_port_data( IN osmtest_t Field mismatch port LID 0x%X Num:0x%X\n \t\t\t\tExpected p_key_violations 0x%X, received 0x%X\n, cl_ntoh16( p_rec-lid ), p_rec-port_num, - p_port-rec.port_info.p_key_violations, - p_rec-port_info.p_key_violations ); + cl_ntoh16( p_port-rec.port_info.p_key_violations ), + cl_ntoh16( p_rec-port_info.p_key_violations ) ); status = IB_ERROR; goto Exit; } @@ -3947,8 +3947,8 @@ osmtest_validate_port_data( IN osmtest_t Field mismatch port LID 0x%X Num:0x%X\n \t\t\t\tExpected q_key_violations 0x%X, received 0x%X\n, cl_ntoh16( p_rec-lid ), p_rec-port_num, - p_port-rec.port_info.q_key_violations, - p_rec-port_info.q_key_violations ); + cl_ntoh16( p_port-rec.port_info.q_key_violations ), + cl_ntoh16( p_rec-port_info.q_key_violations ) ); status = IB_ERROR; goto Exit; } ___ 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 165] New: IBWSD.DLL crashes when accessing g_pm_stat.pdata[INTR_TOTAL]
http://openib.org/bugzilla/show_bug.cgi?id=165 Summary: IBWSD.DLL crashes when accessing g_pm_stat.pdata[INTR_TOTAL] Product: OpenFabrics Windows Version: unspecified Platform: X86-64 OS/Version: Other Status: NEW Severity: blocker Priority: P4 Component: WSD AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Scenario: .NET 2 application ontop WSD The app itself has performance counters. The following line: InterlockedIncrement64( g_pm_stat.pdata[INTR_TOTAL] ); Cause a crash in the function ib_cq_thread() When compiling WSD without performance counter, the app runs succssfully. I couldn't debug the application (yet). --- 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
[openib-general] [PATCH] [TRIVIAL] OpenSM/osm_sm_mad_ctrl.c: Eliminate dead code in __osm_sm_mad_ctrl_process_get_resp
OpenSM/osm_sm_mad_ctrl.c: Eliminate dead code in
__osm_sm_mad_ctrl_process_get_resp
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: opensm/osm_sm_mad_ctrl.c
===
--- opensm/osm_sm_mad_ctrl.c(revision 8341)
+++ opensm/osm_sm_mad_ctrl.c(working copy)
@@ -356,13 +356,6 @@ __osm_sm_mad_ctrl_process_get_resp(
goto Exit;
}
}
- else
- {
-/*
- We received a response for which there is no recipient!!
-*/
-CL_ASSERT( FALSE );
- }
Exit:
OSM_LOG_EXIT( p_ctrl-p_log );
___
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] [MINOR] OpenSM/osm_helper: Add support for dump of SAInformInfoRecord
OpenSM/osm_helper: Add support for dump of SAInformInfoRecord
Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Index: include/opensm/osm_helper.h
===
--- include/opensm/osm_helper.h (revision 8343)
+++ include/opensm/osm_helper.h (working copy)
@@ -265,6 +265,12 @@ osm_dump_inform_info(
IN const osm_log_level_t log_level );
void
+osm_dump_inform_info_record(
+ IN osm_log_t* const p_log,
+ IN const ib_inform_info_record_t* const p_iir,
+ IN const osm_log_level_t log_level );
+
+void
osm_dump_pkey_block(
IN osm_log_t* const p_log,
IN uint64_t port_guid,
Index: opensm/osm_helper.c
===
--- opensm/osm_helper.c (revision 8343)
+++ opensm/osm_helper.c (working copy)
@@ -1254,6 +1254,101 @@ osm_dump_inform_info(
/**
**/
void
+osm_dump_inform_info_record(
+ IN osm_log_t* const p_log,
+ IN const ib_inform_info_record_t* const p_iir,
+ IN const osm_log_level_t log_level )
+{
+ uint32_t qpn;
+ uint8_t resp_time_val;
+
+
ib_inform_info_get_qpn_resp_time(p_iir-inform_info.g_or_v.generic.qpn_resp_time_val,
+ qpn, resp_time_val);
+
+ if( osm_log_is_active( p_log, log_level ) )
+ {
+
+
ib_inform_info_get_qpn_resp_time(p_iir-inform_info.g_or_v.generic.qpn_resp_time_val,
+ qpn, resp_time_val);
+
+if (p_iir-inform_info.is_generic)
+{
+ osm_log( p_log, log_level,
+ InformInfo Record dump:\n
+ \t\t\t\tRID\n
+ \t\t\t\tSubscriberGID...0x%016 PRIx64 :
+ 0x%016 PRIx64 \n
+ \t\t\t\tSubscriberEnum..0x%X\n
+ \t\t\t\tInformInfo dump:\n
+ \t\t\t\tgid.0x%016 PRIx64 ,%016 PRIx64
\n
+ \t\t\t\tlid_range_begin.0x%X\n
+ \t\t\t\tlid_range_end...0x%X\n
+ \t\t\t\tis_generic..0x%X\n
+ \t\t\t\tsubscribe...0x%X\n
+ \t\t\t\ttrap_type...0x%X\n
+ \t\t\t\ttrap_num%u\n
+ \t\t\t\tqpn.0x%06X\n
+ \t\t\t\tresp_time_val...0x%X\n
+ \t\t\t\tnode_type...0x%06X\n
+ ,
+ cl_ntoh64( p_iir-subscriber_gid.unicast.prefix ),
+ cl_ntoh64( p_iir-subscriber_gid.unicast.interface_id ),
+ cl_ntoh16( p_iir-subscriber_enum ),
+ cl_ntoh64( p_iir-inform_info.gid.unicast.prefix ),
+ cl_ntoh64( p_iir-inform_info.gid.unicast.interface_id ),
+ cl_ntoh16( p_iir-inform_info.lid_range_begin ),
+ cl_ntoh16( p_iir-inform_info.lid_range_end ),
+ p_iir-inform_info.is_generic,
+ p_iir-inform_info.subscribe,
+ cl_ntoh16( p_iir-inform_info.trap_type ),
+ cl_ntoh16( p_iir-inform_info.g_or_v.generic.trap_num ),
+ cl_ntoh32(qpn),
+ resp_time_val,
+ cl_ntoh32(ib_inform_info_get_node_type( p_iir-inform_info ))
+ );
+}
+else
+{
+ osm_log( p_log, log_level,
+ InformInfo Record dump:\n
+ \t\t\t\tInformInfo dump:\n
+ \t\t\t\tRID\n
+ \t\t\t\tSubscriberGID...0x%016 PRIx64 :
+ 0x%016 PRIx64 \n
+ \t\t\t\tSubscriberEnum..0x%X\n
+ \t\t\t\tgid.0x%016 PRIx64 ,%016 PRIx64
\n
+ \t\t\t\tlid_range_begin.0x%X\n
+ \t\t\t\tlid_range_end...0x%X\n
+ \t\t\t\tis_generic..0x%X\n
+ \t\t\t\tsubscribe...0x%X\n
+ \t\t\t\ttrap_type...0x%X\n
+ \t\t\t\tdev_id..0x%X\n
+ \t\t\t\tqpn.0x%06X\n
+ \t\t\t\tresp_time_val..0x%X\n
+ \t\t\t\tvendor_id...0x%06X\n
+ ,
+ cl_ntoh64( p_iir-subscriber_gid.unicast.prefix ),
+ cl_ntoh64( p_iir-subscriber_gid.unicast.interface_id ),
+ cl_ntoh16( p_iir-subscriber_enum ),
+ cl_ntoh64( p_iir-inform_info.gid.unicast.prefix ),
+ cl_ntoh64( p_iir-inform_info.gid.unicast.interface_id ),
+ cl_ntoh16( p_iir-inform_info.lid_range_begin ),
+ cl_ntoh16( p_iir-inform_info.lid_range_end ),
+ p_iir-inform_info.is_generic,
+ p_iir-inform_info.subscribe,
+ cl_ntoh16( p_iir-inform_info.trap_type ),
+ cl_ntoh16( p_iir-inform_info.g_or_v.vend.dev_id ),
+
Re: [openib-general] [PATCH] [MINOR] OpenSM/osm_helper: Add support for dump of SAInformInfoRecord
Sure - thanks Eitan Zahavi ___ 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 38 of 39] IB/ipath - More changes to support InfiniPath on PowerPC 970 systems
Hi, Please fix the generic code if it doesn't provide the facility you need at the moment. Don't shoe horn it into your driver just to make up for that. Ive had 3 drivers asking for write combining recently so I agree this is a good idea. How about ioremap_wc as suggested by Willy: http://marc.theaimsgroup.com/?l=linux-kernelm=114374741828040w=2 Anton ___ 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 165] IBWSD.DLL crashes when accessing g_pm_stat.pdata[INTR_TOTAL]
http://openib.org/bugzilla/show_bug.cgi?id=165 --- Comment #1 from [EMAIL PROTECTED] 2006-07-03 15:30 --- (In reply to comment #0) The following line: InterlockedIncrement64( g_pm_stat.pdata[INTR_TOTAL] ); Cause a crash in the function ib_cq_thread() When compiling WSD without performance counter, the app runs succssfully. I couldn't debug the application (yet). Can you provide a backlog, or any information about the crash? Information like the exception code and the address of the variable passed to the function would help. - Fab --- 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
[openib-general] [PATCH] mthca: initialize send and receive queue locks separately
mthca: initialize send and receive queue locks separately
lockdep identifies a lock by the call site of its initialization. By
initializing the send and receive queue locks in mthca_wq_init() we confuse
lockdep. It warns that that the ordered acquiry of both locks in
mthca_modify_qp() is recursive acquiry of one lock:
=
[ INFO: possible recursive locking detected ]
-
modprobe/1192 is trying to acquire lock:
(wq-lock){}, at: [f892b4db] mthca_modify_qp+0x60/0xa7b [ib_mthca]
but task is already holding lock:
(wq-lock){}, at: [f892b4ce] mthca_modify_qp+0x53/0xa7b [ib_mthca]
Initializing the locks separately in mthca_alloc_qp_common() stops the warning
and will let lockdep enforce proper ordering on paths that acquire both locks.
Signed-off-by: Zach Brown [EMAIL PROTECTED]
---
drivers/infiniband/hw/mthca/mthca_qp.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: 2.6.17-mm6/drivers/infiniband/hw/mthca/mthca_qp.c
===
--- 2.6.17-mm6.orig/drivers/infiniband/hw/mthca/mthca_qp.c 2006-07-03
08:41:16.0 -0400
+++ 2.6.17-mm6/drivers/infiniband/hw/mthca/mthca_qp.c 2006-07-03
10:05:52.0 -0400
@@ -224,7 +224,7 @@
static void mthca_wq_init(struct mthca_wq *wq)
{
- spin_lock_init(wq-lock);
+ /* mthca_alloc_qp_common() initializes the locks */
wq-next_ind = 0;
wq-last_comp = wq-max - 1;
wq-head = 0;
@@ -1114,6 +1114,9 @@
qp-sq_policy= send_policy;
mthca_wq_init(qp-sq);
mthca_wq_init(qp-rq);
+ /* these are initialized separately so lockdep can tell them apart */
+ spin_lock_init(qp-sq.lock);
+ spin_lock_init(qp-rq.lock);
ret = mthca_map_memfree(dev, qp);
if (ret)
___
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
