Re: [openib-general] [PATCH] udapl: PPC64 cpuinfo change
On Thu, Oct 06, 2005 at 02:14:08PM -0700, Grant Grundler wrote: > On Thu, Oct 06, 2005 at 11:48:02AM -0600, Todd Bowman wrote: > > /proc/cpuinfo on PPC64 prints different label for processor speed. > ... > > ISTR the "clock" value in cpuinfo is NOT the same as the CPU MHz. > Can you remind me if "clock" value * "mtfb" results in > "wall clock" time units? > > If not, then use of DT_CPU_MHZ_MHZ needs to be reviewed since > it typically makes that assumption. > > Also, if someone cares about sparc (hey Tom! :^) ), > then might leverage the get_clock.c code on: > http://svn.gnumonks.org/trunk/mmio_test/ Oh boy is there some reason 'gettimeofday' does not work? Trying to infer timebase/clock/rtsc frequency is going to be a mess. Think cpus that dynamically change frequency.. Laptops do now.. how long before something with infiniband does and breaks this code horribly? (think embedded systems) There are a couple of implementations of gettimeofday fully in userspace that hide the details and still read the high-res hardware counters. Google for 'vDSO gettimeofday'. ___ 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] RE: OpenIB gen2 support ibv_create_cq
Matt wrote, >Woody, are there plans to update the 2.6.9 backports to svn version 3632 >or more recent to fix this? I just checked in new 2.6.9 backport patches for SVN rev. 3640 that should have this fix. 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
Re: [openib-general] [PATCH] udapl: PPC64 cpuinfo change
On Thu, Oct 06, 2005 at 11:48:02AM -0600, Todd Bowman wrote: > /proc/cpuinfo on PPC64 prints different label for processor speed. ... ISTR the "clock" value in cpuinfo is NOT the same as the CPU MHz. Can you remind me if "clock" value * "mtfb" results in "wall clock" time units? If not, then use of DT_CPU_MHZ_MHZ needs to be reviewed since it typically makes that assumption. Also, if someone cares about sparc (hey Tom! :^) ), then might leverage the get_clock.c code on: http://svn.gnumonks.org/trunk/mmio_test/ hth, grant ___ 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] Re: [PATCH] udapl: PPC64 atomic function additions
On Thu, 6 Oct 2005, Todd Bowman wrote: > This patch in addition to "PPC64 cpuinfo change" provides udapl support on > PPC64 platform. > > Added PPC64 dependent code to dapl_os_atomic_inc, dapl_os_atomic_dec, > dapl_os_atomic_assign and DT_Mdep_GetTimeStamp. > Also added PPC64 to platform checks. Committed in revision 3687. ___ 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] Re: [PATCH] udapl: PPC64 cpuinfo change
On Thu, 6 Oct 2005, Todd Bowman wrote: twbowm> This patch in addition to "PPC64 atomic function additions" provides udapl twbowm> support on PPC64 platform. twbowm> twbowm> /proc/cpuinfo on PPC64 prints different label for processor speed. Committed in revision 3687. ___ 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] segmentation fault in ibv_modify_srq
Roland, * On Oct,13 Roland Dreier<[EMAIL PROTECTED]> wrote : > Sayantan> I noticed that the test re-posts buffers only when the > Sayantan> outstanding recv count is <= 1. I set a SRQ limit as > Sayantan> max_recv - 5. So, I should get the event when 5 WQEs are > Sayantan> consumed from the SRQ, right? > > Yes, your code is correct. The problem was that the mthca kernel > driver was dispatching SRQ events incorrectly, so the event never > reached userspace. I've checked in a fix for that, and I'm going to > queue the SRQ limit event stuff for 2.6.15 (now that I've seen it > working). > > BTW, in your code, you have: > > fprintf(stderr, " event_type %d, port %d\n", event.event_type, > event.element.port_num); > > it would be more sensible to print event.element.srq here, since > you're expecting an SRQ event. Thanks for the fix!! I have updated our systems, and am able to see the event. Thanks for the tip too. My async function was a quick copy from the example asyncwatch.c :-) Thanks, Sayantan. > > - R. -- http://www.cse.ohio-state.edu/~surs ___ 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] segmentation fault in ibv_modify_srq
Sayantan> I noticed that the test re-posts buffers only when the Sayantan> outstanding recv count is <= 1. I set a SRQ limit as Sayantan> max_recv - 5. So, I should get the event when 5 WQEs are Sayantan> consumed from the SRQ, right? Yes, your code is correct. The problem was that the mthca kernel driver was dispatching SRQ events incorrectly, so the event never reached userspace. I've checked in a fix for that, and I'm going to queue the SRQ limit event stuff for 2.6.15 (now that I've seen it working). BTW, in your code, you have: fprintf(stderr, " event_type %d, port %d\n", event.event_type, event.element.port_num); it would be more sensible to print event.element.srq here, since you're expecting an SRQ event. - 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] Linux 2.6.13 Kernel Support Question
Roland Dreier wrote: Sean> Hello, Will openib still supply patches to the 2.6.13 Kernel Sean> or do I need to upgrade my kernel to 2.6.14? 2.6.14 is not out yet, so the OpenIB subversion repository continues to be targeted at 2.6.13 (the latest full kernel release). Once 2.6.14 is released, we'll target that for development. If the are API changes from 2.6.13 to 2.6.14 that mean the subversion tree no longer works with 2.6.13, then if you want to use the latest subversion sources, you'll have to either upgrade to 2.6.14, find some contributed backport patches, or do the backporting yourself. - R. Thanks Roland. Sean Hubbell ___ 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] Linux 2.6.13 Kernel Support Question
Sean> Hello, Will openib still supply patches to the 2.6.13 Kernel Sean> or do I need to upgrade my kernel to 2.6.14? 2.6.14 is not out yet, so the OpenIB subversion repository continues to be targeted at 2.6.13 (the latest full kernel release). Once 2.6.14 is released, we'll target that for development. If the are API changes from 2.6.13 to 2.6.14 that mean the subversion tree no longer works with 2.6.13, then if you want to use the latest subversion sources, you'll have to either upgrade to 2.6.14, find some contributed backport patches, or do the backporting yourself. - 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
[openib-general] Linux 2.6.13 Kernel Support Question
Hello, Will openib still supply patches to the 2.6.13 Kernel or do I need to upgrade my kernel to 2.6.14? Thanks, Sean Hubbell ___ 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] Re: [PATCH] IPoIB: Add API to retrieve ib device, port, and pkey
Hal Rosenstock wrote: What stops the net_device from being pulled from underneath this ? Seems like a similar issue to me. The difference I see is that only net_devices need to be tracked rather than perhaps net_devices and ib_devices. A reference on the net_device needs to be held while this is being read. Net_devices already have reference counting that comes with them; this would need to be added to ib_devices. E.g. dev = ip_dev_find(ip); gid = dev->dev_addr + 4; pkey = get_pkey(dev->broadcast); dev_put(dev); could be used to convert a local IP address to a GID/PKey. I'm assuming that neigh_lookup() provides the same protection: that neigh->dev is valid while a reference on the neigh is held (until neigh_release is called). Does anyone know if this is the case? - 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] Latest build test results
On Thu, 2005-10-06 at 15:20, Nishanth Aravamudan wrote: > On 06.10.2005 [13:25:35 -0400], Hal Rosenstock wrote: > > On Thu, 2005-10-06 at 13:11, Nishanth Aravamudan wrote: > > > On 06.10.2005 [19:40:40 +0300], Dan Bar Dov wrote: > > > > I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in > > > > version 3682. > > > > > > Great! Thanks. > > > > > > I'm re-running the tests (due to a subtle flaw in my PATH, my cronjobs > > > weren't running) now and will post the latest results. > > > > You might also want to apply > > https://openib.org/svn/gen2/trunk/src/linux-kernel/patches/linux-2.6.14-rc3-fib-frontend.diff > > to get rid of the AT and SDP warnings. > > This patch does remove the warning regarding undefined symbols during > modpost, but does not remove the warnings > > drivers/infiniband/core/at.c:1547: warning: initialization from incompatible > pointer type > > drivers/infiniband/ulp/sdp/sdp_link.c:752: warning: initialization from > incompatible pointer type Right. Roland reported a change to struct packet_type in 2.6.14. I'll work on a patch for this too. Thanks. -- 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] Re: [PATCH] IPoIB: Add API to retrieve ib device, port, and pkey
On Thu, 2005-10-06 at 15:08, Sean Hefty wrote: > Roland Dreier wrote: > > Sean> Is it possible to retrieve the pkey using > > Sean> net_device->class_dev? > > > > Maybe, but even more direct would be taking it from net_device->broadcast. > > Okay - this is starting to make more sense to me now: > > priv->dev->broadcast[8] = priv->pkey >> 8; > priv->dev->broadcast[9] = priv->pkey & 0xff; > > I assume that the broadcast address is well defined, and there's no issue > reading it from there? If so, then I think it's a simple change to addr.c to > extract it. What stops the net_device from being pulled from underneath this ? Seems like a similar issue to me. The difference I see is that only net_devices need to be tracked rather than perhaps net_devices and ib_devices. -- 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] Latest build test results
On 06.10.2005 [13:25:35 -0400], Hal Rosenstock wrote: > On Thu, 2005-10-06 at 13:11, Nishanth Aravamudan wrote: > > On 06.10.2005 [19:40:40 +0300], Dan Bar Dov wrote: > > > I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in > > > version 3682. > > > > Great! Thanks. > > > > I'm re-running the tests (due to a subtle flaw in my PATH, my cronjobs > > weren't running) now and will post the latest results. > > You might also want to apply > https://openib.org/svn/gen2/trunk/src/linux-kernel/patches/linux-2.6.14-rc3-fib-frontend.diff > to get rid of the AT and SDP warnings. This patch does remove the warning regarding undefined symbols during modpost, but does not remove the warnings drivers/infiniband/core/at.c:1547: warning: initialization from incompatible pointer type drivers/infiniband/ulp/sdp/sdp_link.c:752: warning: initialization from incompatible pointer type Thanks, Nish ___ 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] IPoIB: Add API to retrieve ib device, port, and pkey
Hal Rosenstock wrote: The CMA maintains a list of devices. The address translation code takes an IP address and returns the corresponding GID. The CMA looks up the GID against its list of devices. All synchronization for device removal is handled by the CMA. The only way I see is that a user needs to register as a client and track device removals. Is there another way ? The CMA will attempt to handle device removal internally. The basic operation is this: id = rdma_create_id(); rdma_resolve_addr(id...); /* associates a device with the ID */ /* wait for resolution to complete */ ib_alloc_pd(id->device...); ib_create_cq(id->device...); ib_create_qp(id->device...); rdma_connect(id); If a device is removed, the user will receive a callback with DEVICE_REMOVAL. The user must free all resources created using id->device, and destroy the id. The removal is blocked until the id is destroyed. Right now, the CMA issues a path record request based on the SGID/DGID only. It would be fairly easy to add the PKey to the request once the address translation code returns it. How would the address translation code get it ? Right now, it doesn't. But see Roland's message. It could be read directly from the broadcast address. - 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] Re: [PATCH] IPoIB: Add API to retrieve ib device, port, and pkey
Roland Dreier wrote: Sean> Is it possible to retrieve the pkey using Sean> net_device->class_dev? Maybe, but even more direct would be taking it from net_device->broadcast. Okay - this is starting to make more sense to me now: priv->dev->broadcast[8] = priv->pkey >> 8; priv->dev->broadcast[9] = priv->pkey & 0xff; I assume that the broadcast address is well defined, and there's no issue reading it from there? If so, then I think it's a simple change to addr.c to extract it. - 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] [PATCH] IPoIB: Add API to retrieve ib device, port, and pkey
On Thu, 2005-10-06 at 13:01, Sean Hefty wrote: > Hal Rosenstock wrote: > >>I didn't see any other way to retrieve the pkey associated with an IP > >>address > >>without this. > > > > Yes, and I looked at getting the ib_device but there is no easy way so I > > added them into the structure returned. Is CMA keeping a list of > > ib_devices that it walks for this ? > > The CMA maintains a list of devices. The address translation code takes an > IP > address and returns the corresponding GID. The CMA looks up the GID against > its > list of devices. All synchronization for device removal is handled by the > CMA. > > Currently, the address translation code isn't aware of ib_devices. It's > almost > a device independent IP to HW address translation mechanism. > > A question that I have is how does the user know if the ib_device pointer is > valid? The only way I see is that a user needs to register as a client and track device removals. Is there another way ? > >>For SDP, if we layered it over the CMA, would it still need to access this > >>information? > > > > I'm not 100% sure. It partially depends on the CMA APIs. How is the > > PathRecord request done ? That's what it's needed for. > > Right now, the CMA issues a path record request based on the SGID/DGID only. > It > would be fairly easy to add the PKey to the request once the address > translation > code returns it. How would the address translation code get it ? -- 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] Re: [PATCH] IPoIB: Add API to retrieve ib device, port, and pkey
Sean> Is it possible to retrieve the pkey using Sean> net_device->class_dev? Maybe, but even more direct would be taking it from net_device->broadcast. - 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] Re: [PATCH] IPoIB: Add API to retrieve ib device, port, and pkey
On Thu, 2005-10-06 at 13:50, Sean Hefty wrote: > Roland Dreier wrote: > > Did we ever figure out how to handle the hotplug issues with the > > lifetime of the struct ib_device pointer? Right now this API is > > unsafe, because a caller can get a pointer to a device that has > > already disappeared. > > Is it possible to retrieve the pkey using net_device->class_dev? I think so, but would that be any safer ? I think it might end up going through the IPoIB device private data (or an API anyhow). -- 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] segmentation fault in ibv_modify_srq
Roland,
* On Oct,11 Sayantan Sur<[EMAIL PROTECTED]> wrote :
> I will test out the limit event generation next.
I made some simple modifications to srq_pingpong.c to see if I am able
to generate the IBV_EVENT_SRQ_LIMIT_REACHED event. I have attached my
changes as a patch and the full file (for easy execution).
I noticed that the test re-posts buffers only when the outstanding recv
count is <= 1. I set a SRQ limit as max_recv - 5. So, I should get the
event when 5 WQEs are consumed from the SRQ, right?
As of now, I am not able to see the event happening. I'd be glad if you
could see if this issue can be resolved.
Thanks for your prompt help.
Sayantan.
--
http://www.cse.ohio-state.edu/~surs
Index: srq_pingpong.c
===
--- srq_pingpong.c (revision 3676)
+++ srq_pingpong.c (working copy)
@@ -36,6 +36,8 @@
# include
#endif /* HAVE_CONFIG_H */
+#define _GNU_SOURCE
+
#include
#include
#include
@@ -62,6 +64,8 @@
static int page_size;
+static pthread_t limit_thread;
+
struct pingpong_context {
struct ibv_context *context;
struct ibv_comp_channel *channel;
@@ -82,6 +86,25 @@
int psn;
};
+
+static void asyncwatch(struct ibv_context *context)
+{
+ struct ibv_async_event event;
+
+ while (1) {
+
+ if (ibv_get_async_event(context, &event)) {
+fprintf(stderr,"Error getting event!\n");
+}
+
+ fprintf(stderr, " event_type %d, port %d\n", event.event_type,
+ event.element.port_num);
+fflush(stderr);
+
+ ibv_ack_async_event(&event);
+ }
+}
+
static uint16_t pp_get_local_lid(struct pingpong_context *ctx, int port)
{
struct ibv_port_attr attr;
@@ -382,7 +405,11 @@
return NULL;
}
+pthread_create(&limit_thread, NULL, (void *) asyncwatch, (void
*)ctx->context);
+
{
+struct ibv_srq_attr srq_attr;
+
struct ibv_srq_init_attr attr = {
.attr = {
.max_wr = rx_depth,
@@ -395,6 +422,15 @@
fprintf(stderr, "Couldn't create SRQ\n");
return NULL;
}
+
+srq_attr.max_wr = rx_depth;
+srq_attr.max_sge = 1;
+srq_attr.srq_limit = rx_depth-5;
+
+if(ibv_modify_srq(ctx->srq, &srq_attr, IBV_SRQ_LIMIT)) {
+fprintf(stderr,"Error modifying SRQ\n");
+exit(-1);
+}
}
for (i = 0; i < num_qp; ++i) {
@@ -434,6 +470,7 @@
}
}
+
return ctx;
}
@@ -742,6 +779,8 @@
}
}
+fprintf(stderr,"routs %d\n", routs);
+
if (scnt < iters) {
j = find_qp(wc[i].qp_num, ctx,
num_qp);
if (j < 0) {
@@ -784,5 +823,7 @@
iters, usec / 100., usec / iters);
}
+sleep(3);
+
return 0;
}
/*
* Copyright (c) 2005 Topspin Communications. All rights reserved.
*
* This software is available to you under a choice of one of two
* licenses. You may choose to be licensed under the terms of the GNU
* General Public License (GPL) Version 2, available from the file
* COPYING in the main directory of this source tree, or the
* OpenIB.org BSD license below:
*
* Redistribution and use in source and binary forms, with or
* without modification, are permitted provided that the following
* conditions are met:
*
* - Redistributions of source code must retain the above
*copyright notice, this list of conditions and the following
*disclaimer.
*
* - Redistributions in binary form must reproduce the above
*copyright notice, this list of conditions and the following
*disclaimer in the documentation and/or other materials
*provided with the distribution.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
* EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
* MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
* NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
* BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
* ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*
* $Id: srq_pingpong.c 3551 2005-09-26 21:07:33Z roland $
*/
#if HAVE_CONFIG_H
# include
#endif /* HAVE_CONFIG_H */
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
enum {
PINGPONG_RECV_WRID = 1,
PINGPONG_SEND_WRID = 2,
MAX_QP = 256,
};
s
Re: [openib-general] Latest build test results
On 06.10.2005 [13:25:35 -0400], Hal Rosenstock wrote: > On Thu, 2005-10-06 at 13:11, Nishanth Aravamudan wrote: > > On 06.10.2005 [19:40:40 +0300], Dan Bar Dov wrote: > > > I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in > > > version 3682. > > > > Great! Thanks. > > > > I'm re-running the tests (due to a subtle flaw in my PATH, my cronjobs > > weren't running) now and will post the latest results. > > You might also want to apply > https://openib.org/svn/gen2/trunk/src/linux-kernel/patches/linux-2.6.14-rc3-fib-frontend.diff > to get rid of the AT and SDP warnings. I already submitted several jobs for 2.6.14-rc3-git6, but I'll redo the gen2 ones with that patch, thanks. Here are the results from 2.6.14-rc3-git6 + gen2 3683 Looks like x86 is broken in the current svn tree. x86 and ppc64 mainline is fine with both =y and =m ppc64 + gen2 =y drivers/infiniband/ulp/srp/ib_srp.c: In function `srp_process_rsp': drivers/infiniband/ulp/srp/ib_srp.c:650: warning: long long unsigned int format, u64 arg (arg 2) drivers/infiniband/core/at.c:1547: warning: initialization from incompatible pointer type drivers/infiniband/ulp/sdp/sdp_link.c:752: warning: initialization from incompatible pointer type ppc64 + gen2 =m same as above, plus *** Warning: ".ip_dev_find" [drivers/infiniband/ulp/sdp/ib_sdp.ko] undefined! *** Warning: ".ip_dev_find" [drivers/infiniband/core/ib_at.ko] undefined! x86 + gen2 =y *FAILED* drivers/infiniband/ulp/sdp/sdp_link.c:752: warning: initialization from incompatible pointer type drivers/infiniband/core/at.c:1547: warning: initialization from incompatible pointer type drivers/infiniband/ulp/iser/iser_conn.c: In function `iser_adaptor_release': drivers/infiniband/ulp/iser/iser_conn.c:195: parse error before `)' drivers/infiniband/ulp/iser/iser_conn.c:203: parse error before `)' drivers/infiniband/ulp/iser/iser_conn.c:206: parse error before `)' drivers/infiniband/ulp/iser/iser_conn.c: In function `iser_conn_establish': drivers/infiniband/ulp/iser/iser_conn.c:284: parse error before `)' drivers/infiniband/ulp/iser/iser_conn.c: In function `iser_post_receive_control': drivers/infiniband/ulp/iser/iser_conn.c:861: parse error before `)' drivers/infiniband/ulp/iser/iser_conn.c:873: parse error before `)' drivers/infiniband/ulp/iser/iser_initiator.c: In function `iser_reg_rdma_mem': drivers/infiniband/ulp/iser/iser_initiator.c:125: parse error before `)' drivers/infiniband/ulp/iser/iser_initiator.c:130: parse error before `)' drivers/infiniband/ulp/iser/iser_initiator.c:141: parse error before `)' drivers/infiniband/ulp/iser/iser_initiator.c:153: parse error before `)' drivers/infiniband/ulp/iser/iser_mod.c: In function `init_module': drivers/infiniband/ulp/iser/iser_mod.c:154: parse error before `)' drivers/infiniband/ulp/iser/iser_mod.c: In function `cleanup_module': drivers/infiniband/ulp/iser/iser_mod.c:243: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c: In function `iser_create_ia_pz_evd': drivers/infiniband/ulp/iser/iser_lkdapl.c:147: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c: In function `iser_consume_events': drivers/infiniband/ulp/iser/iser_lkdapl.c:691: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c: In function `iser_event_handler_thread': drivers/infiniband/ulp/iser/iser_lkdapl.c:731: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c:749: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c: In function `iser_handle_conn_event': drivers/infiniband/ulp/iser/iser_lkdapl.c:776: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c:779: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c:782: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c:785: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c:788: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c:791: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c:794: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c:797: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c:800: parse error before `)' drivers/infiniband/ulp/iser/iser_lkdapl.c: In function `iser_handle_single_kdapl_event': drivers/infiniband/ulp/iser/iser_lkdapl.c:1025: parse error before `)' x86 + gen2 =m *FAILED* same as above Thanks, Nish ___ 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] Re: [git pull] InfiniBand fixes for 2.6.14
Jeff> When I pulled this yesterday, it didn't compile Jeff> uverbs_main.c. It looks like it's missing from Jeff> include/rdma/ib_user_verbs.h Jeff> I'm wondering if I pulled your tree/branch correctly. Can Jeff> you confirm these would be the right instructions? Looks reasonable to me. I'm not sure what went wrong. Unfortunately I just blew away that git tree and rebased against Linus's latest tree. But everything from the for-linus branch should be in Linus's git tree. Does Linus's tree build for you? I just made a new infiniband git tree with an "upstream" branch for changes I plan to merge in 2.6.15 and a for-linus branch (currently empty) with 2.6.14 fixes. Once that hits the mirrors you could try pulling that and see how it works for you. > drivers/infiniband/core/uverbs_main.c: In function `ib_uverbs_write': > drivers/infiniband/core/uverbs_main.c:517: error: > `IB_USER_VERBS_CMD_QUERY_PARAMS' undeclared (first use in this function) > drivers/infiniband/core/uverbs_main.c:517: error: (Each undeclared > identifier is reported only once > drivers/infiniband/core/uverbs_main.c:517: error: for each function it > appears in.) These error messages seem like your uverbs_main.c and ib_user_verbs.h files got out of sync somehow. My tree looked OK to me so I don't know how to explain this. - 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] Re: [PATCH] IPoIB: Add API to retrieve ib device, port, and pkey
Roland Dreier wrote: Did we ever figure out how to handle the hotplug issues with the lifetime of the struct ib_device pointer? Right now this API is unsafe, because a caller can get a pointer to a device that has already disappeared. Is it possible to retrieve the pkey using net_device->class_dev? - 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
[openib-general] [PATCH] udapl: PPC64 atomic function additions
This patch in addition to "PPC64 cpuinfo change" provides udapl support on PPC64 platform.
Added PPC64 dependent code to dapl_os_atomic_inc, dapl_os_atomic_dec, dapl_os_atomic_assign and DT_Mdep_GetTimeStamp.
Also added PPC64 to platform checks.
Signed-off-by: Todd Bowman <[EMAIL PROTECTED]>
Index: userspace/dapl/dapl/udapl/linux/dapl_osd.h
===
--- userspace/dapl/dapl/udapl/linux/dapl_osd.h (revision 3547)
+++ userspace/dapl/dapl/udapl/linux/dapl_osd.h (working copy)
@@ -49,7 +49,7 @@
#error UNDEFINED OS TYPE
#endif /* __linux__ */
-#if !defined (__i386__) && !defined (__ia64__) && !defined(__x86_64__)
+#if !defined (__i386__) && !defined (__ia64__) && !defined(__x86_64__) && !defined(__PPC64__)
#error UNDEFINED ARCH
#endif
@@ -78,7 +78,7 @@
#include
#include
-#ifdef __ia64__
+#if defined(__ia64__) || defined(__PPC64__)
#include
#include
#endif
@@ -162,6 +160,8 @@
IA64_FETCHADD (old_value,v,1,4);
#endif
+#elif defined(__PPC64__)
+ atomic_inc((atomic_t *) v);
#else /* !__ia64__ */
__asm__ __volatile__ (
"lock;" "incl %0"
@@ -190,6 +190,9 @@
IA64_FETCHADD (old_value,v,-1,4);
#endif
+#elif defined (__PPC64__)
+ atomic_dec((atomic_t *)v);
+
#else /* !__ia64__ */
__asm__ __volatile__ (
"lock;" "decl %0"
@@ -230,6 +233,22 @@
current_value = ia64_cmpxchg("acq",v,match_value,new_value,4);
+#elif defined(__PPC64__)
+
+ __asm__ __volatile__ (
+ EIEIO_ON_SMP
+"1: lwarx %0,0,%2 # __cmpxchg_u64\n\
+ cmpd 0,%0,%3\n\
+ bne- 2f\n\
+ stwcx. %4,0,%2\n\
+ bne- 1b"
+ ISYNC_ON_SMP
+ "\n\
+2:"
+ : "=&r" (current_value), "=m" (*v)
+ : "r" (v), "r" (match_value), "r" (new_value), "m" (*v)
+ : "cc", "memory");
+
#else
__asm__ __volatile__ (
"lock; cmpxchgl %1, %2"
Index: userspace/dapl/test/dapltest/mdep/linux/dapl_mdep_user.h
===
--- userspace/dapl/test/dapltest/mdep/linux/dapl_mdep_user.h (revision 3547)
+++ userspace/dapl/test/dapltest/mdep/linux/dapl_mdep_user.h (working copy)
@@ -128,10 +128,20 @@
x = get_cycles ();
return x;
+#else
+#if defined(__PPC64__)
+ unsigned int tbl, tbu0, tbu1;
+ do {
+ __asm__ __volatile__ ("mftbu %0" : "=r"(tbu0));
+ __asm__ __volatile__ ("mftb %0" : "=r"(tbl));
+ __asm__ __volatile__ ("mftbu %0" : "=r"(tbu1));
+ } while (tbu0 != tbu1);
+ return (((unsigned long long)tbu0) << 32) | tbl;
#else
-#error "Non-Pentium Linux - unimplemented"
+#error "Non-Pentium and Non-PPC Linux - unimplemented"
#endif
#endif
+#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] [PATCH] udapl: PPC64 cpuinfo change
This patch in addition to "PPC64 atomic function additions" provides udapl support on PPC64 platform.
/proc/cpuinfo on PPC64 prints different label for processor speed.
Signed-off-by: Todd Bowman <[EMAIL PROTECTED]>
Index: userspace/dapl/test/dapltest/mdep/linux/dapl_mdep_user.c
===
--- userspace/dapl/test/dapltest/mdep/linux/dapl_mdep_user.c (revision 3547)
+++ userspace/dapl/test/dapltest/mdep/linux/dapl_mdep_user.c (working copy)
@@ -186,7 +186,12 @@
void )
{
#define DT_CPU_MHZ_BUFFER_SIZE 128
+
+#if defined (__PPC64__)
+#define DT_CPU_MHZ_MHZ "clock"
+#else
#define
DT_CPU_MHZ_MHZ
"cpu MHz"
+#endif
#define DT_CPU_MHZ_DELIMITER ":"
FILE *fp;
___
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] Latest build test results
On Thu, 2005-10-06 at 13:11, Nishanth Aravamudan wrote: > On 06.10.2005 [19:40:40 +0300], Dan Bar Dov wrote: > > I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in version > > 3682. > > Great! Thanks. > > I'm re-running the tests (due to a subtle flaw in my PATH, my cronjobs > weren't running) now and will post the latest results. You might also want to apply https://openib.org/svn/gen2/trunk/src/linux-kernel/patches/linux-2.6.14-rc3-fib-frontend.diff to get rid of the AT and SDP warnings. -- 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] Re: [git pull] InfiniBand fixes for 2.6.14
On 09/27/2005 09:01 PM, Roland Dreier wrote: > Linus, please pull from > > master.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git > for-linus > > This tree is also available from kernel.org mirrors at: > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git > for-linus When I pulled this yesterday, it didn't compile uverbs_main.c. It looks like it's missing from include/rdma/ib_user_verbs.h I'm wondering if I pulled your tree/branch correctly. Can you confirm these would be the right instructions? export \ IB="rsync://rsync.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git" git clone $IB ib cd ib git-read-tree -m HEAD git-checkout-cache -q -f -u -a At that point I have the master branch. Then I switch to your branch: git checkout -f for-linus Then, after the initial pull, if I wanted to update to the current version I'd run: git pull Thanks, Jeff drivers/infiniband/core/uverbs_main.c: In function `ib_uverbs_write': drivers/infiniband/core/uverbs_main.c:517: error: `IB_USER_VERBS_CMD_QUERY_PARAMS' undeclared (first use in this function) drivers/infiniband/core/uverbs_main.c:517: error: (Each undeclared identifier is reported only once drivers/infiniband/core/uverbs_main.c:517: error: for each function it appears in.) ___ 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] Latest build test results
On 06.10.2005 [19:40:40 +0300], Dan Bar Dov wrote: > I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in version > 3682. Great! Thanks. I'm re-running the tests (due to a subtle flaw in my PATH, my cronjobs weren't running) now and will post the latest results. Thanks, Nish ___ 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] IPoIB: Add API to retrieve ib device, port, and pkey
Hal Rosenstock wrote: I didn't see any other way to retrieve the pkey associated with an IP address without this. Yes, and I looked at getting the ib_device but there is no easy way so I added them into the structure returned. Is CMA keeping a list of ib_devices that it walks for this ? The CMA maintains a list of devices. The address translation code takes an IP address and returns the corresponding GID. The CMA looks up the GID against its list of devices. All synchronization for device removal is handled by the CMA. Currently, the address translation code isn't aware of ib_devices. It's almost a device independent IP to HW address translation mechanism. A question that I have is how does the user know if the ib_device pointer is valid? For SDP, if we layered it over the CMA, would it still need to access this information? I'm not 100% sure. It partially depends on the CMA APIs. How is the PathRecord request done ? That's what it's needed for. Right now, the CMA issues a path record request based on the SGID/DGID only. It would be fairly easy to add the PKey to the request once the address translation code returns it. - 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
[openib-general] Re: [PATCH] IPoIB: Add API to retrieve ib device, port, and pkey
Did we ever figure out how to handle the hotplug issues with the lifetime of the struct ib_device pointer? Right now this API is unsafe, because a caller can get a pointer to a device that has already disappeared. Also if we do decide to add an API like this, the struct ipoib_info and ipoib_get_info() declarations should be in rather than in the private ipoib.h header. - 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] IPoIB: Add API to retrieve ib device, port, and pkey
On Thu, 2005-10-06 at 12:34, Sean Hefty wrote: > Hal Rosenstock wrote: > > IPoIB: Add API to retrieve ib device, port, and pkey > > > > (I'm also attaching my patch to at.c which uses this; If this is > > accepted, I will make up a patch for SDP as well.) > > I didn't see any other way to retrieve the pkey associated with an IP address > without this. Yes, and I looked at getting the ib_device but there is no easy way so I added them into the structure returned. Is CMA keeping a list of ib_devices that it walks for this ? > For SDP, if we layered it over the CMA, would it still need to access this > information? I'm not 100% sure. It partially depends on the CMA APIs. How is the PathRecord request done ? That's what it's needed for. -- 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] Latest build test results
I've fixed the 2.6.14-rc3 compilation warnings with iSER on x86 in version 3682. Dan On 10/4/05, Nishanth Aravamudan <[EMAIL PROTECTED]> wrote: > Hello, > > Here are the build results for 2.6.14-rc3 with and without the latest > gen2 trunk. > > Looks like all the builds were successful, with some warnings: > > - ppc64 + gen2 with =y > > drivers/infiniband/core/at.c:1547: warning: initialization from incompatible > pointer type > > drivers/infiniband/ulp/sdp/sdp_link.c:752: warning: initialization from > incompatible pointer type > > - same for =m, plus > > *** Warning: ".ip_dev_find" [drivers/infiniband/ulp/sdp/ib_sdp.ko] undefined! > *** Warning: ".ip_dev_find" [drivers/infiniband/core/ib_at.ko] undefined! > > WARNING: > /lib/modules/2.6.14-rc3-git3-autokern1/kernel/drivers/infiniband/core/ib_at.ko > needs unknown symbol ip_dev_find > WARNING: > /lib/modules/2.6.14-rc3-git3-autokern1/kernel/drivers/infiniband/ulp/sdp/ib_sdp.ko > needs unknown symbol ip_dev_find > > - x86 + gen2 with =y > > drivers/infiniband/ulp/iser/iser_conn.c: In function `iser_adaptor_release': > drivers/infiniband/ulp/iser/iser_conn.c:195: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_conn.c:203: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_conn.c:206: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_conn.c: In function `iser_conn_establish': > drivers/infiniband/ulp/iser/iser_conn.c:285: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_conn.c: In function `iser_conn_enable_rdma': > drivers/infiniband/ulp/iser/iser_conn.c:357: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_conn.c:431: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_conn.c: In function > `iser_post_receive_control': > drivers/infiniband/ulp/iser/iser_conn.c:933: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_conn.c:950: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_conn.c:981: warning: too few arguments for > format > > drivers/infiniband/ulp/iser/iser_memory.c: In function > `iser_all_mem_add_to_dto': > drivers/infiniband/ulp/iser/iser_memory.c:230: warning: cast from pointer to > integer of different size > > drivers/infiniband/ulp/iser/iser_mod.c: In function `init_module': > drivers/infiniband/ulp/iser/iser_mod.c:152: warning: too few arguments for > format > > drivers/infiniband/ulp/iser/iser_initiator.c: In function `iser_reg_rdma_mem': > drivers/infiniband/ulp/iser/iser_initiator.c:62: warning: too few arguments > for format > drivers/infiniband/ulp/iser/iser_initiator.c:67: warning: too few arguments > for format > drivers/infiniband/ulp/iser/iser_initiator.c:80: warning: too few arguments > for format > drivers/infiniband/ulp/iser/iser_initiator.c:95: warning: too few arguments > for format > > drivers/infiniband/ulp/iser/iser_lkdapl.c: In function > `iser_create_ia_pz_evd': > drivers/infiniband/ulp/iser/iser_lkdapl.c:147: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c: In function `iser_start_dto': > drivers/infiniband/ulp/iser/iser_lkdapl.c:660: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c: In function `iser_consume_events': > drivers/infiniband/ulp/iser/iser_lkdapl.c:758: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c: In function > `iser_event_handler_thread': > drivers/infiniband/ulp/iser/iser_lkdapl.c:800: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c:819: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c: In function > `iser_handle_conn_event': > drivers/infiniband/ulp/iser/iser_lkdapl.c:846: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c:849: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c:852: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c:855: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c:858: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c:861: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c:864: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c:867: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c:870: warning: too few arguments for > format > drivers/infiniband/ulp/iser/iser_lkdapl.c: In function > `iser_handle_single_kdapl_event': > drivers/infiniband/ulp/iser/iser_lkdapl.c:1116: warning: too few arguments > for format > > drivers/infiniband/ulp/iser/iser_mod.c: In function `cleanup_module': > drivers/infiniband/ulp/iser/iser_mod.c:241: warning: too few arguments for > format > > drivers/infiniband/ulp/sdp/sdp_link.c:
Re: [openib-general] [PATCH] IPoIB: Add API to retrieve ib device, port, and pkey
Hal Rosenstock wrote: IPoIB: Add API to retrieve ib device, port, and pkey (I'm also attaching my patch to at.c which uses this; If this is accepted, I will make up a patch for SDP as well.) I didn't see any other way to retrieve the pkey associated with an IP address without this. For SDP, if we layered it over the CMA, would it still need to access this information? - 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
[openib-general] [PATCH] IPoIB: Add API to retrieve ib device, port, and pkey
IPoIB: Add API to retrieve ib device, port, and pkey
(I'm also attaching my patch to at.c which uses this; If this is
accepted, I will make up a patch for SDP as well.)
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: ipoib.h
===
--- ipoib.h (revision 3683)
+++ ipoib.h (working copy)
@@ -210,6 +210,12 @@ struct ipoib_neigh {
struct list_headlist;
};
+struct ipoib_info {
+ struct ib_device *dev;
+ int port;
+ u16 pkey;
+};
+
static inline struct ipoib_neigh **to_ipoib_neigh(struct neighbour *neigh)
{
return (struct ipoib_neigh **) (neigh->ha + 24 -
@@ -239,6 +245,8 @@ void ipoib_reap_ah(void *dev_ptr);
void ipoib_flush_paths(struct net_device *dev);
struct ipoib_dev_priv *ipoib_intf_alloc(const char *format);
+int ipoib_get_info(struct net_device *dev, struct ipoib_info *info);
+
int ipoib_ib_dev_init(struct net_device *dev, struct ib_device *ca, int port);
void ipoib_ib_dev_flush(void *dev);
void ipoib_ib_dev_cleanup(struct net_device *dev);
Index: ipoib_ib.c
===
--- ipoib_ib.c (revision 3683)
+++ ipoib_ib.c (working copy)
@@ -38,6 +38,8 @@
#include
#include
+#include /* For ARPHRD_xxx */
+
#include
#include "ipoib.h"
@@ -569,6 +571,29 @@ int ipoib_ib_dev_init(struct net_device
return 0;
}
+int ipoib_get_info(struct net_device *dev, struct ipoib_info *info)
+{
+ struct ipoib_dev_priv *priv;
+
+ if (!info)
+ return -EINVAL;
+
+ /* Make sure IPoIB interface */
+ if (dev->type != ARPHRD_INFINIBAND)
+ return -ENODEV;
+
+ priv = netdev_priv(dev);
+ /* PKey assigned yet ? */
+ if (!test_bit(IPOIB_PKEY_ASSIGNED, &priv->flags))
+ return -ENOENT;
+
+ info->dev = priv->ca;
+ info->port = priv->port;
+ info->pkey = priv->pkey;
+ return 0;
+}
+EXPORT_SYMBOL(ipoib_get_info);
+
void ipoib_ib_dev_flush(void *_dev)
{
struct net_device *dev = (struct net_device *)_dev;
Index: at.c
===
--- at.c(revision 3683)
+++ at.c(working copy)
@@ -416,10 +416,10 @@ static void ib_at_ats_reg(void *data)
static int resolve_ip(struct ib_at_src *src, u32 dst_ip, u32 src_ip,
int tos, union ib_gid *dgid)
{
- struct ipoib_dev_priv *priv;
struct net_device *loopback = NULL;
struct net_device *ipoib_dev;
struct rtable *rt;
+ struct ipoib_info info;
struct flowi fl = {
.oif = 0, /* oif */
.nl_u = {
@@ -504,14 +504,16 @@ static int resolve_ip(struct ib_at_src *
}
/*
-* lookup local info.
+* Obtain ib_device, port, and PKey based on IPoIB net_device
*/
- priv = ipoib_dev->priv;
-
src->netdev = ipoib_dev;
- src->dev = priv->ca;
- src->port = priv->port;
- src->pkey = cpu_to_be16(priv->pkey);
+ if ((r = ipoib_get_info(ipoib_dev, &info))) {
+ DEBUG("ipoib_get_pkey failed %d", r);
+ goto done;
+ }
+ src->dev = info.dev;
+ src->port = info.port;
+ src->pkey = cpu_to_be16(info.pkey);
memcpy(&src->gid, ipoib_dev->dev_addr + 4, sizeof src->gid);
if (!dgid) {
___
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] ib_cm_listen failure
On Thu, 6 Oct 2005, Todd Bowman wrote: > Here is a patch for dtest.c to remove the qualifier from the sdp range. Thanks. Committed revision in 3683. ___ 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] Re: [PATCH] IPoIB: Backoff on send only joins as well
On Thu, 2005-10-06 at 10:28, Roland Dreier wrote: > Hal> IPoIB: Backoff on send only joins as well (as full member > Hal> ones) (This was part of the original patch but somehow > Hal> doesn't appear to have made it in). > > I left this part out intentionally because I don't see how it makes a > difference. Maybe I'm missing something, but where does > mcast->backoff get updated for send-only joins? OK. There is some code missing from the patch to do the backoff for send only joins. > Does this patch fix something in your testing? Shouldn't send only joins backoff like full member ones ? -- 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] Re: [PATCH] IPoIB: Backoff on send only joins as well
Hal> IPoIB: Backoff on send only joins as well (as full member Hal> ones) (This was part of the original patch but somehow Hal> doesn't appear to have made it in). I left this part out intentionally because I don't see how it makes a difference. Maybe I'm missing something, but where does mcast->backoff get updated for send-only joins? Does this patch fix something in your testing? - 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] ib_cm_listen failure
On 10/5/05, James Lentini <[EMAIL PROTECTED]> wrote: On Wed, 5 Oct 2005, Todd Bowman wrote:> Here is a patch for dtest.c to remove the qualifier from the sdp range.>> Index: userspace/dapl/test/dtest/dtest.c> === > --- userspace/dapl/test/dtest/dtest.c (revision 3547)> +++ userspace/dapl/test/dtest/dtest.c (working copy)> @@ -53,7 +53,7 @@> #include "dat/udat.h">> /* definitions */ > -#define SERVER_CONN_QUAL 71123> +#define SERVER_CONN_QUAL 45248> #define DTO_TIMEOUT (1000*1000*5)> #define DTO_FLUSH_TIMEOUT (1000*1000*2)> #define CONN_TIMEOUT (1000*1000*10) Thanks Todd. I don't mean to nit pick, but do mind throwing aSigned-off-by line on it? No problem. Signed-off-by: Todd Bowman <[EMAIL PROTECTED]> Index: userspace/dapl/test/dtest/dtest.c === --- userspace/dapl/test/dtest/dtest.c (revision 3547) +++ userspace/dapl/test/dtest/dtest.c (working copy) @@ -53,7 +53,7 @@ #include "dat/udat.h" /* definitions */ -#define SERVER_CONN_QUAL 71123 +#define SERVER_CONN_QUAL 45248 #define DTO_TIMEOUT (1000*1000*5) #define DTO_FLUSH_TIMEOUT (1000*1000*2) #define CONN_TIMEOUT (1000*1000*10) ___ 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] segmentation fault in ibv_modify_srq
* On Oct,10 Roland Dreier<[EMAIL PROTECTED]> wrote :
> Sayantan> I am getting a segmentation fault after a couple of
> Sayantan> thousand messages are sent over SRQ (using ping-pong
> Sayantan> latency test). Here is a snippet from the core
> Sayantan> generated.
>
> Is it possible that you are posting one more receive to the SRQ than
> the max capacity you requested when creating the SRQ?
>
> What happens with the patch below applied to libmthca?
Upon inspection of my code, I found that there _is_ a possibility of
posting more than srq config. I fixed that and the ping-pong test works.
The patch you sent is good, it prevents the application from posting
more than max.
I will test out the limit event generation next.
Thanks,
Sayantan.
>
> Thanks,
> Roland
>
>
> --- libmthca/src/srq.c(revision 3664)
> +++ libmthca/src/srq.c(working copy)
> @@ -110,6 +110,13 @@ int mthca_tavor_post_srq_recv(struct ibv
>
> wqe = get_wqe(srq, ind);
> next_ind = *wqe_to_link(wqe);
> +
> + if (next_ind < 0) {
> + err = -1;
> + *bad_wr = wr;
> + break;
> + }
> +
> prev_wqe = srq->last;
> srq->last = wqe;
>
> @@ -197,6 +204,12 @@ int mthca_arbel_post_srq_recv(struct ibv
> wqe = get_wqe(srq, ind);
> next_ind = *wqe_to_link(wqe);
>
> + if (next_ind < 0) {
> + err = -1;
> + *bad_wr = wr;
> + break;
> + }
> +
> ((struct mthca_next_seg *) wqe)->nda_op =
> htonl((next_ind << srq->wqe_shift) | 1);
> ((struct mthca_next_seg *) wqe)->ee_nds = 0;
--
http://www.cse.ohio-state.edu/~surs
___
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] IPoIB: Backoff on send only joins as well
IPoIB: Backoff on send only joins as well (as full member ones)
(This was part of the original patch but somehow doesn't appear to have
made it in).
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]>
Index: ipoib_multicast.c
===
--- ipoib_multicast.c (revision 3678)
+++ ipoib_multicast.c (working copy)
@@ -366,7 +366,7 @@ static int ipoib_mcast_sendonly_join(str
IB_SA_MCMEMBER_REC_PORT_GID|
IB_SA_MCMEMBER_REC_PKEY|
IB_SA_MCMEMBER_REC_JOIN_STATE,
-1000, GFP_ATOMIC,
+mcast->backoff * 1000, GFP_ATOMIC,
ipoib_mcast_sendonly_join_complete,
mcast, &mcast->query);
if (ret < 0) {
___
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] Re: [PATCH] Fix leak on MAD initialization failure
On Wed, 2005-10-05 at 17:25, Roland Dreier wrote: > It seems that there is a bug in ib_mad_init_device(): if > ib_agent_port_open() fails for a given port, then the current code > doesn't call ib_mad_port_close() for that port. I think something > like the patch below is needed. Yup, it missed calling ib_agent_port_close in the case where it was the ib_agent_port_open which failed for a port. 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] [PATCH] libibat: little / big endian problems in example programs
On Thu, 2005-10-06 at 08:14, Heiko J Schick wrote:
> Hello,
>
> during (some) test with libibat I found out that the example programs
> include a little/big endian problem.
> Below you will find the patch for ats.c and att.c which will solve
> this problem on PPC64:
>
> Signed-off-by: Heiko Joerg Schick <[EMAIL PROTECTED]>
Thanks. Applied.
> --- /home/source/trunk_3615_orig/src/userspace/libibat/examples/ats.c
> 2005-08-23 18:49:39.0 +0200
> +++ ats.c 2005-10-06 13:42:02.492909848 +0200
> @@ -225,7 +225,7 @@ int main(int argc, char **argv)
> }
>
> for (i = 0; i < MAX_REQ; i++) {
> - r = ib_at_route_by_ip(0x0100a8c0, 0, 0,
> + r = ib_at_route_by_ip(htonl(0xc0a80001), 0, 0,
> IB_AT_ROUTE_FORCE_ATS,
> att_rt + i, att_rt_comp + i,
> &req_id);
The patch din't apply. It indicated it was malformed here. I think your
mailer line wrapped this. That needs to be turned off when submitting
patches.
>
> --- /home/source/trunk_3615_orig/src/userspace/libibat/examples/att.c
> 2005-08-23 18:49:39.0 +0200
> +++ att.c 2005-10-06 13:40:26.293891760 +0200
> @@ -190,7 +190,7 @@ int main(int argc, char **argv)
> }
>
> for (i = 0; i < MAX_REQ; i++) {
> - r = ib_at_route_by_ip(0x0100a8c0, 0, 0, 0,
> + r = ib_at_route_by_ip(htonl(0xc0a80001), 0, 0, 0,
> att_rt + i, att_rt_comp + i,
> &req_id);
>
> #if __WORDSIZE == 64
>
> BTW. Does the output of the uatt program looks alright?
Yes, that looks OK to me but would need to be verified with your subnet
config. It looks like your test node was not 192.168.0.1 and had a LID
of 0xab and the 192.168.0.1 node was a different node with LID 0xae. You
could also verify the GIDs which were indicated as well.
-- Hal
> uatt: att_path_comp_fn: id 21 context 0x10012ae8 completed with
> rec_num 1
> ===> slid 0xab dlid 0xae
> uatt: main: ib_at_route_by_ip: ret 1 errno 0 for request 21 id 0 0
> uatt: att_rt_comp_fn: id 0 context 0x100135f0 completed with rec_num 1
> ===> rt 0x100135f0 sgid 0xfe8067eafbe40001 dgid
> 0xfe8067eafbe40002
> uatt: att_rt_comp_fn: ib_at_paths_by_route: ret 0 errno 0 id 22 22
> uatt: att_path_comp_fn: id 22 context 0x10012b30 completed with
> rec_num 1
> ===> slid 0xab dlid 0xae
> uatt: main: ib_at_route_by_ip: ret 1 errno 0 for request 22 id 0 0
> uatt: att_rt_comp_fn: id 0 context 0x10013628 completed with rec_num 1
> ===> rt 0x10013628 sgid 0xfe8067eafbe40001 dgid
> 0xfe8067eafbe40002
> uatt: att_rt_comp_fn: ib_at_paths_by_route: ret 0 errno 0 id 23 23
> uatt: att_path_comp_fn: id 23 context 0x10012b78 completed with
> rec_num 1
> ===> slid 0xab dlid 0xae
> ...
>
> Many thanks in advance!
>
> Mit freundlichen Gruessen / Kind Regards
> Heiko Joerg Schick
>
> IBM Deutschland Entwicklung GmbH
> I/Ox Microcode Development
> Linux Infiniband Device Drivers
>
> Schoenaicher Str. 220
> 71032 Boeblingen
> E-Mail: [EMAIL PROTECTED]
> External: 49-7031-16-0 x4219, t/l: 120-4219
>
>
> __
>
> ___
> 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
[openib-general] [PATCH] libibat: little / big endian problems in example programs
Hello,
during (some) test with libibat I found
out that the example programs include a little/big endian problem.
Below you will find the patch for ats.c
and att.c which will solve this problem on PPC64:
Signed-off-by: Heiko Joerg Schick <[EMAIL PROTECTED]>
--- /home/source/trunk_3615_orig/src/userspace/libibat/examples/ats.c
2005-08-23 18:49:39.0 +0200
+++ ats.c 2005-10-06
13:42:02.492909848 +0200
@@ -225,7 +225,7 @@ int main(int argc,
char **argv)
}
for (i
= 0; i < MAX_REQ; i++) {
-
r = ib_at_route_by_ip(0x0100a8c0, 0, 0,
+
r = ib_at_route_by_ip(htonl(0xc0a80001), 0, 0,
IB_AT_ROUTE_FORCE_ATS,
att_rt + i, att_rt_comp + i, &req_id);
--- /home/source/trunk_3615_orig/src/userspace/libibat/examples/att.c
2005-08-23 18:49:39.0 +0200
+++ att.c 2005-10-06
13:40:26.293891760 +0200
@@ -190,7 +190,7 @@ int main(int argc,
char **argv)
}
for (i
= 0; i < MAX_REQ; i++) {
-
r = ib_at_route_by_ip(0x0100a8c0, 0, 0, 0,
+
r = ib_at_route_by_ip(htonl(0xc0a80001), 0, 0, 0,
att_rt + i, att_rt_comp + i, &req_id);
#if __WORDSIZE == 64
BTW. Does the output of the uatt program
looks alright?
uatt: att_path_comp_fn: id 21 context
0x10012ae8 completed with rec_num 1
===> slid 0xab dlid 0xae
uatt: main: ib_at_route_by_ip: ret
1 errno 0 for request 21 id 0 0
uatt: att_rt_comp_fn: id 0 context
0x100135f0 completed with rec_num 1
===> rt 0x100135f0 sgid 0xfe8067eafbe40001
dgid 0xfe8067eafbe40002
uatt: att_rt_comp_fn: ib_at_paths_by_route:
ret 0 errno 0 id 22 22
uatt: att_path_comp_fn: id 22 context
0x10012b30 completed with rec_num 1
===> slid 0xab dlid 0xae
uatt: main: ib_at_route_by_ip: ret
1 errno 0 for request 22 id 0 0
uatt: att_rt_comp_fn: id 0 context
0x10013628 completed with rec_num 1
===> rt 0x10013628 sgid 0xfe8067eafbe40001
dgid 0xfe8067eafbe40002
uatt: att_rt_comp_fn: ib_at_paths_by_route:
ret 0 errno 0 id 23 23
uatt: att_path_comp_fn: id 23 context
0x10012b78 completed with rec_num 1
===> slid 0xab dlid 0xae
...
Many thanks in advance!
Mit freundlichen Gruessen / Kind Regards
Heiko Joerg Schick
IBM Deutschland Entwicklung GmbH
I/Ox Microcode Development
Linux Infiniband Device Drivers
Schoenaicher Str. 220
71032 Boeblingen
E-Mail: [EMAIL PROTECTED]
External: 49-7031-16-0 x4219, t/l: 120-4219
___
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] Updating firmware
Quoting Sean Hubbell <[EMAIL PROTECTED]>: > Michael, > > Would you like me to add autogen.sh and configure scripts to build > mstflint? The reason is that to compile this on my system (Dell > PowerEdge 2850 (2) 3.2 GHz running cAos 2.0 (with Patches) is not > resolving some of the require include paths. > > Sean Sean, thanks for offering help. So far, I managed to avoid the need for configure scripts, basically on account of the tool dependencies being so simple. Could you please explain what kind of problem are you facing? Is this a cross-compilation environment? How would configure scripts help? Thanks, -- 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
