> We have an application that doesn't require a receive CQ or QP resources
> since it will never post receive messages. We are attempting to limit
> our resources and reduce our receive resources to zero but it appears
> that the create qp assumes a receive CQ is always provided. According to
> What are the IB drivers that are in kernel.org (2.6.18.1) kernel. If they
> are not the same then should I remove them from the menuconfig and then
> build OFED drivers in order to avoid conflict. Is there any how-to procedure
> on how I can patch my kernel.org's vanilla kernel with the OFED
What are the IB drivers that are in kernel.org (2.6.18.1) kernel. If they are not the same then should I remove them from the menuconfig and then build OFED drivers in order to avoid conflict. Is there any how-to procedure on how I can patch my
kernel.org's vanilla kernel with the OFED 1.1 drivers
The following patch attempts to fix issues in the ib_cm regarding support
for path migration. The fixes are mainly on feedback from Venkatesh.
The patch has NOT been tested to verify that APM works correctly, but I did
check that it didn't break anything. I need to develop a test program to
verif
Davis, Arlin R wrote:
> We have an application that doesn’t require a receive CQ or QP resources
> since it will never post receive messages. We are attempting to limit
> our resources and reduce our receive resources to zero but it appears
> that the create qp assumes a receive CQ is always pro
> I'm beginning to think Michael Tsirkin has the only solution to this
> -- architectures need to check that their hardware blocks until the
> config write completion has occurred (and if not, simulate that it has
> in software).
OK, I guess I'm convinced. The vague language in the base PCI 3
On 13:35 Tue 31 Oct , Hal Rosenstock wrote:
> The following OpenSM header files appear to be unused:
>
> 183 osm_errors.h
> 230 osm_ft_config_ctrl.h
> 291 osm_mcast_config_ctrl.h
> 289 osm_pi_config_ctrl.h
> 289 osm_pkey_config_ctrl.h
> 297 osm_sm_info_get_ctrl.h
> 290 osm_subnet
Quoting r. Richard B. Johnson <[EMAIL PROTECTED]>:
> Subject: Re: Ordering between PCI config space writes and MMIO reads?
>
>
> - Original Message -
> From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
> To: "Roland Dreier" <[EMAIL PROTECTED]>
> Cc: ; ;
> <[EMAIL PROTECTED]>; <[EMAIL PROTE
On Tue, Oct 31, 2006 at 03:34:47PM -0500, Richard B. Johnson wrote:
> If you write to the PCI bus and then you read the result, the read
> __might__ be the
> read that flushes any posted writes rather than the read of device
Config space writes aren't posted, they're delayed. So, for example,
y
On 10/31/06, Sean Hefty <[EMAIL PROTECTED]> wrote:
> Or Gerlitz wrote:
> > Please let me know if you manage to get mckey working in non loopback
> > mode and if yes, if you have an idea how can i further debug my config.
>
> I did get mckey working fine in non loopback mode.
OK, thanks for putting
- Original Message -
From: "Michael S. Tsirkin" <[EMAIL PROTECTED]>
To: "Roland Dreier" <[EMAIL PROTECTED]>
Cc: ; ;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; ;
<[EMAIL PROTECTED]>; "David Miller" <[EMAIL PROTECTED]>
Sent: Tuesday, October 31, 2006 2:53 PM
Subject: Re: Ordering between P
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Ordering between PCI config space writes and MMIO reads?
>
> > Here's what I don't understand: according to PCI rules, pci config read
> > can bypass pci config write (both are non-posted).
> > So why does doing it help flush the writ
Roland,
We have an application that doesn’t require a receive
CQ or QP resources since it will never post receive messages. We are attempting
to limit our resources and reduce our receive resources to zero but it appears
that the create qp assumes a receive CQ is always provided. Accord
On Tue, Oct 31, 2006 at 11:53:02AM -0800, Roland Dreier wrote:
> > Here's what I don't understand: according to PCI rules, pci config read
> > can bypass pci config write (both are non-posted).
> > So why does doing it help flush the writes as the comment claims?
>
> No, I don't believe a read
> Here's what I don't understand: according to PCI rules, pci config read
> can bypass pci config write (both are non-posted).
> So why does doing it help flush the writes as the comment claims?
No, I don't believe a read of a config register can pass a write of
the same register. (Someone cor
Quoting r. Roland Dreier <[EMAIL PROTECTED]>:
> Subject: Re: Ordering between PCI config space writes and MMIO reads?
>
> The discussion fizzled out without really reaching a definitive
> answer, so I'm going to apply the original patch (below), since I
> pretty much convinced myself that only the
Quoting r. Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: [PATCH repost] IB/srp: destroy/recreate qp/cq at reconnect
>
> From: Ishai Rabinovitz <[EMAIL PROTECTED]>
>
> This makes SRP more robust in presence of hardware errors
> and is closer to behaviour suggested by IB spec,
> reducing chanc
Require registration with ib_addr module to prevent caller from unloading
while a callback is in progress.
Signed-off-by: Sean Hefty <[EMAIL PROTECTED]>
---
Changes from v1: Renamed deref_client to put_client.
diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
old mode 1
The discussion fizzled out without really reaching a definitive
answer, so I'm going to apply the original patch (below), since I
pretty much convinced myself that only the driver doing the config
access has enough information to fix this reliably.
- R.
Author: John Partridge <[EMAIL PROTECTED]>
Roland Dreier wrote:
> > @@ -305,6 +330,7 @@ int rdma_resolve_ip(struct sockaddr *src
> >break;
> >default:
> >ret = req->status;
> > + atomic_dec(&client->refcount);
> >kfree(req);
> >break;
> >}
>
> Doesn't this need to be
thanks, applied. I decided to leave the RLID -- it's not hurting
anything so let's be conservative for now
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://o
> @@ -305,6 +330,7 @@ int rdma_resolve_ip(struct sockaddr *src
> break;
> default:
> ret = req->status;
> +atomic_dec(&client->refcount);
> kfree(req);
> break;
> }
Doesn't this need to be deref_client() here too? O
> We are developing SRP target code and testing it with the OFED
> 1.1 SRP initiator. The OFED SRP initiator sends us a CM REQ (IB
> 12.6.5) and we respond with CM REP (12.6.8). However, instead of
> the expected CM RTU (12.6.9) we ALWAYS receive a CM REJ (12.6.7)
> with status 0x1
The following OpenSM header files appear to be unused:
183 osm_errors.h
230 osm_ft_config_ctrl.h
291 osm_mcast_config_ctrl.h
289 osm_pi_config_ctrl.h
289 osm_pkey_config_ctrl.h
297 osm_sm_info_get_ctrl.h
290 osm_subnet_config_ctrl.h
Any objections if they disappear ?
-- Hal
_
Chris Youb wrote:
> We are developing SRP target code and testing it with the OFED 1.1 SRP
> initiator. The OFED SRP initiator sends us a CM REQ (IB 12.6.5) and we
> respond with CM REP (12.6.8). However, instead of the expected CM RTU
> (12.6.9) we ALWAYS receive a CM REJ (12.6.7) with statu
From: Chris
YoubSent: Tuesday, October 31, 2006 12:13 PMTo:
openib-general@openib.orgSubject: [openib-general] OFED SRP initiator
always sends CM REJ in response to CM
REPAbstract: We are developing SRP target code and testing
it with the OFED 1.1 SRP initiator. The OFED SRP initiator s
I cannot find psm.h which header file
mtl_psm.h calls out in ompi v1.2 12372. Any hints on where
I would get that? Thanks.
--Mike
Michael E. Aho
Roadrunner Communications Stack Interconnect Lead
MS: 45E/015-2 (Office D116)
Rochester, MN 55901-7829
Phone (507) 253-6222, TL 553-6222
Abstract: We are developing SRP target code and testing it with the OFED 1.1 SRP initiator. The OFED SRP initiator sends us a CM REQ (IB 12.6.5) and we respond with CM REP (12.6.8). However, instead of the expected CM RTU (12.6.9) we ALWAYS receive a CM REJ (12.6.7) with status 0x1C == Reaso
Hi Mike,
I have copied this to the Open MPI devel list as this is an Open MPI
specific question.
The PSM MTL in Open MPI does not use the OpenIB verbs api at all.
Instead it makes use of the PSM library from QLogic. If you are using
the InfiniPath adapter you should be able to use PSM with Ope
Or Gerlitz wrote:
> Please let me know if you manage to get mckey working in non loopback
> mode and if yes, if you have an idea how can i further debug my config.
I did get mckey working fine in non loopback mode.
>> [EMAIL PROTECTED] librdmacm]# /home/ogerlitz/ib1.1/bin/mckey -m 224.5.5.5
>>
Hi,
I have added OFED support page on the Wiki:
https://openib.org/tiki/tiki-index.php?page=OFED+Support
and added a link to this page from the Wiki home.
And I am going to add few more items in the coming days.
Fill free to add/update with more issues/howtos/etc.
Tziporet
_
Michael S. Tsirkin wrote:
> ib_cm has this bug as well. Shouldn't we patch it for 2.6.19 too?
Yes - I've started on patches for the ib_cm and rdma_cm as well. They just
aren't quite so straightforward to fix.
- Sean
___
openib-general mailing list
op
On 17:06 Tue 31 Oct , Michael S. Tsirkin wrote:
> Quoting r. Sasha Khapyorsky <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] diags/saquery: fix node_desc.description as string
> > usages
> >
> > On 15:46 Tue 31 Oct , Michael S. Tsirkin wrote:
> > > Quoting r. Sasha Khapyorsky <[EMAIL PROTE
Or Gerlitz wrote:
> So the only case for which all this registration api/code at the ib_sa
> ib_cm and ib_addr (is it also in the ib_mad) protects against is where
> the consumer wants to destroy its ID by returning non zero from a
> callback and not by an explicit call to XXX_destory_id()
ib_s
This sounds like a question for the Open MPI mailing list; this list
is for OpenIB / OpenFabrics issues.
MTL and PSM issues are Open MPI-specific -- they do not have anything
to do with OpenIB / OpenFabrics. So I'll reply separately and move
your thread over to that list...
On Oct 31, 200
Ramachandra K wrote:
> Moni Shoua wrote:
>
>> We already tried to go this way and found that a local Module.symvers
>> is not always generated (but we might have missed something though).
>> I suggest that you check that this alternative way works under all
>> OSs compilation (SuSE and RedHat to
At 02:43 PM 10/30/2006, Hal Rosenstock wrote:
>On Mon, 2006-10-30 at 17:29, Michael Krause wrote:
> > At 02:05 PM 10/30/2006, Roland Dreier wrote:
> > > Hal> So rate = speed * width ?
> > >
> > >Yes, you should see the right think on DDR systems etc.
> >
> > Strange. Bandwidth = signaling rate
Quoting r. Sasha Khapyorsky <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] diags/saquery: fix node_desc.description as string usages
>
> On 15:46 Tue 31 Oct , Michael S. Tsirkin wrote:
> > Quoting r. Sasha Khapyorsky <[EMAIL PROTECTED]>:
> > > > > Look at this for example:
> > > > > http://source
On 15:46 Tue 31 Oct , Michael S. Tsirkin wrote:
> Quoting r. Sasha Khapyorsky <[EMAIL PROTECTED]>:
> > > > Look at this for example:
> > > > http://sourceware.org/ml/bug-glibc/2005-02/msg00123.html
> > >
> > > Hmm, yea. Do you understand the answer there?
> > > Does not make sense to me ...
>
Or Gerlitz wrote:
> Sean Hefty wrote:
>> Sean Hefty wrote:
One of the systems kernel is actually 2.6.19-rc3 and patches 1-7 (ie
not roland's tree) and i see there some issues also with ip multicast
over ipoib. I will move to use the same kernel config (roland's tree
and patch
Quoting r. Sasha Khapyorsky <[EMAIL PROTECTED]>:
> > > Look at this for example:
> > > http://sourceware.org/ml/bug-glibc/2005-02/msg00123.html
> >
> > Hmm, yea. Do you understand the answer there?
> > Does not make sense to me ...
>
> I less care about the answer, but more about valgrind output
On 22:13 Mon 30 Oct , Jason Gunthorpe wrote:
> On Tue, Oct 31, 2006 at 06:59:02AM +0200, Sasha Khapyorsky wrote:
>
> > > > This would be simpler. However some web searching shows that not all
> > > > printf() implementation permits not null terminated arrays even when
> > > > precision is spec
On 07:11 Tue 31 Oct , Michael S. Tsirkin wrote:
> Quoting r. Sasha Khapyorsky <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] diags/saquery: fix node_desc.description as string
> > usages
> >
> > On 06:30 Tue 31 Oct , Michael S. Tsirkin wrote:
> > > Quoting r. Sasha Khapyorsky <[EMAIL PROTE
On Tue, 2006-10-31 at 07:42, Yevgeny Kliteynik wrote:
> Fixing a broken compilation on windows (problems with data types).
>
> Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]>
Thanks. Applied.
-- Hal
___
openib-general mailing list
openib-genera
Quoting r. Or Gerlitz <[EMAIL PROTECTED]>:
> there must be away to avoid the race within the ID provider module,
There's no other way - go over the archives.
> so at least the api can be saved...
See Documentation/stable_api_nonsense.txt
--
MST
___
Michael S. Tsirkin wrote:
>> Michael S. Tsirkin wrote:
>>> Quoting r. Or Gerlitz <[EMAIL PROTECTED]>:
>>> The race happens on module unload - you might be inside the cm callback when
>>> the module is unloaded. Nothing the module itself does can help here - you
>>> must
>>> synchronize with the c
Sean Hefty wrote:
> Sean Hefty wrote:
>>> One of the systems kernel is actually 2.6.19-rc3 and patches 1-7 (ie
>>> not roland's tree) and i see there some issues also with ip multicast
>>> over ipoib. I will move to use the same kernel config (roland's tree
>>> and patches 1-7), then test ipoib
Fixing a broken compilation on windows (problems with data types).
Signed-off-by: Yevgeny Kliteynik <[EMAIL PROTECTED]>
Index: opensm/osm_ucast_file.c
===
--- opensm/osm_ucast_file.c (revision 10009)
+++ opensm/osm_ucast_file.c
Moni Shoua wrote:
>We already tried to go this way and found that a local Module.symvers is
>not always generated (but we might have missed something though).
>I suggest that you check that this alternative way works under all OSs
>compilation (SuSE and RedHat to be precise)...
>
>
I think Mod
Quoting r. Or Gerlitz <[EMAIL PROTECTED]>:
> Subject: Re: [openib-general] [PATCH] for 2-6-19 rdma/addr: use client
> registration to fix module unload race
>
> Michael S. Tsirkin wrote:
> > Quoting r. Or Gerlitz <[EMAIL PROTECTED]>:
> Require registration with ib_addr module to prevent call
Michael S. Tsirkin wrote:
> Quoting r. Or Gerlitz <[EMAIL PROTECTED]>:
Require registration with ib_addr module to prevent caller from unloading
while a callback is in progress.
>>> ib_cm has this bug as well. Shouldn't we patch it for 2.6.19 too?
>> I know there was a similar discussion
Quoting r. Or Gerlitz <[EMAIL PROTECTED]>:
> >> Require registration with ib_addr module to prevent caller from unloading
> >> while a callback is in progress.
>
> > ib_cm has this bug as well. Shouldn't we patch it for 2.6.19 too?
>
> I know there was a similar discussion which i was not trackin
Michael S. Tsirkin wrote:
> Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
>> Subject: [PATCH] for 2-6-19 rdma/addr: use client registration to fix module
>> unload race
>> Require registration with ib_addr module to prevent caller from unloading
>> while a callback is in progress.
> ib_cm has this b
Vladimir Sokolovsky wrote:
> The alternative way to resolve this issue is the following:
> Save Modules.symvers file generated by OFED kernel modules compilation
> (drivers/infiniband/Modules.symvers).
> It can be added to the kernel-ib-devel RPM in the next OFED release.
> Then in order to compi
Quoting r. Sean Hefty <[EMAIL PROTECTED]>:
> Subject: [PATCH] for 2-6-19 rdma/addr: use client registration to fix module
> unload race
>
> Require registration with ib_addr module to prevent caller from unloading
> while a callback is in progress.
>
> Signed-off-by: Sean Hefty <[EMAIL PROTECTED
Quoting r. Or Gerlitz <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] for 2-6-19 rdma/addr: use client registration to fix
> module unload race
>
> Sean Hefty wrote:
> > Require registration with ib_addr module to prevent caller from unloading
> > while a callback is in progress.
>
> Sean,
>
> Is t
Sean Hefty wrote:
> Require registration with ib_addr module to prevent caller from unloading
> while a callback is in progress.
Sean,
Is there a conceptual/practical difference between the ib_addr and ib_cm
modules which enforces this client registration of the cma being an addr
consumer but n
The alternative way to resolve this issue is the following:
Save Modules.symvers file generated by OFED kernel modules compilation
(drivers/infiniband/Modules.symvers).
It can be added to the kernel-ib-devel RPM in the next OFED release.
Then in order to compile external module copy this Modules.s
58 matches
Mail list logo
