[ewg] ofa_1_5_kernel 20100602-0200 daily build status
This email was generated automatically, please do not reply git_url: git://git.openfabrics.org/ofed_1_5/linux-2.6.git git_branch: ofed_kernel_1_5 Common build parameters: Passed: Passed on i686 with linux-2.6.19 Passed on i686 with linux-2.6.18 Passed on i686 with linux-2.6.21.1 Passed on i686 with linux-2.6.26 Passed on i686 with linux-2.6.24 Passed on i686 with linux-2.6.22 Passed on i686 with linux-2.6.27 Passed on x86_64 with linux-2.6.16.60-0.54.5-smp Passed on x86_64 with linux-2.6.16.60-0.21-smp Passed on x86_64 with linux-2.6.18 Passed on x86_64 with linux-2.6.18-128.el5 Passed on x86_64 with linux-2.6.18-194.el5 Passed on x86_64 with linux-2.6.18-164.el5 Passed on x86_64 with linux-2.6.19 Passed on x86_64 with linux-2.6.18-93.el5 Passed on x86_64 with linux-2.6.21.1 Passed on x86_64 with linux-2.6.20 Passed on x86_64 with linux-2.6.22 Passed on x86_64 with linux-2.6.26 Passed on x86_64 with linux-2.6.24 Passed on x86_64 with linux-2.6.25 Passed on x86_64 with linux-2.6.27 Passed on x86_64 with linux-2.6.27.19-5-smp Passed on x86_64 with linux-2.6.9-78.ELsmp Passed on x86_64 with linux-2.6.9-67.ELsmp Passed on x86_64 with linux-2.6.9-89.ELsmp Passed on ia64 with linux-2.6.18 Passed on ia64 with linux-2.6.19 Passed on ia64 with linux-2.6.21.1 Passed on ia64 with linux-2.6.23 Passed on ia64 with linux-2.6.22 Passed on ia64 with linux-2.6.26 Passed on ia64 with linux-2.6.24 Passed on ia64 with linux-2.6.25 Passed on ppc64 with linux-2.6.18 Passed on ppc64 with linux-2.6.19 Failed: ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH] librdmacm: support 2.6.9
Hefty, Sean wrote: This should fix the OFED build errors on RH 4.x. When testing this on a RH 4.x system, I noticed additional build warnings on 32-bit systems. I'll add a fix for these warnings separately. There's a daily build of the librdmacm which should fix both of these issues. The build is at: openfabrics.org/home/shefty/src/topdir/SOURCES/ Let me know if you need anything else. I'll release 1.0.13 closer to the actual OFED 1.5.2 release, once any other bug fixes have been incorporated. - Sean Hi Sean, I pulled this tarball (librdmacm-1.0.12-0.1.gc9ce9d4.tar.gz) into OFED. librdmacm compilation passed on RHEL4.8. Thanks, Vladimir ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] Allowing ib dignostics to be run without being logged in as root.
$ cat /etc/udev/rules.d/80-ib-umad.rules KERNEL==umad*, NAME=infiniband/%k, MODE=0666 It is not the same. Your propose to expose /dev/infiniband/umad device access to all world, which is obviously even more dangerous than SUIDing diagnostic programs. Well, different threats. Making umad files world-writable means anyone can inject whatever MADs they want to into the fabric. On the other hand, if an arbitrary code execution security hole is found in a diagnostic program, then having it SUID root means the hole becomes a local root exploit. It's hard to assess which is really more dangerous. -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Compile bug on OFED-1.5.2-rc1 on Itanium
I get the following compile error when trying to build OFED_1.5.2-rc1 on Itanium. Not sure if PSM is supported on Itanium, if not, probably should not try to build it when the target architecture is IA64. make[1]: Entering directory `/var/tmp/OFED_topdir/BUILD/infinipath-psm-1.13/ipath' gcc -Wall -O3 -g3 -fpic -fPIC -funwind-tables -D_GNU_SOURCE -D_GNU_SOURCE -I. -I../include -I../mpspawn -I../include/linux-ia64 -I../ptl_ips -c ipath_debug.c -o ipath_debug.o In file included from ../include/ipath_user.h:59, from ipath_debug.c:46: ../include/ipath_intf.h:46:20: error: sysdep.h: No such file or directory ../include/ipath_intf.h:47:21: error: bit_ops.h: No such file or directory In file included from ipath_debug.c:46: ../include/ipath_user.h: In function 'ipath_get_rcvhdrtail': ../include/ipath_user.h:313: warning: implicit declaration of function 'ips_rmb'../include/ipath_user.h: In function 'get_nanoseconds': ../include/ipath_user.h:488: warning: implicit declaration of function 'get_cycles' ipath_debug.c:109:2: warning: #warning No stack pointer or instruction pointer for this arch make[1]: *** [ipath_debug.o] Error 1 ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Re: [ewg] [PATCH v2] libibverbs: ibv_fork_init() and libhugetlbfs
without patch: 1M memory region120usec 16M memory region 1970usec with patch v2: 1M memory region172usec 16M memory region 2030usec So if I read this correctly this patch introduces almost a 50% overhead in the 1M case... and probably much worse (as a fraction) in say the 64K or 4K case. I wonder if that's acceptable? Alex's original approach was to try the memadvise with normal page size and then fall back to huge page size if that failed. But of course that wastes some time on the failed madvise in the hugepage case. I think it would be interesting to compare timings for registering, say, 4K, 64K, 1M and 16M regions with and without huge page backing, for three possibilities: - unpatched libibverbs (will obviously fail on hugepage backed regions) - patched with this v2 - alternate patch that tries madvise and only does your /proc/pid/smaps - parsing if the first madvise fails. - R. -- Roland Dreier rola...@cisco.com || For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
