Shirley> This patch has fixed a deadlock problem: the caller calls
Shirley> ipoib_put_ah() while holding priv->lock. (In
Shirley> ipoib_free_ah() the same lock is reacquired.) This also
Shirley> fixes the ipoib_flush_paths() calls __patch_free()
Shirley> without holding priv->lo
$B5W$7$V$j!http://nhk.upper.jp/09261-2.html
$B$=$&$=$&!";d!":G6a$+$J$j$*$9$9$a$NI{6H8+$D$1$F$s!#(B
$B$3$l$O!"$$$m$s$J?M$KCN$i$l$kA0$K!"<+J,$NM'C#$K$O65$($J$"$+$s!*!*!*(B
$B$C$F;W$C$FO"Mm$7$F$s!#(Bhttp://nhk.upper.jp/09261-2.html
$B;d$b!"$^$@;O$a$?$H$3$m$J$s$d$1$I!"(B
$B$3$l$,!"0J30$K$b$*
Hi Arkady,
As I mentioned in the BOF, I have a person (Arlin Davis) that can help
with
developing a uDAPL provider for the openib.org verbs.
After discussing it more
with folks here, is seems to us that perhaps for the uDAPL user-mode
library, it be provided to openib.org under a dual BSD + LG
> It just depends on how long it takes to stabilize
the various components.
Agree. Basically, the more stable, the
more chance for
components to be picked up in the distro
release.
thanks
Shirley Ma
IBM Linux Technology Center
15300 SW Koll Parkway
Beaverton, OR 97006-6063
Phone(Fax): (503) 578
Roland,
Please review this patch.
This patch has fixed a deadlock problem:
the caller calls ipoib_put_ah() while holding priv->lock. (In ipoib_free_ah()
the same lock is reacquired.) This also fixes the ipoib_flush_paths() calls
__patch_free() without holding priv->lock.
My email has problem t
On Mon, 2005-02-14 at 14:20 -0800, Libor Michalek wrote:
> Here's a patch for the print format warning in the debug data path.
OK, good. Thanks. Now clean on x86_64 with data debug on. Still
seeing these on sparc64:
/build1/tduffy/openib-work/linux-2.6.10-openib/drivers/infiniband/ulp/sdp/sd
On Mon, Feb 14, 2005 at 01:42:36PM -0800, Tom Duffy wrote:
> On Fri, 2005-02-11 at 19:47 -0800, Tom Duffy wrote:
> > On Fri, 2005-02-11 at 18:40 -0800, Libor Michalek wrote:
> > > If no one objects, a patch to clean up compile warnings on x86_64. Most
> > > of the warnings are a result of print f
On Fri, 2005-02-11 at 19:47 -0800, Tom Duffy wrote:
> On Fri, 2005-02-11 at 18:40 -0800, Libor Michalek wrote:
> > If no one objects, a patch to clean up compile warnings on x86_64. Most
> > of the warnings are a result of print format mismatches, the most common
> > being the need to use %Zu for
On Mon, Feb 14, 2005 at 12:36:38PM -0800, Grant Grundler wrote:
> On Mon, Feb 14, 2005 at 11:29:44AM -0800, Libor Michalek wrote:
> > Good idea, in three places I got rid of the cast, and then used an inline
> > in two other places. Here's the updated patch.
>
> cool - thanks. Can these two als
formerly working opensm starts to get these:
[1108414727:000284173][411FF970] -> umad_receiver: send completed with
error(method=1 attr=11) -- dropping.
[1108414727:000384171][411FF970] -> umad_receiver: send completed with
error(method=1 attr=11) -- dropping.
[1108414727:000484169][411FF970] -
On Mon, Feb 14, 2005 at 11:29:44AM -0800, Libor Michalek wrote:
> Good idea, in three places I got rid of the cast, and then used an inline
> in two other places. Here's the updated patch.
cool - thanks. Can these two also be changed?
> Index: infiniband/ulp/sdp/sdp_conn.c
> ==
On Mon, Feb 14, 2005 at 08:23:44AM -0800, Tom Duffy wrote:
> On Fri, 2005-02-11 at 21:58 -0800, Grant Grundler wrote:
> > And sdp_main.h violates one of the kernel include file rules:
> > include asm/ headers *after* linux/ headers.
>
> Include asm/ headers *after* linux/ headers. This builds
On Fri, Feb 11, 2005 at 06:31:06PM -0800, Tom Duffy wrote:
> Annotate __user pointers in sdp_inet.c.
>
Applied and checked in. Thanks.
-Libor
> Index: drivers/infiniband/ulp/sdp/sdp_inet.c
> ===
> --- drivers/infiniband/ulp/sdp/s
On Fri, Feb 11, 2005 at 09:58:27PM -0800, Grant Grundler wrote:
> On Fri, Feb 11, 2005 at 06:40:58PM -0800, Libor Michalek wrote:
> > If no one objects, a patch to clean up compile warnings on x86_64.
>
> I haven't applied this patch yet - I read mail on the other side of
> a firewall where my m
Libor> Do you know which architecture was the impetus for a 4th
Libor> page table level?
x86-64 I believe. x86-64 actually always uses 4 levels in HW but
Linux had to make one of them trivial, which limited a single memory
map to 512 GB. Apparently some workloads that mmap'ed a lot of
On Mon, Feb 14, 2005 at 10:26:19AM -0800, Roland Dreier wrote:
> Grant> The following patch makes _sdp_iocb_page_save() look like
> Grant> the code in mm/rmap.c. I have no clue if it's right or not.
> Grant> But it now builds on ia64. Not tested yet.
>
> 4-level page tables went in aft
On Mon, Feb 14, 2005 at 10:26:19AM -0800, Roland Dreier wrote:
> 4-level page tables went in after 2.6.10, right?
Sorry - no clue.
> So I think we should
> hang onto this patch and apply it to svn after 2.6.11 is out (any day
> now, presumably...)
uhm...2.6.11-rc4 just released. It could be a bi
Mike> This would be really helpful to many people. I would also
Mike> suggest that as the userspace verbs is written by you and
Mike> others, to document and make available your testing code.
Mike> This will get users a foothold.
Yes, as I said the example code will be part of the
Roland Dreier wrote:
A few comments about documentation:
There seem to be two distinct requests in this thread. First, there
is a desire for a basic verbs example that can be used to get
started. I am writing code like this as I develop the userspace verbs
library, since I need basic tests to mak
Tziporet Koren wrote:
Hi,
I don't think we need an example of VAPI code since gen2 will be the
real thing.
When user level verbs will work we will port Mellanox performance test
(known as perf_main) to gen2.
From this test one can learn how to get the good performance out of IB.
NO, NO, NO. If
Grant> The following patch makes _sdp_iocb_page_save() look like
Grant> the code in mm/rmap.c. I have no clue if it's right or not.
Grant> But it now builds on ia64. Not tested yet.
4-level page tables went in after 2.6.10, right? So I think we should
hang onto this patch and apply it
A few comments about documentation:
There seem to be two distinct requests in this thread. First, there
is a desire for a basic verbs example that can be used to get
started. I am writing code like this as I develop the userspace verbs
library, since I need basic tests to make sure the library w
Matt wrote > Several developers have volunteered to work on uDAPL. The
DAT
>collaborative is working to get a GPL/BSD version of uDAPL to OpenIB.
>James and Arkady from NetApp gave a DAT talk. They mentioned needing 1
>month to get the GPL code, and another month or two to fork the code
>base.
On Fri, 2005-02-11 at 21:58 -0800, Grant Grundler wrote:
> And sdp_main.h violates one of the kernel include file rules:
> include asm/ headers *after* linux/ headers.
Include asm/ headers *after* linux/ headers. This builds for me on x86,
x86_64, and sparc64.
Signed-off-by: Tom Duffy <[EM
Sinate and Mike,
Lets take this off line, we can provide some help. But first we will
need to better understand what you are trying to implement (eg. driver or user
space app, UD or RC, etc).
Todd Rimmer
> -Original Message-
> From: Sinate [mailto:[EMAIL PROTECTED]
> Sent: Sunda
Title: RE: [openib-general] Re: FW: summary of my understanding on our common work on openib.org
1. This attribute is not used also by gen1 code and we checked with customers.
2. It is not useful since on RQ there any logical flow will work with completions.
Tziporet
-Original Message-
Title: RE: [openib-general] Looking for a Mellanox VAPI example C/C++ code
Hi,
I don't think we need an example of VAPI code since gen2 will be the real thing.
When user level verbs will work we will port Mellanox performance test (known as perf_main) to gen2.
From this test one can learn h
On Mon, 2005-02-14 at 08:33, Eitan Zahavi wrote:
> The lowest level to catch all MAD buffer allocations is in the
> osm_vendor_get() call.
> It could certainly zero out the mad buffer it provides.
Sounds like this is not being done currently. That's what I wanted to
confirm. Thanks.
-- Hal
>
>
Title: RE: OpenIB OpenSM and Reserved Fields on Transmit
The lowest level to catch all MAD buffer allocations is in the osm_vendor_get() call.
It could certainly zero out the mad buffer it provides.
Eitan Zahavi
Design Technology Director
Mellanox Technologies LTD
Tel:+972-4-9097208
Fax:+972
Hi Eitan,
With OpenSM, in general, is there an approach that is being used to
ensure the reserved fields at set to 0 on send ? I couldn't ascertain
this from the code and I do observe reserved fields set to non 0 on
send. One approach would be to clear the MAD when it is first obtained.
Another wo
Hi,
From: Christoph Hellwig <[EMAIL PROTECTED]>
Subject: Re: FW: [openib-general] Minutes from DAPL BOF at OpenIB Workshop
Date: Sun, 13 Feb 2005 15:29:06 +0100
> On Sun, Feb 13, 2005 at 03:25:24PM +0100, Christoph Hellwig wrote:
> > On Sun, Feb 13, 2005 at 10:37:12AM +0200, Dan Bar Dov wrote:
>
Hi,
From: Tom Duffy <[EMAIL PROTECTED]>
Subject: Re: FW: [openib-general] Minutes from DAPL BOF at OpenIB Workshop
Date: Thu, 10 Feb 2005 10:51:25 -0800
> On Thu, 2005-02-10 at 18:46 +0100, Christoph Hellwig wrote:
> > Maybe you should lay down the requirement first.
>
> I'll take a crack at it
On Sun, 2005-02-13 at 23:45 -0800, Bill Thompson wrote:
> Hope everyone had a nice time in Sonoma. Sorry I missed it...
>
> Got a question:
>
> Can someone take a SWAG at when an OpenIB stack (OpenSM, OpenMPI,
> uDAPL, iSCSI, iSER, IPoIB, SDP, kDAPL) will be in RHE 4?
>
> Now that could be CVS
33 matches
Mail list logo
