Re: [openib-general] PXE + infiniband?
On Fri, 2006-09-01 at 14:51 -0400, Cain, Brian (GE Healthcare) wrote: > A while back > (http://openib.org/pipermail/openib-general/2005-September/010801.html) > there was mention of putting PXE stuff on an HCA. Has anyone done this > with PXELINUX? It doesn't seem like it's as straightforward as just > putting the stock PXELINUX image on your HCA. I'm assuming this image > would have to recognize the HCA and bring up IPoIB in order to use the > conventional TFTP transport? There is an implementation of PXE for Mellanox's HCAs that can be found here: http://sourceforge.net/forum/forum.php?forum_id=494529 ___ 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] OpenSM/osm_log API: Use symbol versionsrather than polluting namespace
Quoting r. Doug Ledford <[EMAIL PROTECTED]>: > Subject: Re: [openib-general] OpenSM/osm_log API: Use symbol versionsrather > than polluting namespace > > On Wed, 2006-09-06 at 18:16 +0300, Michael S. Tsirkin wrote: > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > Subject: Re: OpenSM/osm_log API: Use symbol versions rather than > > > polluting namespace > > > > > > On Wed, 2006-09-06 at 09:42, Michael S. Tsirkin wrote: > > > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > > > Subject: OpenSM/osm_log API: Use symbol versions rather than > > > > > polluting namespace > > > > > > > > > > OpenSM/osm_log API: Rather than polluting the namespace with needless > > > > > symbols, use symbol versions and have a versioned osm_log_init rather > > > > > than adding osm_log_init_v2 as an additional API > > > > > > > > > > This patch is intended to be applied to both trunk and 1.1 versions. > > > > > > > > > > Signed-off-by: Doug Ledford <[EMAIL PROTECTED]> > > > > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> > > > > > > > > This preserves the ABI, but would this not break the API? > > > > > > Yes, this patch changes the API (in a most trivial way). > > > > So all users need to change code or they won't compile against the new > > library? > > Yes, and that is the correct way to handle this change. I disagree. In my opinion, asking all users to add a parameter they don't care about is worse than having multiple functions with a convenient set of options. And if there is a low cost way to help apps compile without code change, I don't see why it makes sense to create work. Even if this were a good idea, I don't think introducing a flag day for all users without warning is as good way to extend library APIs. I would expect at least one release where both new and old functions are available. > I could see > leaving the whole log init change out entirely, but if it's going to go > in, this is the right way to do it. Maybe it should be left out. Whether the issue this addresses is critical for release is Hal's call. But if the change affects other modules I think it's clear we won't be able to take the fix. > > Not sure what do you mean by upward compatible. This API change does not > > seem to > > be backward compatible - won't it break building dependent applications? > > If so is not something you should do after code freeze. > > APIs change. APIs should not change with every release. > Any app you can build can compensate. Sure it seems simple if you are RedHat and rebuild the whole OS. However, let us look at an application vendor that cares about portability. What this "trivial" change involves is: 1. add a configure hook to check library version installed 2. define an approprite macro 3. add a wrapper in header file to call the appropriate function 4. update the application to use the wrapper instead of the function directly All this after a supposed code freeze. > The goal is to keep > apps that aren't recompiled working, and to make apps that are > recompiled compliant with the latest version of the function. We are past code freeze. I agree with Hal that it might be hard to draw a line between a critical and a non-critical bugfix. However, an API change that 1. is purely cosmetical 2. requires code changes in dependent applications 3. is not uncontroversial is, for me, obviously beyond that line. -- MST ___ 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 222] ib_uverbs fails to load on ia64, OFED 1.1 - rc3
http://openib.org/bugzilla/show_bug.cgi?id=222 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from [EMAIL PROTECTED] 2006-09-06 23:04 --- A fix was done in the way page shift are calculated in Itanium. Will be part of RC4 --- 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] ibv_poll_cq after ibv_post_send does not work
Hi Thomas. Bub Thomas wrote: > > I’m still in the process of porting my gen1 code to gen2. > > As mentioned yesterday I can connect to a listener on the same machine > using libibcm. > > Doing this I have to do the ibv_modify_qp by myself to get the qp’s > from INIT via RTR to RTS on both sides. > > At least the ibv_modify_qp doesn not complain when having done the > connection via the libibcm. > > So my assumption is I have my two qp’s successfully connected. > > First action after the connection is the listener to wait on it’s > receive cq for an IBV_WR_SEND done by the connector. > > Here is now the problem: > > · The listener never gets a completion > > · The connector doing the IBV_WR_SEND does get error on the send cq like > opcode=0x7f status=0x5 vendor_err=129 for the first IBV_WR_SEND and > opcode=0x7f status=0xc vendor_err=129 for all sub-sequent attempt to > send the data > > Is there anyone out there who can help me out to understand the error > codes and or to understand what is wrong? > > Thanks in advance from Germany > > Thomas > Which QP do you use (RC/UC/UD)? do you get any completion in the connector side? If you are using RC QP: the reason for not getting any completion in the CQ is that Did you post any RR (Receive Request) at the listener side? rnr_retry =7 means that in case of RNR retry there will be infinite retries if the timeout = 0 and the remote QP is not ready then there won't be any retransmition. Dotan ___ 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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
On Wed, 2006-09-06 at 18:16 +0300, Michael S. Tsirkin wrote: > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > Subject: Re: OpenSM/osm_log API: Use symbol versions rather than polluting > > namespace > > > > On Wed, 2006-09-06 at 09:42, Michael S. Tsirkin wrote: > > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > > Subject: OpenSM/osm_log API: Use symbol versions rather than polluting > > > > namespace > > > > > > > > OpenSM/osm_log API: Rather than polluting the namespace with needless > > > > symbols, use symbol versions and have a versioned osm_log_init rather > > > > than adding osm_log_init_v2 as an additional API > > > > > > > > This patch is intended to be applied to both trunk and 1.1 versions. > > > > > > > > Signed-off-by: Doug Ledford <[EMAIL PROTECTED]> > > > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> > > > > > > This preserves the ABI, but would this not break the API? > > > > Yes, this patch changes the API (in a most trivial way). > > So all users need to change code or they won't compile against the new > library? Yes, and that is the correct way to handle this change. I could see leaving the whole log init change out entirely, but if it's going to go in, this is the right way to do it. > Not sure what do you mean by upward compatible. This API change does not seem > to > be backward compatible - won't it break building dependent applications? > If so is not something you should do after code freeze. APIs change. Any app you can build can compensate. The goal is to keep apps that aren't recompiled working, and to make apps that are recompiled compliant with the latest version of the function. -- Doug Ledford <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: This is a digitally signed message part ___ 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] [-mm patch] drivers/infiniband/hw/amso1100/: possible cleanups
Roland: Is there anything we know about that is still unresolved at this point? We've got a bunch of balls up in the air here and I want to make sure we haven't dropped one. Thanks, Tom On 9/5/06 5:39 PM, "Roland Dreier" <[EMAIL PROTECTED]> wrote: > Steve> Its old debug code that isn't used anywhere. It would be > Steve> nice to keep it around, but if you really don't want it, > Steve> nuke it... > > No, that's fine, I'll leave it inside the #if 0. > > - R. ___ 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] OFED 1.1-rc3 is ready
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > I spoke with our MPI team lead and it is very likely that the fix that > is in 2.0.1-refresh did not make it into 3.0 beta, but it should be > in the 3.0 release schedule to be completed in a couple of weeks. OK then - I'll wait for that. Regards, Robert. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iQEVAwUBRP9kyfzvnpzTd9fxAQJu/wf+PEjyS1xAKzmXD+oZJxUNNeaW7QpqKz3h zc370m74yIWjI+8GianGN4VM6Zx4InPdsRbGNGTd+FRhmZvYDhuuo8VBQUDdAZdB Tkm+PomDIWdftj8cWCsiah4UkhzRv//83TiIkGZ5+zk25qOvQ6VAW4fy6vpJhKvo uTW9Sow/G/BAIuMZ8wwg5Jyz5kbYxDxr+21jzQ+nblM/6YdGVco3GI1/z/dXwK5V JEPIEu4ZxExOU9yGqS/hculq2Z9WFyGTBYoll67KkhpOuLUxiCxCxStA8Z0x52fG OIhL0vKYgiOWLZnxZONRsy89OR/mUV7SNZeOZVqJSqMh7SpeLWWYHQ== =SRiy -END PGP SIGNATURE- ___ 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] OFED 1.1-rc3 is ready
Robert Walsh wrote, >> I rebuilt OFED from scratch with the patch, and ran successfully on >> Intel MPI 2.0.1 with the refresh patch. I could not get it to run on >> Intel MPI 3.0b. If you could verify that the fix you mentioned that is >> in the 2.0.1 refresh patch also made it into 3.0b, I'd appreciate it. >> If you have a later beta version you could send me, that would be great, >> too. >> >> Regards, >> Robert. I spoke with our MPI team lead and it is very likely that the fix that is in 2.0.1-refresh did not make it into 3.0 beta, but it should be in the 3.0 release schedule to be completed in a couple of weeks. woody ___ 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 222] New: ib_uverbs fails to load on ia64, OFED 1.1 - rc3
http://openib.org/bugzilla/show_bug.cgi?id=222 Summary: ib_uverbs fails to load on ia64, OFED 1.1 - rc3 Product: OpenFabrics Linux Version: 1.1rc3 Platform: IA64 OS/Version: RHEL 4 Status: NEW Severity: blocker Priority: P1 Component: Verbs AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] OFED 1.1-rc3 ib_uverbs fails to load on Itanium on RHEL4-U3, due to unknown symbol hpage_shift. This is a new bug that did not happen with OFED 1.1-rc2. /etc/init.d/openibd start Loading HCA driver and Access Layer: [FAILED] Please open an issue in the http://openib.org/bugzilla and attach /tmp/ib_debug_info.log > dmesg ib_mthca: Mellanox InfiniBand HCA driver v0.08 (February 14, 2006) ib_mthca: Initializing :0d:00.0 ACPI: PCI interrupt :0d:00.0[A] -> GSI 76 (level, low) -> IRQ 58 ib_mthca :0d:00.0: HCA FW version 3.3.2 is old (3.4.0 is current). ib_mthca :0d:00.0: If you have problems, try updating your HCA FW. ib_uverbs: Unknown symbol hpage_shift divert: not allocating divert_blk for non-ethernet device ib0 divert: not allocating divert_blk for non-ethernet device ib1 ip_tables: (C) 2000-2002 Netfilter core team ib0: no IPv6 routers present --- 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] Reduce packet loss in receive path, OFED 1.1
Hi, Tziporet - This is another patch for RC4, which reduces the likelihood of packet loss when the receiver is being saturated with packets. Please apply. Thanks, IB/ipath - use memcpy_cachebypass to reduce packet loss In cases where a large incoming RDMA is being received, we have to copy data inside the interrupt handler before we can ACK each packet. The source is DMAed to by the hardware, which means that the CPU won't have it cached. We only read the source this one time; using normal load instructions pollutes the dcache with useless data, reducing performance to the point where we can lose a significant number of packets. We use memcpy_cachebypass to try to not fill the dcache with useless data. Avoiding the cache refill penalty lets us keep up better with the sender, resulting in many fewer dropped packets. Signed-off-by: Ralph Campbell <[EMAIL PROTECTED]> Signed-off-by: Bryan O'Sullivan <[EMAIL PROTECTED]> diff -r d8eed27eaaa2 drivers/infiniband/hw/ipath/Makefile --- a/drivers/infiniband/hw/ipath/Makefile Wed Sep 06 13:26:27 2006 -0700 +++ b/drivers/infiniband/hw/ipath/Makefile Wed Sep 06 15:48:34 2006 -0700 @@ -31,4 +31,5 @@ ib_ipath-y := \ ipath_verbs.o ib_ipath-$(CONFIG_X86_64) += ipath_wc_x86_64.o +ib_ipath-$(CONFIG_X86_64) += memcpy_cachebypass_x86_64.o ib_ipath-$(CONFIG_PPC64) += ipath_wc_ppc64.o diff -r d8eed27eaaa2 drivers/infiniband/hw/ipath/ipath_verbs.c --- a/drivers/infiniband/hw/ipath/ipath_verbs.c Wed Sep 06 13:26:27 2006 -0700 +++ b/drivers/infiniband/hw/ipath/ipath_verbs.c Wed Sep 06 15:48:45 2006 -0700 @@ -40,6 +40,12 @@ #include "ipath_verbs.h" #include "ipath_common.h" +#ifdef __x86_64__ +void *memcpy_cachebypass(void *, const void *, __kernel_size_t); +#else +#define memcpy_cachebypass(a,b,c) memcpy((a),(b),(c)) +#endif + static unsigned int ib_ipath_qp_table_size = 251; module_param_named(qp_table_size, ib_ipath_qp_table_size, uint, S_IRUGO); MODULE_PARM_DESC(qp_table_size, "QP table size"); @@ -167,7 +173,7 @@ void ipath_copy_sge(struct ipath_sge_sta BUG_ON(len == 0); if (len > length) len = length; - memcpy(sge->vaddr, data, len); + memcpy_cachebypass(sge->vaddr, data, len); sge->vaddr += len; sge->length -= len; sge->sge_length -= len; diff -r d8eed27eaaa2 drivers/infiniband/hw/ipath/memcpy_cachebypass_x86_64.S --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/drivers/infiniband/hw/ipath/memcpy_cachebypass_x86_64.S Wed Sep 06 15:48:34 2006 -0700 @@ -0,0 +1,115 @@ + .text + .p2align 4,,15 + /* rdi destination, rsi source, rdx count */ + .globl memcpy_cachebypass + .type memcpy_cachebypass, @function +memcpy_cachebypass: + movq%rdi, %rax +.L5: + cmpq$15, %rdx + ja .L34 +.L3: + cmpl$8, %edx/* rdx is 0..15 */ + jbe .L9 +.L6: + testb $8, %dxl/* rdx is 3,5,6,7,9..15 */ + je .L13 + movq(%rsi), %rcx + addq$8, %rsi + movq%rcx, (%rdi) + addq$8, %rdi +.L13: + testb $4, %dxl + je .L15 + movl(%rsi), %ecx + addq$4, %rsi + movl%ecx, (%rdi) + addq$4, %rdi +.L15: + testb $2, %dxl + je .L17 + movzwl (%rsi), %ecx + addq$2, %rsi + movw%cx, (%rdi) + addq$2, %rdi +.L17: + testb $1, %dxl + je .L33 +.L1: + movzbl (%rsi), %ecx + movb%cl, (%rdi) +.L33: + ret +.L34: + cmpq$63, %rdx /* rdx is > 15 */ + ja .L64 + movl$16, %ecx /* rdx is 16..63 */ +.L25: + movq8(%rsi), %r8 + movq(%rsi), %r9 + addq%rcx, %rsi + movq%r8, 8(%rdi) + movq%r9, (%rdi) + addq%rcx, %rdi + subq%rcx, %rdx + cmpl%edx, %ecx /* is rdx >= 16? */ + jbe .L25 + jmp .L3 /* rdx is 0..15 */ + .p2align 4,,7 +.L64: + movl$64, %ecx +.L42: + prefetchnta 128(%rsi) + movq(%rsi), %r8 + movq8(%rsi), %r9 + movq16(%rsi), %r10 + movq24(%rsi), %r11 + subq%rcx, %rdx + movq%r8, (%rdi) + movq32(%rsi), %r8 + movq%r9, 8(%rdi) + movq40(%rsi), %r9 + movq%r10, 16(%rdi) + movq48(%rsi), %r10 + movq%r11, 24(%rdi) + movq56(%rsi), %r11 + addq%rcx, %rsi + movq%r8, 32(%rdi) + movq%r9, 40(%rdi) + movq%r10, 48(%rdi) + movq%r11, 56(%rdi) + addq%rcx, %rdi + cmpq%rdx, %rcx /* is rdx >= 64? */ + jbe .L42 + sfence + orl %edx, %edx + je .L33 + jmp .L5 +.L9: + jmp *.L12(,%rdx,8) /* rdx is 0..8 */ + .section.rodata + .align 8
Re: [openib-general] uDAPL patch
>Hi James, > >I don't know if you've been following the back-and-forth on >openib-general concerning the problems we've had running Intel MPI on >QLogic's adapters. Basically, between Arlin Davis and myself, we've >come up with a patch to uDAPL to fix some uninitialized fields returned >by dat_ia_query() that allows the InfiniPath adapters to work correctly. Committed in OpenFabrics (svn9315) and SourceForge (svn1411). Thanks, -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
Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tziporet Koren wrote: > Robert Walsh wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> >>> Here is a slightly modified patch for your attributes issue. Can you >>> give it a try? >>> >> >> I rebuilt OFED from scratch with the patch, and ran successfully on >> Intel MPI 2.0.1 with the refresh patch. I could not get it to run on >> Intel MPI 3.0b. If you could verify that the fix you mentioned that is >> in the 2.0.1 refresh patch also made it into 3.0b, I'd appreciate it. >> If you have a later beta version you could send me, that would be great, >> too. >> >> Regards, >> Robert. >> > I added this patch under fixes to OFED 1.1. Will be in RC4 Excellent. Thanks, Tziporet. Regards, Robert. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iQEVAwUBRP8V4fzvnpzTd9fxAQLZVAf+IYtLA2c7cBCbzih2Suy4AHUdD1CghC0U XL+iWjLo4TFbcUhBIrzwG4M72VQanqhNr2Qs3ZtfU2+qN6qKnSZXdejd7nYYOAsz 5LnrWa6Y+9Jfy3K/JOQ4wpjc3lWs3rvuzPTBhmEPcNHZk5+/m0gbfzYLdrc2djPp soyFSQpyLdpF0J5iY12EWiPYnFK7ConoqYHkTODZV8IjBJIImvDoScouIC+Uzi+x HlANIlneKa4/zQHNaK+3vZ6N7ZUq30quMZU6ICMI2gzFEzsEe/HxbtnraXfnXH1J NQ4mMOJNXwPVveNn1E9zA7IgFTMYsnGH080O5saloj2S6P6jb3PLXw== =mDD0 -END PGP SIGNATURE- ___ 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] Latency Problem with MT25204 HCAs
We are seeing a latency problem that seems to be specific to the Mellanox MT25204 HCA. We do not see the same problem with MT25208 HCAs running in MT23108 compatibility mode. The problem is demonstrated running multiple streams of ib_rdma_lat. On the SDR MT25208 HCA: typical latency 1 stream 3.70 usec 2 streams 4.47 usec 4 streams 6.74 usec On the DDR MT25204 HCA: typical latency 1 stream 3.03 usec 2 streams 7.36 usec 4 streams 22.4 usec Can anyone explain this behavior? We are running OFED 1.0 release on a pair of EM64T dual CPU nodes. ibstat output: CA 'mthca0' CA type: MT25208 (MT23108 compat mode) Number of ports: 2 Firmware version: 4.7.400 Hardware version: a0 Node GUID: 0x0005ad035950 System image GUID: 0x0005ad000100d050 Port 1: State: Active Physical state: LinkUp Rate: 10 Base lid: 21 LMC: 0 SM lid: 16 Capability mask: 0x02500a68 Port GUID: 0x0005ad035951 Port 2: State: Down Physical state: Polling Rate: 10 Base lid: 0 LMC: 0 SM lid: 0 Capability mask: 0x02500a68 Port GUID: 0x0005ad035952 CA 'mthca1' CA type: MT25204 Number of ports: 1 Firmware version: 1.0.800 Hardware version: a0 Node GUID: 0x0002c90200216e40 System image GUID: 0x0002c90200216e43 Port 1: State: Active Physical state: LinkUp Rate: 20 Base lid: 22 LMC: 0 SM lid: 22 Capability mask: 0x02500a6a Port GUID: 0x0002c90200216e41 -Don___ 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] [librdmacm] execuation of the the test udaddy is failing
> # udaddy >udaddy: starting server >librdmacm: Kernel ABI does not support requested port space. >udaddy: listen request failed >test complete >return status -93 UD QP and multicast support requires kernel ABI version 2. It appears that the kernel version running is 1. - 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] OpenSM/osm_log API: Use symbol versions rather than pollutingnamespace
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > Subject: Re: OpenSM/osm_log API: Use symbol versions rather than > pollutingnamespace > > On Wed, 2006-09-06 at 12:10, Michael S. Tsirkin wrote: > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > > > (which, as I understand it, is really only an issue because opensm can > > > > > log so much), > > > > > which is what this entire patch series was designed to > > > > > address. They are two different problem spaces. > > > > > > > > So ... wouldn't it be better to address the real issue? > > > > As I see it, the problem only appears if you activate opensm in the > > > > verbose > > > > mode. And the reason to run so for a long time is only if you suspect > > > > you'll > > > > want to debug something later, without killing opensm. > > > > > > Those patches are still pending and won't be in OFED 1,1, right ? > > > > Well, I donnu. If it's assumed reducing log size is important enough > > for 1.1, then maybe applying these patches are the way to go? > > Right now these also involve an API change and that patch is being > reworked (so they couldn't possibly make OFED 1.1 rc4). Actually I was under impression that that patch was preserving the exiting API (only extension). I hope we all agree API breakage isn't an option at this point. -- MST ___ 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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
On Wed, 2006-09-06 at 12:10, Michael S. Tsirkin wrote: > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > > (which, as I understand it, is really only an issue because opensm can > > > > log so much), > > > > which is what this entire patch series was designed to > > > > address. They are two different problem spaces. > > > > > > So ... wouldn't it be better to address the real issue? > > > As I see it, the problem only appears if you activate opensm in the > > > verbose > > > mode. And the reason to run so for a long time is only if you suspect > > > you'll > > > want to debug something later, without killing opensm. > > > > Those patches are still pending and won't be in OFED 1,1, right ? > > Well, I donnu. If it's assumed reducing log size is important enough > for 1.1, then maybe applying these patches are the way to go? Right now these also involve an API change and that patch is being reworked (so they couldn't possibly make OFED 1.1 rc4). -- 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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > (which, as I understand it, is really only an issue because opensm can > > > log so much), > > > which is what this entire patch series was designed to > > > address. They are two different problem spaces. > > > > So ... wouldn't it be better to address the real issue? > > As I see it, the problem only appears if you activate opensm in the verbose > > mode. And the reason to run so for a long time is only if you suspect you'll > > want to debug something later, without killing opensm. > > Those patches are still pending and won't be in OFED 1,1, right ? Well, I donnu. If it's assumed reducing log size is important enough for 1.1, then maybe applying these patches are the way to go? -- MST ___ 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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
On Wed, 2006-09-06 at 11:27, Michael S. Tsirkin wrote: > Quoting r. Doug Ledford <[EMAIL PROTECTED]>: > > Subject: Re: OpenSM/osm_log API: Use symbol versions rather than polluting > > namespace > > > > On Wed, 2006-09-06 at 10:14 -0400, Hal Rosenstock wrote: > > > On Wed, 2006-09-06 at 09:42, Michael S. Tsirkin wrote: > > > > > > Nor is this feature uncontroversial. Would not support for log rotation > > > > be better? > > > > If you are just going to do log rotation, then no need to change opensm, > > just add an appropriate logrotate.d/opensm file to the distribution. > > I guess opensm will need to be signalled to close/reopen the log file though. > No? > > > But, that doesn't address what to do if you hit a full filesystem > > condition, > > Since logs are compressed this should at least alleviate that. > what do other daemons do? > > > nor how to limit the size of a log file between rotations > > again, what do other daemons do? > > > (which, as I understand it, is really only an issue because opensm can > > log so much), > > which is what this entire patch series was designed to > > address. They are two different problem spaces. > > So ... wouldn't it be better to address the real issue? > As I see it, the problem only appears if you activate opensm in the verbose > mode. And the reason to run so for a long time is only if you suspect you'll > want to debug something later, without killing opensm. Those patches are still pending and won't be in OFED 1,1, right ? > So the ability to control verbosity at runtime There already is a way to do that. -- Hal > will be a better solution > it seems, and there are patches that do that. ___ 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] OpenSM/osm_log API: Use symbol versions rather than pollutingnamespace
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > It is an upward compatible change so is low risk. > > > > Not sure what do you mean by upward compatible. This API change does not > > seem to be backward compatible - won't it break building dependent > > applications? > > We are talking about 2 different changes. I was responding to your > comment about the addition of osm_log_init_v2 not being a bug fix, not > the symver patch on top of that. I'm mostly concerned with the symver patch. I think we can't do API changes at this stage in the release process. -- MST ___ 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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
On Wed, 2006-09-06 at 11:16, Michael S. Tsirkin wrote: > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > Subject: Re: OpenSM/osm_log API: Use symbol versions rather than polluting > > namespace > > > > On Wed, 2006-09-06 at 09:42, Michael S. Tsirkin wrote: > > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > > Subject: OpenSM/osm_log API: Use symbol versions rather than polluting > > > > namespace > > > > > > > > OpenSM/osm_log API: Rather than polluting the namespace with needless > > > > symbols, use symbol versions and have a versioned osm_log_init rather > > > > than adding osm_log_init_v2 as an additional API > > > > > > > > This patch is intended to be applied to both trunk and 1.1 versions. > > > > > > > > Signed-off-by: Doug Ledford <[EMAIL PROTECTED]> > > > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> > > > > > > This preserves the ABI, but would this not break the API? > > > > Yes, this patch changes the API (in a most trivial way). > > So all users need to change code or they won't compile against the new > library? > > > > Anyway, frankly, I do not see why was osm_log_init_v2 added into 1.1 at > > > all. > > > We are in code freeze, only critical fixes are supposed to be applied to > > > branch > > > at this stage. How was adding osm_log_init_v2 critical? > > > > There was a bug reported when the log filled up which started motivating > > these changes. > > As I see it, a bugzilla ticket does not automatically convert feature request > into a bug report. The issue is not exactly new, and people seem to have been > able to live with this. > > The enhancement will keep opensm friendly to appliance like devices that are > single task subnet managers. fine, but OFED by default will activate opensm > without this switch. It is another feature when this situation is encountered. It has been encountered and will be again. > Given all of the above, I don't see how can this be considered a critical bug > fix. > > > We had just missed the rc3 window for this. > > So that's a reason not to apply on branch unless it is critical. I've also seen other patches which do not meet this criteria go into 1.1. I know that's not a reason either. > > It is an upward compatible change so is low risk. > > Not sure what do you mean by upward compatible. This API change does not seem > to > be backward compatible - won't it break building dependent applications? We are talking about 2 different changes. I was responding to your comment about the addition of osm_log_init_v2 not being a bug fix, not the symver patch on top of that. > If so is not something you should do after code freeze. > > If we care about namespace pollution that much (and I don't really see an > issue) > do the changes on trunk. > > > > Nor is this feature uncontroversial. Would not support for log rotation > > > be better? > > > > Were there comments on the list before to this effect ? > > Hmm. Not explicitly. There were comments this is non-standard and > will surprise system administrators if activated. > http://thread.gmane.org/gmane.linux.drivers.openib/29195/focus=29199 Not sure exactly what email (and comment) you are referring to here. -- 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
[openib-general] ibv_poll_cq after ibv_post_send does not work
Title: ibv_poll_cq after ibv_post_send does not work I’m still in the process of porting my gen1 code to gen2. As mentioned yesterday I can connect to a listener on the same machine using libibcm. Doing this I have to do the ibv_modify_qp by myself to get the qp’s from INIT via RTR to RTS on both sides. At least the ibv_modify_qp doesn not complain when having done the connection via the libibcm. So my assumption is I have my two qp’s successfully connected. First action after the connection is the listener to wait on it’s receive cq for an IBV_WR_SEND done by the connector. Here is now the problem: · The listener never gets a completion · The connector doing the IBV_WR_SEND does get error on the send cq like opcode=0x7f status=0x5 vendor_err=129 for the first IBV_WR_SEND and opcode=0x7f status=0xc vendor_err=129 for all sub-sequent attempt to send the data Is there anyone out there who can help me out to understand the error codes and or to understand what is wrong? Thanks in advance from Germany Thomas Thomas Bub Grass Valley Germany GmbH Brunnenweg 9 64331 Weiterstadt, Germany Tel: +49 6150 104 147 Fax: +49 6150 104 656 Email: [EMAIL PROTECTED] www.GrassValley.com ___ 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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
Quoting r. Doug Ledford <[EMAIL PROTECTED]>: > Subject: Re: OpenSM/osm_log API: Use symbol versions rather than polluting > namespace > > On Wed, 2006-09-06 at 10:14 -0400, Hal Rosenstock wrote: > > On Wed, 2006-09-06 at 09:42, Michael S. Tsirkin wrote: > > > > Nor is this feature uncontroversial. Would not support for log rotation > > > be better? > > If you are just going to do log rotation, then no need to change opensm, > just add an appropriate logrotate.d/opensm file to the distribution. I guess opensm will need to be signalled to close/reopen the log file though. No? > But, that doesn't address what to do if you hit a full filesystem > condition, Since logs are compressed this should at least alleviate that. what do other daemons do? > nor how to limit the size of a log file between rotations again, what do other daemons do? > (which, as I understand it, is really only an issue because opensm can > log so much), > which is what this entire patch series was designed to > address. They are two different problem spaces. So ... wouldn't it be better to address the real issue? As I see it, the problem only appears if you activate opensm in the verbose mode. And the reason to run so for a long time is only if you suspect you'll want to debug something later, without killing opensm. So the ability to control verbosity at runtime will be a better solution it seems, and there are patches that do that. -- MST ___ 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] OpenSM/osm_base.h: Change OSM_DEFAULT_TMP_DIR to /var/logfor Linux
OK. I will need to update the ibdmchk utility to look by default for
osm.{fdbs,mcfdbs} and subnet.lst in the /var/tmp ...
I hope this is not targeting the OFED 1.1 as it must not be critical ...
Eitan Zahavi
Senior Engineering Director, Software Architect
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972-4-9593245
P.O. Box 586 Yokneam 20692 ISRAEL
> -Original Message-
> From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 06, 2006 6:09 PM
> To: openib-general@openib.org
> Cc: Eitan Zahavi
> Subject: [PATCH] OpenSM/osm_base.h: Change OSM_DEFAULT_TMP_DIR to
> /var/logfor Linux
>
> OpenSM/osm_base.h: Change OSM_DEFAULT_TMP_DIR to /var/log for Linux
>
> Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
>
> Index: include/opensm/osm_base.h
>
> ===
> --- include/opensm/osm_base.h (revision 9158)
> +++ include/opensm/osm_base.h (working copy)
> @@ -177,15 +177,14 @@ BEGIN_C_DECLS
> *
> * DESCRIPTION
> *Specifies the default temporary directory for the log file,
subnet.lst
> -* and the other log files (with the exception of osm.log for Linux
being
> -* in /var/log).
> +* and the other log files.
> *
> * SYNOPSIS
> */
> #ifdef __WIN__
> #define OSM_DEFAULT_TMP_DIR GetOsmTempPath() #else -#define
> OSM_DEFAULT_TMP_DIR "/tmp/"
> +#define OSM_DEFAULT_TMP_DIR "/var/log/"
> #endif
> /***/
>
>
___
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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > Subject: Re: OpenSM/osm_log API: Use symbol versions rather than polluting > namespace > > On Wed, 2006-09-06 at 09:42, Michael S. Tsirkin wrote: > > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > > Subject: OpenSM/osm_log API: Use symbol versions rather than polluting > > > namespace > > > > > > OpenSM/osm_log API: Rather than polluting the namespace with needless > > > symbols, use symbol versions and have a versioned osm_log_init rather > > > than adding osm_log_init_v2 as an additional API > > > > > > This patch is intended to be applied to both trunk and 1.1 versions. > > > > > > Signed-off-by: Doug Ledford <[EMAIL PROTECTED]> > > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> > > > > This preserves the ABI, but would this not break the API? > > Yes, this patch changes the API (in a most trivial way). So all users need to change code or they won't compile against the new library? > > Anyway, frankly, I do not see why was osm_log_init_v2 added into 1.1 at all. > > We are in code freeze, only critical fixes are supposed to be applied to > > branch > > at this stage. How was adding osm_log_init_v2 critical? > > There was a bug reported when the log filled up which started motivating > these changes. As I see it, a bugzilla ticket does not automatically convert feature request into a bug report. The issue is not exactly new, and people seem to have been able to live with this. The enhancement will keep opensm friendly to appliance like devices that are single task subnet managers. fine, but OFED by default will activate opensm without this switch. Given all of the above, I don't see how can this be considered a critical bug fix. > We had just missed the rc3 window for this. So that's a reason not to apply on branch unless it is critical. > It is an upward compatible change so is low risk. Not sure what do you mean by upward compatible. This API change does not seem to be backward compatible - won't it break building dependent applications? If so is not something you should do after code freeze. If we care about namespace pollution that much (and I don't really see an issue) do the changes on trunk. > > Nor is this feature uncontroversial. Would not support for log rotation > > be better? > > Were there comments on the list before to this effect ? Hmm. Not explicitly. There were comments this is non-standard and will surprise system administrators if activated. http://thread.gmane.org/gmane.linux.drivers.openib/29195/focus=29199 -- MST ___ 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/osm_base.h: Change OSM_DEFAULT_TMP_DIR to /var/log for Linux
OpenSM/osm_base.h: Change OSM_DEFAULT_TMP_DIR to /var/log for Linux Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> Index: include/opensm/osm_base.h === --- include/opensm/osm_base.h (revision 9158) +++ include/opensm/osm_base.h (working copy) @@ -177,15 +177,14 @@ BEGIN_C_DECLS * * DESCRIPTION * Specifies the default temporary directory for the log file, subnet.lst -* and the other log files (with the exception of osm.log for Linux being -* in /var/log). +* and the other log files. * * SYNOPSIS */ #ifdef __WIN__ #define OSM_DEFAULT_TMP_DIR GetOsmTempPath() #else -#define OSM_DEFAULT_TMP_DIR "/tmp/" +#define OSM_DEFAULT_TMP_DIR "/var/log/" #endif /***/ ___ 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] execuation of the the test udaddy is failing
Here are the machine/driver props: * Host Architecture : x86_64 Linux Distribution: SUSE Linux Enterprise Server 10 (x86_64) VERSION = 10 Kernel Version: 2.6.16.21-0.8-smp GCC Version : gcc (GCC) 4.1.0 (SUSE Linux) Memory size : 4045720 kB Driver Version: gen2_linux-20060905-1700 (REV=9264) HCA ID(s) : mthca0 HCA model(s) : 25218 FW version(s) : 5.1.927 Board(s) : MT_015001 * Here is the output of the test: # udaddy udaddy: starting server librdmacm: Kernel ABI does not support requested port space. udaddy: listen request failed test complete return status -93 executing the test mckey fails too because of the same problem: # mckey recv 239.0.0.2 librdmacm: Kernel ABI does not support requested port space. The tests rping and the ucmatose are passing with no problem. thanks Dotan ___ 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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
On Wed, 2006-09-06 at 10:14 -0400, Hal Rosenstock wrote: > On Wed, 2006-09-06 at 09:42, Michael S. Tsirkin wrote: > > Nor is this feature uncontroversial. Would not support for log rotation > > be better? If you are just going to do log rotation, then no need to change opensm, just add an appropriate logrotate.d/opensm file to the distribution. But, that doesn't address what to do if you hit a full filesystem condition, nor how to limit the size of a log file between rotations (which, as I understand it, is really only an issue because opensm can log so much), which is what this entire patch series was designed to address. They are two different problem spaces. -- Doug Ledford <[EMAIL PROTECTED]> GPG KeyID: CFBFF194 http://people.redhat.com/dledford Infiniband specific RPMs available at http://people.redhat.com/dledford/Infiniband signature.asc Description: This is a digitally signed message part ___ 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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
On Wed, 2006-09-06 at 09:42, Michael S. Tsirkin wrote: > Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > > Subject: OpenSM/osm_log API: Use symbol versions rather than polluting > > namespace > > > > OpenSM/osm_log API: Rather than polluting the namespace with needless > > symbols, use symbol versions and have a versioned osm_log_init rather > > than adding osm_log_init_v2 as an additional API > > > > This patch is intended to be applied to both trunk and 1.1 versions. > > > > Signed-off-by: Doug Ledford <[EMAIL PROTECTED]> > > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> > > This preserves the ABI, but would this not break the API? Yes, this patch changes the API (in a most trivial way). > Anyway, frankly, I do not see why was osm_log_init_v2 added into 1.1 at all. > We are in code freeze, only critical fixes are supposed to be applied to > branch > at this stage. How was adding osm_log_init_v2 critical? There was a bug reported when the log filled up which started motivating these changes. We had just missed the rc3 window for this. It is an upward compatible change so is low risk. > Nor is this feature uncontroversial. Would not support for log rotation > be better? Were there comments on the list before to this effect ? > So - why are all these changes going into 1.1 branch? See answers above. -- 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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > Subject: OpenSM/osm_log API: Use symbol versions rather than polluting > namespace > > OpenSM/osm_log API: Rather than polluting the namespace with needless > symbols, use symbol versions and have a versioned osm_log_init rather > than adding osm_log_init_v2 as an additional API > > This patch is intended to be applied to both trunk and 1.1 versions. > > Signed-off-by: Doug Ledford <[EMAIL PROTECTED]> > Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]> This preserves the ABI, but would this not break the API? Anyway, frankly, I do not see why was osm_log_init_v2 added into 1.1 at all. We are in code freeze, only critical fixes are supposed to be applied to branch at this stage. How was adding osm_log_init_v2 critical? Nor is this feature uncontroversial. Would not support for log rotation be better? So - why are all these changes going into 1.1 branch? -- MST ___ 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] problems to regiser memory as a reglar user on SLES9 SP3
Moshe Kazir wrote: > Hi Tziporet, > > I'm trying Ofed 1.1 rc3 on IBM js21 sles9sp3 ppc64. > > Install is stopped at the very beginning as 64-bit udev is missing. > > I tried to compile the udev...src.rpm supplied in sls9sp3 cd3 and failed > as result of compilation error. > > Did you test ofed 1.1 rc3 on ppc64. Can you advice me how to get 64-bit > udev ? > > We have here only one MAC PPC64 machine that can run only Fedora C4 thus this is the only system we check. Maybe Vlad can help but I think best if you approach Novel (Mois is their contact for OFED) Tziporet ___ 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] OpenSM/osm_log API: Use symbol versions rather than polluting namespace
OpenSM/osm_log API: Rather than polluting the namespace with needless
symbols, use symbol versions and have a versioned osm_log_init rather
than adding osm_log_init_v2 as an additional API
This patch is intended to be applied to both trunk and 1.1 versions.
Signed-off-by: Doug Ledford <[EMAIL PROTECTED]>
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: osm/opensm/libopensm.map
===
--- osm/opensm/libopensm.map(revision 9253)
+++ osm/opensm/libopensm.map(working copy)
@@ -3,7 +3,6 @@ OPENSM_1.3 {
osm_log;
osm_is_debug;
osm_log_init;
- osm_log_init_v2;
osm_mad_pool_construct;
osm_mad_pool_destroy;
osm_mad_pool_init;
@@ -55,3 +54,8 @@ OPENSM_1.3 {
osm_get_sm_mgr_state_str;
local: *;
};
+
+OPENSM_1.3.1 {
+ global:
+ osm_log_init;
+} OPENSM_1.3;
Index: osm/opensm/libopensm.ver
===
--- osm/opensm/libopensm.ver(revision 9158)
+++ osm/opensm/libopensm.ver(working copy)
@@ -6,4 +6,4 @@
# API_REV - advance on any added API
# RUNNING_REV - advance any change to the vendor files
# AGE - number of backward versions the API still supports
-LIBVERSION=2:0:1
+LIBVERSION=2:1:1
Index: osm/include/opensm/osm_log.h
===
--- osm/include/opensm/osm_log.h(revision 9251)
+++ osm/include/opensm/osm_log.h(working copy)
@@ -152,13 +152,13 @@ osm_log_construct(
* This function does not return a value.
*
* NOTES
-* Allows calling osm_log_init, osm_log_init_v2, osm_log_destroy
+* Allows calling osm_log_init, osm_log_destroy
*
* Calling osm_log_construct is a prerequisite to calling any other
-* method except osm_log_init or osm_log_init_v2.
+* method except osm_log_init.
*
* SEE ALSO
-* Log object, osm_log_init, osm_log_init_v2,
+* Log object, osm_log_init,
* osm_log_destroy
*/
@@ -196,25 +196,25 @@ osm_log_destroy(
* Log object.
* Further operations should not be attempted on the destroyed object.
* This function should only be called after a call to
-* osm_log_construct, osm_log_init, or osm_log_init_v2.
+* osm_log_construct, osm_log_init.
*
* SEE ALSO
* Log object, osm_log_construct,
-* osm_log_init, osm_log_init_v2
+* osm_log_init
*/
-/f* OpenSM: Log/osm_log_init_v2
+/f* OpenSM: Log/osm_log_init
* NAME
-* osm_log_init_v2
+* osm_log_init
*
* DESCRIPTION
-* The osm_log_init_v2 function initializes a
+* The osm_log_init function initializes a
* Log object for use.
*
* SYNOPSIS
*/
ib_api_status_t
-osm_log_init_v2(
+osm_log_init(
IN osm_log_t* const p_log,
IN const boolean_t flush,
IN const uint8_t log_flags,
@@ -249,27 +249,6 @@ osm_log_init_v2(
* osm_log_destroy
*/
-/f* OpenSM: Log/osm_log_init
-* NAME
-* osm_log_init
-*
-* DESCRIPTION
-* The osm_log_init function initializes a
-* Log object for use. It is a wrapper for osm_log_init_v2().
-*
-* SYNOPSIS
-*/
-ib_api_status_t
-osm_log_init(
- IN osm_log_t* const p_log,
- IN const boolean_t flush,
- IN const uint8_t log_flags,
- IN const char *log_file,
- IN const boolean_t accum_log_file );
-/*
- * Same as osm_log_init_v2() but without max_size parameter
- */
-
/f* OpenSM: Log/osm_log_get_level
* NAME
* osm_log_get_level
Index: osm/opensm/osm_log.c
===
--- osm/opensm/osm_log.c(revision 9257)
+++ osm/opensm/osm_log.c(working copy)
@@ -225,7 +225,7 @@ osm_is_debug(void)
}
ib_api_status_t
-osm_log_init_v2(
+osm_log_init_1_3_1(
IN osm_log_t* const p_log,
IN const boolean_t flush,
IN const uint8_t log_flags,
@@ -280,13 +280,18 @@ osm_log_init_v2(
return IB_ERROR;
}
+__asm__(".symver osm_log_init_1_3_1, osm_log_init@@OPENSM_1.3.1");
+
ib_api_status_t
-osm_log_init(
+osm_log_init_1_3(
IN osm_log_t* const p_log,
IN const boolean_t flush,
IN const uint8_t log_flags,
IN const char *log_file,
IN const boolean_t accum_log_file )
{
- return osm_log_init_v2( p_log, flush, log_flags, log_file, 0, accum_log_file
);
+ return osm_log_init_1_3_1( p_log, flush, log_flags, log_file, 0,
accum_log_file );
}
+
+__asm__(".symver osm_log_init_1_3, [EMAIL PROTECTED]");
+
Index: osm/opensm/osm_opensm.c
===
--- osm/opensm/osm_opensm.c (revision 9251)
+++ osm/opensm/osm_opensm.c (working copy)
@@ -180,9 +180,9 @@ osm_opensm_init(
/* Can't use log macros here, since we're initializing the log. */
osm_opensm_construct( p_osm );
- status = osm_log_init_v2( &p_osm->log, p_opt->force_log_flush,
-
Re: [openib-general] getting LOC_QP_OP_ERR with IPoIB - mstflint question
Quoting r. Moshe Kazir <[EMAIL PROTECTED]>: > Is it time to create a work arround that opens /proc/bus/pci/ And > always work ? But why isn't the driver loaded? -- MST ___ 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] problems to regiser memory as a reglar user on SLES9 SP3
Hi Tziporet, I'm trying Ofed 1.1 rc3 on IBM js21 sles9sp3 ppc64. Install is stopped at the very beginning as 64-bit udev is missing. I tried to compile the udev...src.rpm supplied in sls9sp3 cd3 and failed as result of compilation error. Did you test ofed 1.1 rc3 on ppc64. Can you advice me how to get 64-bit udev ? Moshe Moshe Katzir | +972-9971-8639 (o) | +972-52-860-6042 (m) Voltaire - The Grid Backbone www.voltaire.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tziporet Koren Sent: Tuesday, August 29, 2006 5:50 PM To: OPENIB Subject: [openib-general] problems to regiser memory as a reglar user on SLES9 SP3 Hi All, In testing today we found that on SLES9 SP3 memory locking as a regular user fails. Although I changed /etc/security/limits.conf and added the following two lines: * soft memlock * hard memlock Note that same change does work in SLES10. Another change I tried (that worked in gen1) was to add the following line to the file/etc/sysctl.conf: vm.disable_cap_mlock=1. However nothing helped in SLES9 Does anyone have any idea how to solve this? Thanks, Tziporet ___ 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
Re: [openib-general] [Openib-windows] File transfer performance options
Hi Paul, In the beginning of this mail thread you have described a problem of passing files from a Linux server to windows server. You have described many experiments that you did and the fact that the performance that you received was not as good as expected. In reply I have advised you to consider using SDP for this file transfers. if to summarize your answer in one sentence you said that SDP is still not ready. I would have loved to tell you that SDP is ready, but unfortunately the windows SDP is not a product yet. However, it is mature enough to start doing some measurements which is what I did. I have changed a simple benchmark program that I had to also write it's data to disk. As a disk I have used AMT Ramdisk (512 MB). I have run two instances of this program, and got the results of 578 MB/sec which is considerably higher than results that you have achieved using other experiments. (one client gave me 450 MB/sec) Please note that since data is being copied 3 times in this scenario, we are standing near the theoretical speed of the machine (one copy is from the HCA to the kernel buffer, another is from the kernel buffer to the application buffer, and that last copy is from the application buffer to the Ram Disk). It is true that the development road of your application might force you not to use SDP, as SDP is not in production right now, but if you can wait the extra time than please note that SDP can supply the BW. Thanks Tzachi > -Original Message- > From: Paul Baxter [mailto:[EMAIL PROTECTED] > Sent: Friday, September 01, 2006 1:11 AM > To: openib-windows@openib.org; Tzachi Dar > Subject: Re: [Openib-windows] File transfer performance options > > > > From: "Tzachi Dar" <[EMAIL PROTECTED]> There is one > thing that is missing from your mail, and that is if you want > to see the windows machine as some file server (for example > SAMBA, NFS, SRP), or are you ready to accept it as a normal > server. The big difference is that on the second option the > server can be running at user mode (for example FTP server). > < > > The windows machine has to list and then choose amongst a set > of files from our Linux system and retrieve only relevant > files e.g. those whose filename relates to particular time slots. > We prefer not to write a Linux 'client' application to do > this explicitly but would rather have the windows machine's > application access our data files directly. > A few application-level locks are in place so that we won't > be writing new files to our local disks at the same time as > the remote archiving accesses them. > > Other than that the main goal is to make the inter-OS (and > inter-company) interface as simple as possible. It currently > doesn't seem that there is a proven solution to support this > at any transfer rate that takes significant advantage of Infiniband. > > I've specced my disks for 200 MB/s and we have DDR cards etc. > (for other reasons!), just no means to flex their muscles too > easily using existing COTS infrastructure. > > > > When (the server application is) running at user mode, SDP > can be used as a socket provider. This means that > theoretically every socket application should run and enjoy > the speed of Infiniband. Currently there are two projects of > SDP under development: one is for Linux and the other for > Windows, so SDP can be used to allow machines from both types > to connect. > < > > The key here is 'theoretical'. IMHO, Linux-Linux and > Windows-Windows get a lot more testing and priority than a > Linux-Windows combination. (Which is fair enough if that's > where the market is.) > > We've been burnt by this not being robustly tested and proven > in reality in cross-platform cases. (Note that this was > before the current openfabrics windows driver initiative). > > > > Performance that we have measured on the windows platform, > using DDR cards was bigger than 1200 MB/Sec. (of course, this > data was from host memory, and not from disks). > < > > We've used SDP previously in our Linux message interface and > were very happy with the results. Then someone included an > old (v9 ) Solaris machine into the mix so even before we > tested on Windows, we ended up using sockets/gigabit ethernet > for command transfers. > > SDP as an option for other parts of our application (large > data transfers) took a big turn for the worse when the > previous Linux SDP implementation was mothballed without a > mature replacement. We've ended up writing our application to > use RDMA write directly now. > > Note that I'm not too critical of the way SDP went away since > I can appreciate the need to greatly simplify the Linux SDP > implementation, it did leave people like me in the lurch > however. I really appreciate the effort put into these things > by Michael Tsirkin et al. and look forward to the new code in OFED 1.1 > > > I'm also not sure that cross-platform operation of > high-performance I
Re: [openib-general] [PATCH] OFED 1.1-rc3 is ready
Robert Walsh wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > >> Here is a slightly modified patch for your attributes issue. Can you give it >> a try? >> > > I rebuilt OFED from scratch with the patch, and ran successfully on > Intel MPI 2.0.1 with the refresh patch. I could not get it to run on > Intel MPI 3.0b. If you could verify that the fix you mentioned that is > in the 2.0.1 refresh patch also made it into 3.0b, I'd appreciate it. > If you have a later beta version you could send me, that would be great, > too. > > Regards, > Robert. > I added this patch under fixes to OFED 1.1. Will be in RC4 Tziporet ___ 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] getting LOC_QP_OP_ERR with IPoIB - mstflint question
I have tested the mstflint problem with two different ppc64 machines : - On sles 10 PPC64 PowerMac G5 -> mstflint -d 0001:07:00.0 qworks o.k. with and without the ib_mthca loaded - On s;es10 PPC64 IBM JS21 -> mstflint -d 0001:07:00.0 qDOESN'T work with and without the ib_mthca loaded and I have to use /proc/bus/pci/. Is it time to create a work arround that opens /proc/bus/pci/ And always work ? Moshe Moshe Katzir | +972-9971-8639 (o) | +972-52-860-6042 (m) Voltaire - The Grid Backbone www.voltaire.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael S. Tsirkin Sent: Tuesday, September 05, 2006 4:37 PM To: Or Gerlitz Cc: Roland Dreier; openib-general@openib.org Subject: Re: [openib-general] getting LOC_QP_OP_ERR with IPoIB - mstflint question Quoting r. Or Gerlitz <[EMAIL PROTECTED]>: > Subject: Re: getting LOC_QP_OP_ERR with IPoIB - mstflint question > > Michael S. Tsirkin wrote: > > Donnu, it looks really weird. Could you try firmware 3.5.0 please? > > I just noted that you can not work with mstflint if the mthca driver > is > not loaded, i think it was not the case in the gen1 tools, am i correct. Yes, recent kernels disable device access once driver is unloaded: mstflint -d 08:00.0 q *** ERROR *** Read a corrupted device id (0x). Probably HW/PCI access problem *** ERROR *** Device type 65535 not supported. *** ERROR *** Can not get flash type using device 08:00.0 mstflint should work without driver using /proc: mstflint -d /proc/bus/pci/08/00.0 q Image type: Failsafe I.S. Version:1 Chip Revision: A0 In gen1 flint had a separate driver which you had to load. I am not sure whether this would work on 2.6.18 > Is this connected to this print > > ACPI: PCI interrupt for device :02:00.0 disabled > > i see once the mthca driver is unloaded? > > Or. Probably not. -- MST ___ 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
