Hi Roland,
Sorry we were distracted by some other work so I did not respond your
email.
Yes, unfortunately I still see the problem.
I get the core dump, but I am not sure what exactly information is
helpful to you.
Anyway, here is some of the output from the core dump:
=
We also use TCP streams for disaster recovery archiving involving very
large amounts of data. We would like to move this to SDP via AIO too.
On Thu, 2006-01-05 at 20:07 -0500, Richard Frank wrote:
> We need both - each for different Oracle clients / functionality with
> respective connection mode
On Thu, Jan 05, 2006 at 02:46:42PM -0800, Bob Woodruff wrote:
> Ranjit wrote,
> >fw rev: 3.03.0003rc16b
>
> I think that 4.7 is the latest (at least for the PCI-E cards)
> and 3.2 ( for the PCI-X cards)
Latest for PCI-X is 3.3.5.
Latest for PCI-e is 4.7.4.
The 3.3.3 is likely to refer to a PCI-
We need both - each for different Oracle clients / functionality with
respective connection models / modes of operation (stream vs datagram).
BTW - Oracle currently uses TCP streams / SDP for Client / middle tier
connectivity to the database. We use UDP / RDS within the database for
inter databas
On Jan 5, 2006, at 11:59 AM, Richard Frank wrote:
Besides OpenIB for Linux and Windows ?
Solaris ?
Sun had a fully working SDP for Solaris that got cut from Solaris 10
right at the last moment. I am not sure what the current status is,
but I know there were folks that were trying to res
>Any platform that supports SDP will have a distinct performance
>advantage - especially if it supports zero copy.
>
>W.R.T. RDS - we are moving to RDS as a replacement for IT-API / uDAPL /
>and standard UDP.
Are you planning on using SDP or RDS? What platforms will have RDS that will
not have SD
>> Note that with
>> a MAD interface, kernel modules would still have access to
>> any cached data. I
>> also wanted to stick with usermode to allow saving the cache
>> to disk, so that it
>> would be available immediately after a reboot. (My
>> assumption being that
>> changes to the network to
What platforms does IT-API inter-operate with ?
OK - for HPUX we can fall back to normal TCP / sockets - for the stream
mode cases.
Any platform that supports SDP will have a distinct performance
advantage - especially if it supports zero copy.
W.R.T. RDS - we are moving to RDS as a replacement
Fix mthca_create_eq for when the EQ size is not a power of 2.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/mthca/mthca_eq.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
466200562ccd80f728f7ef60
Modify_qp should check that the physical port number provided
is a legal value.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/mthca/mthca_qp.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
38d1e7
Check error return on call to mthca_dev_lim for Tavor
(as is done for memfree).
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/mthca/mthca_main.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
aa2f93
Thinko: 64 bytes is the minimum SRQ WQE size (not the maximum).
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Signed-off-by: Roland Dreier <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/mthca/mthca_srq.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
1d7d2f6f476cf7aa65f9f740a
Thanks, applied.
___
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
Thanks, applied.
___
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
Thanks, applied.
___
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
Ugh, the latest git tree still has version 2.6.15, so there's no way
to tell if add_hotplug_env_var() has changed or not. This will fix
itself once 2.6.16-rc1 comes out in about 10 days, but I don't know of
a good way to fix it until then.
You can hack drivers/infiniband/core/sysfs.c by hand to c
On 05.01.2006 [15:15:10 -0800], Roland Dreier wrote:
> Ugh, the latest git tree still has version 2.6.15, so there's no way
> to tell if add_hotplug_env_var() has changed or not. This will fix
> itself once 2.6.16-rc1 comes out in about 10 days, but I don't know of
> a good way to fix it until the
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
> Your kernel footprint is smaller than I expected, which is
> good.
The key is that while there are O(N^2) path records in a fabric, only O(N) are
of interest to a given node. Hence if you only replicate entries where this
node is the source the siz
Kanevsky, Arkady wrote:
Arlin,
nice proposal, thanks.
I have one high level question and a few specific technical ones.
1. Why do you want to provide this functionality via extension instead
of part of new DAT spec, say 2.0?
This will allow Consumers to use all events, operations, and
Provid
On Thu, 2006-01-05 at 18:24, Sean Hefty wrote:
> >For the precise language, see C15-0-1.24 p. 923 IBA 1.2:
> >
> >
> >C15-0.1.24: It shall be possible to determine the location of SA from
> >any
> >endport by sending a GMP to QP1 (the GSI) of the node identified by the
> >endport's PortInfo:MasterS
Ranjit wrote,
>fw rev: 3.03.0003rc16b
I think that 4.7 is the latest (at least for the PCI-E cards)
and 3.2 ( for the PCI-X cards)
and I think the latest FW is required for correct operation with the openIB
stack.
Michael is this correct ?
woody
__
On Thu, 2006-01-05 at 17:04, Sean Hefty wrote:
> >> I hadn't fully figured this out yet. I'm not sure if another MAD class is
> >> needed or not. My goal is to implement this as transparent to the
> >application
> >> as possible without violating the spec, perhaps appearing as an SA on a
> >> dif
>- It is implemented in kernel mode
> - while user mode may help during initial debug, it will be important
for
> kernel mode ULPs such as SRP, IPoIB and SDP to also make use of
>these records
Your kernel footprint is smaller than I expected, which is good. Note that with
a MA
On Thu, 2006-01-05 at 16:51, Sean Hefty wrote:
> I agree that this is a problem, but I my preference would be for a dedicated
> kernel module to handle multicast join/leave requests.
In addition to multicast, it's also service records and event
subscriptions too.
-- Hal
> From: Bob Woodruff [mailto:[EMAIL PROTECTED]
>
> Ranjit wrote,
> >fw rev: 3.03.0003rc16b
>
> I think that 4.7 is the latest (at least for the PCI-E cards)
> and 3.2 ( for the PCI-X cards)
> and I think the latest FW is required for correct operation
> with the openIB
> stack.
> Michael is t
fw rev: 3.03.0003rc16b
On 1/5/06, Woodruff, Robert J <[EMAIL PROTECTED]> wrote:
> >I'm having the same problem with the kernel that Redhat posted
>
> >"kernel-smp-2.6.9-22.14.EL.OpenIB_3965.3.i686.rpm"
>
> I have not seen any reset issues with 4507 or the
> Redhat 3965 kernel on a mellanox SDR PC
>Sean, This is great. This is a feature which I find near and dear and is very
>important to large fabric scalability. If you look in contrib in the infinicon
>area, you will see a version of a SA replica which we implemented in the
>linux_discovery tree. The version in SVN is a little dated, bu
>> I hadn't fully figured this out yet. I'm not sure if another MAD class is
>> needed or not. My goal is to implement this as transparent to the
>application
>> as possible without violating the spec, perhaps appearing as an SA on a
>> different LID.
>
>The LID for the (real) SA is determined fr
>I'm having the same problem with the kernel that Redhat posted
>"kernel-smp-2.6.9-22.14.EL.OpenIB_3965.3.i686.rpm"
I have not seen any reset issues with 4507 or the
Redhat 3965 kernel on a mellanox SDR PCI-E card
on EM64T platform. I have also ran 4507 on an IPF platform with
PCI-X cards.
Wha
On 05.01.2006 [13:08:39 -0800], Roland Dreier wrote:
> Sorry, my previous "fix" was totally bogus. I checked something in
> that should compile OK against both 2.6.15 and mainline.
with 4785, I still get:
drivers/infiniband/core/sysfs.c: In function `ib_device_uevent':
drivers/infiniband/core/sy
>* Regarding the sentence:"Clients would send their queries to the sa_cache
>instead of the SA"
> I would propose that a "SA MAD send switch" be implemented in the core: Such
>a switch
> will enable plugging in the SA cache (I would prefer calling it SA local
>agent due to
> its extended func
I'm having the same problem with the kernel that Redhat posted
"kernel-smp-2.6.9-22.14.EL.OpenIB_3965.3.i686.rpm"
from:
http://people.redhat.com/dledford/Infiniband/RHEL-4/kernel/2.6.9-22.14.EL.OpenIB_3965.3/i686/
Again, I know that the card is functional.
Ranjit
On 1/5/06, Ranjit Pandit <[
> From: Sean Hefty [mailto:[EMAIL PROTECTED]
>
> I've been given the task of trying to come up with an
> implementation for an SA
> cache. The intent is to increase the scalability and
> performance of the openib
> stack. My current thoughts on the implementation are below.
> Any feedback
On 05.01.2006 [13:08:39 -0800], Roland Dreier wrote:
> Sorry, my previous "fix" was totally bogus. I checked something in
> that should compile OK against both 2.6.15 and mainline.
I assume that was what caused this:
drivers/infiniband/core/sysfs.c:653: error: unknown field `hotplug' specified
It appears that dtest.c does not ever exercise the dat_cno_wait() or
dat_evd_wait() calls. The "polling" flag is initialized to "1" at
declaration time. Specifying "-p" on the command line will set
"polling" to "1", but there is nothing that sets "polling" to "0".
Therefore "polling" is always "1"
Sorry, my previous "fix" was totally bogus. I checked something in
that should compile OK against both 2.6.15 and mainline.
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe
Michael> Hmm. Lets suppose I have a first chunk in bytes 1 to
Michael> 2095, and then another chunk in bytes 0x10 to
Michael> 0x1ff - should not we limit the page size to 4K? Does
Michael> your proposed change do this?
Yes, you're right again. It seems like we can get rid
Has anybody seen this problem before?
modprobe ib_mthca
ib_mthca: Mellanox InfiniBand HCA driver v0.06 (June 23, 2005)
ib_mthca: Initializing :03:00.0
ACPI: PCI interrupt :03:00.0[A] -> GSI 24 (level, low) -> IRQ 233
ib_mthca :03:00.0: PCI device did not come back after reset, abortin
On Thu, Jan 05, 2006 at 02:59:43PM -0500, Richard Frank wrote:
> Besides OpenIB for Linux and Windows ?
> HP-UX ?
Almost certainly not for HPUX.
Oracle should plan on continuing to use existing IT-API interface.
I'm told "it's known to work" and meets HP's requirements
(which RDS does not AFAICT).
Besides OpenIB for Linux and Windows ?
Solaris ?
AIX ?
HP-UX ?
Are there any plans for interoperability tests / have any completed ?
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubs
On 05.01.2006 [11:44:47 -0800], Roland Dreier wrote:
> Nishanth> Hi all, New build failure today:
>
> Nishanth> drivers/infiniband/core/sysfs.c: In function
> Nishanth> `ib_device_hotplug':
> Nishanth> drivers/infiniband/core/sysfs.c:440: warning: implicit
> Nishanth> declarati
Nishanth> Hi all, New build failure today:
Nishanth> drivers/infiniband/core/sysfs.c: In function
Nishanth> `ib_device_hotplug':
Nishanth> drivers/infiniband/core/sysfs.c:440: warning: implicit
Nishanth> declaration of function `add_hotplug_env_var'
Looks like add_hotplug_env_
Thanks, applied.
___
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
On Thu, 2006-01-05 at 03:24, Yael Kalka wrote:
> Hi Hal,
>
> When trying to run OpenSM on a system with 2 hca cards, we noticed
> that there is a problem with the osm_vendor_get_all_port_attr.
> What happens is that we are saving the port 0 for each hca, though
> this data is relevant for the defa
Hi all,
New build failure today:
drivers/infiniband/core/sysfs.c: In function `ib_device_hotplug':
drivers/infiniband/core/sysfs.c:440: warning: implicit declaration of function
`add_hotplug_env_var'
drivers/infiniband/core/sysfs.c: At top level:
drivers/infiniband/core/sysfs.c:653: error: unkno
This patch is for CMA changes to support iWARP and is relative to the
trunk. It includes the latest ib_addr generalizations that allowed for
some simplification in the rdma_resolve_addr implementation. This patch
needs the include file patch to compile.
I tested this on 2.6.14.5 with the AMSO110
This patch is for the include files needed to support iWARP and is
relative to the trunk. I added some new device capabilities bits that
could use some name tweaking --
Thanks,
Signed-off-by: Tom Tucker <[EMAIL PROTECTED]>
Index: rdma/ib_verbs.h
===
On Thu, 2006-01-05 at 08:25, Yael Kalka wrote:
> Hi Hal,
>
> Attached is a fix for the qp0_mads_outstanding handling, according to
> what I've described in the previous mail.
Thanks. Applied with some formatting changes.
-- Hal
___
openib-general mail
Bryan O'Sullivan wrote:
On Thu, 2005-12-29 at 15:42 +0100, Christoph Hellwig wrote:
PathScale's use of this language is not original. SGI has used, and perhaps
originated, the additional language.
XFS has been switched to a normal short GPL boilerplate exactly because
this wording is not
On Thu, 2005-12-29 at 15:42 +0100, Christoph Hellwig wrote:
> > PathScale's use of this language is not original. SGI has used, and perhaps
> > originated, the additional language.
> XFS has been switched to a normal short GPL boilerplate exactly because
> this wording is not okay.
FYI, we have
Fix mthca_create_eq for when the EQ size is not a power of 2.
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: linux-2.6.14.3-kgdb/drivers/infiniband/hw/mthca/mthca_eq.c
===
--- linux-2.6.14.3-kgdb.orig/drivers/infiniband
On Wed, 2006-01-04 at 13:28 -0800, Roland Dreier wrote:
> Isn't there some way you can use the same SMA (subnet management
> agent) interface in all the cases?
I'll look into it, but I rather doubt it.
> Can ipath_mad.c just go away in
> favor of your userspace SMA?
Our userspace SMA is a tiny
Hi Eitan,
On Thu, 2006-01-05 at 07:27, Eitan Zahavi wrote:
> Hi Sean,
>
> This is great initiative - tackling an important issue.
> I am glad you took this on.
>
> Please see below.
>
> Sean Hefty wrote:
> > I've been given the task of trying to come up with an implementation for
> > an SA cac
On Wed, 2006-01-04 at 13:26 -0800, Roland Dreier wrote:
> Yes, this might be a good idea. The "core" driver looks like it is
> suffering from really being several things stuck together.
Yes, this is undoubtedly the case; we developed it organically based on
our evolving needs, and we're only now
Hi Sean,
On Tue, 2006-01-03 at 20:15, Sean Hefty wrote:
> Hal Rosenstock wrote:
> >>I've been given the task of trying to come up with an implementation for an
> >>SA
> >>cache. The intent is to increase the scalability and performance of the
> >>openib
> >>stack. My current thoughts on the
Hi Yael,
On Thu, 2006-01-05 at 07:52, Yael Kalka wrote:
> Hi Hal,
> I've reviewed the code and as you noted - there is a bug in the code,
> actually 2 bugs.
> The qp0_mads_outstanding counter is incremented on mads with response
> expected.
> In the "regular" flow this counter is decremented throu
Applied r4770.
Thanks,
Dan
On 1/5/06, Or Gerlitz <[EMAIL PROTECTED]> wrote:
> more cleanups which are possible following the iscsi_iser/iser merge:
> remove unused struct iscsi_buf, make some func call pathes shorter.
>
>
> Index: ulp/iser/iscsi_iser.h
> ==
libmthca: fix memory leak in mthca_destroy_qp and mthca_destroy_srq.
Signed-off-by: Jack Morgenstein <[EMAIL PROTECTED]>
Index: last_stable/src/userspace/libmthca/src/verbs.c
===
--- last_stable.orig/src/userspace/libmthca/src/verbs.
mthca: add alternate path support.
Signed-off-by: Dotan Barak <[EMAIL PROTECTED]>
Signed-off-by: Michael S. Tsirkin <[EMAIL PROTECTED]>
Index: last_stable/drivers/infiniband/hw/mthca/mthca_qp.c
===
--- last_stable.orig/drivers/infini
Hi Hal,
Attached is a fix for the qp0_mads_outstanding handling, according to
what I've described in the previous mail.
Thanks,
Yael
Signed-off-by: Yael Kalka <[EMAIL PROTECTED]>
Index: opensm/osm_vl15intf.c
===
--- opensm/osm_vl
Jack Morgenstein has discovered the following race condition in
libmthca. We are actually hitting it in testing.
Thread A destroys QP A at the kernel side by calling ibv_cmd_destroy_qp, but its
time-slice is over before removing it from the user-space qp_table removal.
Thread B allocates QP B, re
Hi Hal,
I've reviewed the code and as you noted - there is a bug in the code,
actually 2 bugs.
The qp0_mads_outstanding counter is incremented on mads with response
expected.
In the "regular" flow this counter is decremented through
__osm_sm_mad_ctrl_retire_trans_mad,
after the response was receive
Hi Sean,
This is great initiative - tackling an important issue.
I am glad you took this on.
Please see below.
Sean Hefty wrote:
I've been given the task of trying to come up with an implementation for
an SA cache. The intent is to increase the scalability and performance
of the openib stack
Hi Hal,
I've noticed that sometimes when killing OpenSM using ^C not all
threads are killed.
The reason for that is that there are threads that mask the
signalling, and when removing the ^C handling from OpenSM, these
threads still mask the signalling and stay alive as a result.
The following pat
more cleanups which are possible following the iscsi_iser/iser merge:
remove unused struct iscsi_buf, make some func call pathes shorter.
Index: ulp/iser/iscsi_iser.h
===
--- ulp/iser/iscsi_iser.h (revision 4768)
+++ ulp/iser/i
Applied r4761.
Thanks,
Dan
On 1/5/06, Or Gerlitz <[EMAIL PROTECTED]> wrote:
> some leftovers of the mem registration for unsolicited data change.
> post_lock field of struct iscsi_iser_conn removed as the xmitsema
> field serializes connection xmits, removed the unused conn_lock.
>
> Signed-off-b
Hi Hal,
When trying to run OpenSM on a system with 2 hca cards, we noticed
that there is a problem with the osm_vendor_get_all_port_attr.
What happens is that we are saving the port 0 for each hca, though
this data is relevant for the default port only once.
The result is that if running with -g
67 matches
Mail list logo
