[02-03-10] WinOF 2.2 RC3 Release Download @ http://www.openfabrics.org/downloads/WinOF/v2.2_RC3
Please address comments and concerns to https://bugs.openfabrics.org and/or the Windows OpenFabrics email list [email protected] WinOF 2.2 RC0 released @ svn.2642 WinOF 2.2 RC1 released @ svn.2654 WinOF 2.2 RC2 released @ svn.2667 WinOF 2.2 RC3 released @ svn.2698 Changes since RC2 ----------------- Revision: 2670 Author: stansmith Date: 3:13:42 PM, Friday, January 15, 2010 Message: [WINVERBS,ND,WINMAD,MAD] delete critical sections when no longer needed. To avoid leaking memory, we need to call DeleteCriticalSection for all critical sections once they are no longer needed. Signed-off-by: Sean Hefty <[email protected]> ---- Modified : /gen1/branches/WOF2-2/core/winmad/user/wm_provider.cpp Modified : /gen1/branches/WOF2-2/core/winverbs/user/wv_base.cpp Modified : /gen1/branches/WOF2-2/ulp/libibumad/src/umad.cpp Modified : /gen1/branches/WOF2-2/ulp/netdirect/user/nd_adapter.cpp Revision: 2677 Author: stansmith Date: 3:02:38 PM, Friday, January 22, 2010 Message: [LIBIBUMAD] libibumad: fix freeing wrong memory on failure umad_get_ca() should free the allocated 'ports' memory on failure, not the ca structure, which is provided by the user. Bug reported by Leonid Keller. Signed-off-by: Sean Hefty <[email protected]> ---- Modified : /gen1/branches/WOF2-2/ulp/libibumad/src/umad.cpp Revision: 2678 Author: stansmith Date: 3:05:49 PM, Friday, January 22, 2010 Message: [CORE] ib/mad: fix routing of vendor mads. SVN commit 2174 introduced an error that resulted in all vendor MADs being routed to the local HCA driver. This results in the ib-diag vendstat failing to receive a response when trying to gather statistics about a remote device. We should only route vendor mads to the local HCA if the mad is one of the mellanox vendor classes, the mad is not a response, and the local HCA is the destination for the mad. Simplify both the send and receive processing to be consistent in vendor mad handling. Problem reported by Mohammad Sawalha. Signed-off-by: Sean Hefty <[email protected]> ---- Modified : /gen1/branches/WOF2-2/core/al/kernel/al_smi.c Revision: 2679 Author: stansmith Date: 3:08:40 PM, Friday, January 22, 2010 Message: [WINVERBS} winverbs/ep: handle receiving REQ then DREQ. For fast connections, it's possible to receive a DREQ immediately after receiving a REQ, without an RTU coming in between. If we've sent a REP to the REQ, then the DREQ should be treated as if the connection had been fully established. (The RTU could be delayed, and the communication established event is processed asynchronously, so there's no way to tell for certain.) This fixes an issue where the passive side Accept() call fails waiting for the RTU, but receives a DREQ instead. Signed-off-by: Sean Hefty <[email protected]> ---- Modified : /gen1/branches/WOF2-2/core/winverbs/kernel/wv_ep.c Revision: 2680 Author: stansmith Date: 3:11:37 PM, Friday, January 22, 2010 Message: [WINVERBS] winverbs/lib: cache pkey table. Connection establishment rates take a huge performance hit as a result of using FindPkey, which results in querying the HCA to lookup current pkey information. Add a cache to the userspace library for pkey information. The cache is updated using the CWVDevice:Notify() routine. Before any access is made to the cache, the caller checks for changes to the partition tables. If a change is found, then the cache is updated. Otherwise, the cache is accessed to map pkey values to indices. This results in the connection rate over winverbs almost doubling. Signed-off-by: Sean Hefty <[email protected]> ---- Modified : /gen1/branches/WOF2-2/core/winverbs/user/wv_device.cpp Modified : /gen1/branches/WOF2-2/core/winverbs/user/wv_device.h Revision: 2684 Author: stansmith Date: 12:31:36 PM, Tuesday, January 26, 2010 Message: [DAPL2] libibverbs/device: destroy completion channel when closing device. ibv_close_device should destroy the completion channel when closing the device and freeing the memory. trunk/ulp/libibverbs/src/device.cpp dapl: move close device after async thread is done using it. Before calling ibv_close_device, wait for the asynchronous processing thread to finish using the device. This prevents a use after free error. trunk/ulp/dapl2/dapl/openib_cma/device.c trunk/ulp/dapl2/dapl/openib_scm/device.c librdmacm: set private_data_len. Set the private_data_len for reported events. This allows DAPL to use the value when copying private data. trunk/ulp/librdmacm/include/rdma/rdma_cma.h trunk/ulp/librdmacm/src/cma.cpp dapl: quick fix for wrong private data size. DAPL expects the private data size to be up to 256 bytes, but on windows the private data size is limited to 56 bytes. As a result, DAPL can access memory beyond the end of what's allocated. A more 'correct' fix is being submitted upstream to dapl. This is a simpler fix for the Windows 2.2 release only. trunk/ulp/dapl2/dapl/openib_cma/cm.c dapl/cma: fix referencing freed address DAPL uses a pointer to reference the local and remote addresses of an endpoint. It expects that those addresses are located in memory that is always accessible. Typically, for the local address, the pointer references the address stored with the DAPL HCA device. However, for the cma provider, it changes this pointer to reference the address stored with the rdma_cm_id. This causes a problem when that endpoint is connected on the passive side of a connection. When connect requests are given to DAPL, a new rdma_cm_id is associated with the request. The DAPL code replaces the current rdma_cm_id associated with a user's endpoint with the new rdma_cm_id. The old rdma_cm_id is then deleted. But the endpoint's local address pointer still references the address stored with the old rdma_cm_id. The result is that any reference to the address will access freed memory. Fix this by keeping the local address pointer always pointing to the address associated with the DAPL HCA device. This is about the best that can be done given the DAPL interface design. trunk/ulp/dapl2/dapl/openib_common/qp.c Signed-off-by: Sean Hefty <[email protected]> ---- Modified : /gen1/branches/WOF2-2/ulp/dapl2/dapl/openib_cma/cm.c Modified : /gen1/branches/WOF2-2/ulp/dapl2/dapl/openib_cma/device.c Modified : /gen1/branches/WOF2-2/ulp/dapl2/dapl/openib_common/qp.c Modified : /gen1/branches/WOF2-2/ulp/dapl2/dapl/openib_scm/device.c Modified : /gen1/branches/WOF2-2/ulp/libibverbs/src/device.cpp Modified : /gen1/branches/WOF2-2/ulp/librdmacm/include/rdma/rdma_cma.h Modified : /gen1/branches/WOF2-2/ulp/librdmacm/src/cma.cpp Revision: 2696 Author: stansmith Date: 3:00:07 PM, Wednesday, February 03, 2010 Message: [LIBIBVERBS] reorder sequence to be correct ---- Modified : /gen1/branches/WOF2-2/ulp/libibverbs/src/device.cpp Revision: 2697 Author: stansmith Date: 3:04:54 PM, Wednesday, February 03, 2010 Message: [IPOIB_NDIS6_CM] use SHUTTER data structure to eliminate the problem when IPoIB continues to receive packets during shutdown/halt process. Signed-off-by: Alex Naslednikov [[email protected]] ---- Modified : /gen1/branches/WOF2-2/ulp/ipoib_NDIS6_CM/kernel/ipoib_adapter.cpp Modified : /gen1/branches/WOF2-2/ulp/ipoib_NDIS6_CM/kernel/ipoib_adapter.h Modified : /gen1/branches/WOF2-2/ulp/ipoib_NDIS6_CM/kernel/ipoib_driver.cpp Modified : /gen1/branches/WOF2-2/ulp/ipoib_NDIS6_CM/kernel/ipoib_port.cpp WinOF Release Summary ----------------- 1) The WinOF 2.2 release is based on openib-windows source svn revision (branches\WOF2-2 svn.2698). Last WinOF release (2.1) based on svn.2476. 2) Features Installers available for Windows 7 & Server 2008 R2 NDIS 6 IPoIB for Server 2008, Svr 2008 R2, Windows 7 and Vista. NDIS 5.1 IPoIB for Server 2003 & XP. uDAPL 2.0.25 code base: No longer supporting uDAT/uDAPL version 1.0, uDAT/uDAPL version 2.0 only. OpenSM upgraded to version 3.3.3 (see %windir%\temp\osm.log for SM operational details). WinOF installer upgraded to WIX 3.0 ND/winverbs provider available as a technology preview. ND/IBAL is the installed 'default' provider, see ndinstall -h to change provider. 2) Bug fixes in IB Core IPoIB WSD DAT/DAPL WinVerbs WinMAD OFED (Open Fabrics Enterprise Distribution [Linux]) verbs API IPoIB SRP WinOF Installer manual **** Known Issues **** HCA drivers are reclassified as BOOT_START drivers to support booting from an SRP IOC. An unfortunate side-effect is when WinOF 2.2 is installed on a system for the first time, after installation a mandatory reboot is Required by Windows. After the WinOF.msi file has started installation, an errant "Welcome to the Found New Hardware Wizard" window 'may' popup; XP & Svr 2003. Just ignore or 'cancel' the errant FNHW popup window in order to proceed with the installation. XP requires a cancel, for WLH & WNET, the notifier will disappear on their own. You do need to answer 'Yes' or 'Continue' to popup windows which refer to Non-Logo'ed (aka, Non-WHQL'ed) drivers being installed. If the install appears to hang, look around for popup windows requesting input which are covered by other windows. Such is the case on Server 2008 initial install - Answer 'yes' to always trust the OpenFabrics Alliance as a SW publisher. Please: Read the Release_notes.htm file! make 'sure' your HCA firmware is recent: vstat.exe displays HCA firmware version & PSID. flint.exe (found in the Mellanox firmware tools package) displays PSID. Thank you, WinOF Developers. _______________________________________________ ofw mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ofw
