On Thu, Jul 28, 2005 at 09:48:59AM +0300, Michael S. Tsirkin wrote:
> Quoting r. Greg KH <[EMAIL PROTECTED]>:
> > Subject: Re: [PATCH] arch/xx/pci: remap_pfn_range -> io_remap_pfn_range
> >
> > On Tue, Jul 26, 2005 at 01:32:00AM +0300, Michael S. Tsirkin wrote:
> > > Greg, Martin, does the followi
Quoting r. Greg KH <[EMAIL PROTECTED]>:
> Subject: Re: [PATCH] arch/xx/pci: remap_pfn_range -> io_remap_pfn_range
>
> On Tue, Jul 26, 2005 at 01:32:00AM +0300, Michael S. Tsirkin wrote:
> > Greg, Martin, does the following make sense?
> > If it does, should other architectures be updated as well?
On Wed, Jul 27, 2005 at 09:30:17PM -0700, Roland Dreier wrote:
> Greg> Hm, you do realize that io_remap_pfn_range() is the same
> Greg> thing as remap_pfn_range() on i386, right?
>
> Greg> So, why would this patch change anything?
>
> It's not the same thing under Xen. I think this p
Greg> Hm, you do realize that io_remap_pfn_range() is the same
Greg> thing as remap_pfn_range() on i386, right?
Greg> So, why would this patch change anything?
It's not the same thing under Xen. I think this patch fixes userspace
access to PCI memory for XenLinux.
- R.
On Tue, Jul 26, 2005 at 01:32:00AM +0300, Michael S. Tsirkin wrote:
> Greg, Martin, does the following make sense?
> If it does, should other architectures be updated as well?
>
> ---
>
> Convert i386/pci to use io_remap_pfn_range instead of remap_pfn_range.
>
> Signed-off-by: Michael S. Tsirkin
Linus, please pull from
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This will update the following files:
core/ucm.c| 88 +-
core/uverbs.h |1
core/uverbs_main.c|
On Wed, 2005-07-27 at 21:27 -0400, Hal Rosenstock wrote:
> Which IBAT are you using ? It is the one in the trunk or the one on
> shaharf-ibat branch ?
uat.[ch] isn't in trunk yet, right?
-tduffy
signature.asc
Description: This is a digitally signed message part
_
Tziporet, This did appear to be a firmware issue. After the update I have a latency difference on the order of .2 uSec which seems reasonable, much better than a ~5. uSec penalty! Thanks for the help, Galen On Jul 27, 2005, at 12:38 AM, Tziporet Koren wrote: Hi Galen, You are working with an old
Hi Arlin,
On Wed, 2005-07-27 at 20:39, Arlin Davis wrote:
> I move from a 2.6.11 kernel to 2.6.12.3 and am now having some problems
> with IBAT. (svn 2919)
>
> Running the simple example...
>
> [EMAIL PROTECTED] examples]$ ./uatt
> uatt: main: uat test start
> uatt: main: ib_at_route_by_ip: ret
Hi Hal,
I move from a 2.6.11 kernel to 2.6.12.3 and am now having some problems
with IBAT. (svn 2919)
Running the simple example...
[EMAIL PROTECTED] examples]$ ./uatt
uatt: main: uat test start
uatt: main: ib_at_route_by_ip: ret 0 errno 0 for request 1 id 1 1
[EMAIL PROTECTED] examples]$
Me
I've created a git tree of patches to be sent upstream to Linus. You
can pull it from
http://www.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
or browse it with the web interface at
http://www.kernel.org/git/?p=linux/kernel/git/roland/infiniband.git;a=summary
So far, this
On Wed, Jul 27, 2005 at 02:13:18PM -0700, Tom Duffy wrote:
> [ Libor, sorry for the dup's, my sendmail is fucked ]
>
> No need for linux/version.h in SDP, either.
No problem, I've removed the include.
-Libor
___
openib-general mailing list
openib-gen
[ Libor, sorry for the dup's, my sendmail is fucked ]
No need for linux/version.h in SDP, either.
Signed-off-by: Tom Duffy <[EMAIL PROTECTED]>
Index: linux-2.6.13-rc3-openib/drivers/infiniband/ulp/sdp/sdp_main.h
===
--- linux-2.6.13
That's great Roland.
Thanks a lot.
Cheers,
Steve.
Roland Dreier wrote:
Steve> Hi, I would like to use the OpenIb drivers with a 2.6.12
Steve> kernel with the realtime-preemt patch maintained by Ingo
Steve> Molnar. I get the following error in sdp_conn.c using svn
Steve> 2909:
Thanks, I've finally applied this to our repository, and will merge it
upstream for 2.6.14 (unless it shows up by some other route first).
- R.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
Steve> Hi, I would like to use the OpenIb drivers with a 2.6.12
Steve> kernel with the realtime-preemt patch maintained by Ingo
Steve> Molnar. I get the following error in sdp_conn.c using svn
Steve> 2909:
Steve> line 49: error: SPIN_LOCK_UNLOCKED undeclared in this
Steve>
Hi,
I would like to use the OpenIb drivers with a 2.6.12 kernel with the
realtime-preemt patch maintained by Ingo Molnar. I get the following
error in sdp_conn.c using svn 2909:
line 49: error: SPIN_LOCK_UNLOCKED undeclared in this function
Has anybody out there got this working or could giv
Hal> Only print messages when debug level set
I just saw Andrew send all the -mm changes up to Linus, so I'll queue
this one up as well.
Hal> The only other changes have to do with copyrights. Should
Hal> they be pushed for 2.6.13 ?
I don't think it's a good idea at this point in the
On Wed, 2005-07-27 at 14:00, Roland Dreier wrote:
> Here is the set of patches I am planning on sending upstream this week
> for inclusion in 2.6.13. In addition to bug fixes, I am including
> fasync support for uverbs -- it seems worth having this in 2.6.13, so
> that code can rely on it any rele
Here is the set of patches I am planning on sending upstream this week
for inclusion in 2.6.13. In addition to bug fixes, I am including
fasync support for uverbs -- it seems worth having this in 2.6.13, so
that code can rely on it any released kernel.
Please let me know if you think there are ot
Pete> I think those are solvable problems and a reasonable
Pete> approach. There are a few reasons I didn't make this
Pete> coupling more intimate from the start:
All fair enough -- I was just scared of writing code to deal with the
queue overflow!
- R.
_
Roland Dreier wrote:
The first statement in this paragraph is false. It's easy to strace a
simple program that does something like
x = malloc(100);
free(x);
and watch glibc do an mmap(... MAP_ANONYMOUS ...) followed by
munmap(). Even for smaller allocations, glibc may use
Hal wrote,
>Do you have the log file as to where in the initialization this was
>detected ? Do you know how to reproduce this ? I'll also do a code
>inspection to see if I can find it.
>-- Hal
I don't have the log file, but it is easy to reproduce.
Load the stack on an HCA that has old firmwar
Add ucm to udev rules
Signed-off-by: Hal Rosenstock <[EMAIL PROTECTED]
Also, should these (https://openib.org/svn/trunk/contrib/mellanox/) be
moved to a gen2 location ?
Index: 90-ib.rules
===
--- 90-ib.rules (revision 2917)
+++ 90-i
[EMAIL PROTECTED] wrote on Mon, 25 Jul 2005 16:36 -0700:
> Hmm, thinking about this some more, it occurs to me that it might be
> possible for the kernel and userspace to work together even more
> efficiently. Does the following make sense?
>
> When memory is registered, userspace tells the kerne
On Wed, 2005-07-27 at 09:54, James Lentini wrote:
> Being able to debug connectivity problems at the IB level strikes me
> as very useful. Perhaps some people expect to always use IPoIB on
> their IB network, and therefore plan to use IP tools. Even in these
> configurations, native IB protocols
On Wed, Jul 27, 2005 at 09:52:02AM -0400, Pete Wyckoff wrote:
> [EMAIL PROTECTED] wrote on Wed, 27 Jul 2005 10:02 +0300:
> > Then we understand Pete differently. This is what he wrote in his first
> > email on the subject:
> >The MPI library essentially makes a system call before
> >reusing
On Wed, 27 Jul 2005, Hal Rosenstock wrote:
On Tue, 2005-07-26 at 13:37, James Lentini wrote:
On Mon, 25 Jul 2005, Hal Rosenstock wrote:
Hi,
Here is a writeup on proposed IB endport liveness and resposiveness.
This "grew" out of discussions on ibping on this list some time ago.
Thanks in ad
[EMAIL PROTECTED] wrote on Wed, 27 Jul 2005 10:02 +0300:
> Then we understand Pete differently. This is what he wrote in his first
> email on the subject:
>The MPI library essentially makes a system call before
>reusing a cached memory registration to verify it is still valid.
> How "the MP
On Tue, 2005-07-26 at 13:37, James Lentini wrote:
> On Mon, 25 Jul 2005, Hal Rosenstock wrote:
>
> > Hi,
> >
> > Here is a writeup on proposed IB endport liveness and resposiveness.
> > This "grew" out of discussions on ibping on this list some time ago.
> > Thanks in advance for any comments on t
On Tue, 2005-07-26 at 17:20, [EMAIL PROTECTED] wrote:
> Author: jlentini
> Date: 2005-07-26 14:20:22 -0700 (Tue, 26 Jul 2005)
> New Revision: 2915
>
> Modified:
>gen2/users/jlentini/linux-kernel/README
> Log:
> Updated README with new code location
> Signed-off-by: James Lentini <[EMAIL PROTEC
On Tue, 2005-07-26 at 17:19, Woodruff, Robert J wrote:
> Hi Hal,
>
> I was setting up a new 32-node cluster with the openIB code
> here in Oregon. I ran into a problem where the mthca driver failed
> to initialize due to the fact the the firmware was down rev.
> I origianlly did not notice that
[kdapltest]: this patch adds the option of using memory registration
types other then the default PHY on the server side.
Signed-off-by: Guy German <[EMAIL PROTECTED]>
Index: dapltest/test/dapl_server.c
===
--- dapltest/test/dapl_se
[kdapl]: this patch adds the option of using DAT_MEM_TYPE_IA in dat_lmr_kcreate
Signed-off-by: Guy German <[EMAIL PROTECTED]>
Index: infiniband/ulp/kdapl/ib/dapl_openib_util.c
===
--- infiniband/ulp/kdapl/ib/dapl_openib_util.c (rev
Title: RE: [openib-general] Shared Receive Queue
The performance of SRQ was improved to be identical to regular QP in the latest FW release for all devices.
Tziporet
-Original Message-
From: Galen M. Shipman [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 26, 2005 5:57 PM
To: Or Gerli
On Tue, Jul 26, 2005 at 09:43:44PM -0700, Roland Dreier wrote:
> Gleb> This is what Pete did. We are back to on syscall on each
> Gleb> registration. And the worst case is three syscalls. First
> Gleb> to check that mapping is valid, second to deregister memory
> Gleb> if it is not
36 matches
Mail list logo
