Troy Benjegerdes wrote:
Um. So I built openib-1.1 from the OFED-1.1 tarball, and now I get:
*
p5l9:/usr/src/openib-1.1/src/userspace/libehca# ibv_devinfo
libibverbs: Warning: no userspace device-specific driver found for
uverbs0
driver search path: /usr/local/lib/infiniband
Sean,
you got it!
Setting the hop_limit from 64 down to 0 or 1 solved the problem. :-)
Don't ask me where I got that hop_limit from, it must have been an
example I found somewhere.
Can you explain why that hop_limit/is_global makes a difference in
communication between gen1 and gen2? Does the
Hello Moni,
Thanks for your answer.
I had installed:
glibc-devel (2.5-17)
glibc-devel-32bit (2.5-17)
when i tried to install the OFED package.
I saw in the mailing list that is available OFED 1.1.1, should I try and
install it?
Thanks,
Diego
- Original Message -
From: Moni Levy
What if we didn't try to solve a problem we don't have ?
Yes exactly.
Have we yet encountered an HT device with that sort of bogus
capability
list ?
Nope. So whatever fancy time-to-live scheme we come
up with, we cannot even test it, and it performance
no useful function. Nuke it :-)
Unaligned DMA is slow ppc64 systems - that's why this architecture
overrides NET_IP_ALIGN. IPoIB should take this into account and align
DMA on this platform.
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
Roland, what do you think?
This comes from reading linux/skbuff.h and
zhu shi song wrote:
how can I git latest tree?
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
Or.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To
Hi Diego,
OFED-1.1.1 includes fixed libehca package.
So, if you are not going to use eHCA driver then you can stay with OFED-1.1.
Regards,
Vladimir
Diego Guella wrote:
Hello Moni,
Thanks for your answer.
I had installed:
glibc-devel (2.5-17)
glibc-devel-32bit (2.5-17)
when i tried to
See embedded comment below.
From: Yevgeny Kliteynik [mailto:[EMAIL PROTECTED]
Sent: Sun 11/12/2006 8:42 AM
To: Hal Rosenstock; OPENIB
Subject: [PATCH v2] osm: comparing InformInfo records
Hi Hal
Here's the fixed InformInfo patch
Yevgeny
Signed-off-by:
On 11/12/06 11:30 PM, Krishna Kumar2 [EMAIL PROTECTED] wrote:
Hi Tom Sean,
There may be a race here, but... Why wouldn't the second call into
cm_work_handler simply find the list empty on entry into the call?
Basically, you've got a free work queue element sitting on the iwcm_wq.
On Fri, 10 Nov 2006, Ralph Campbell wrote:
I must have woken up on the wrong side of the bed today :-)
Perhaps I am remembering it being changed from in to in/out since
the code obviously is in/out now.
How about:
The 'iova' argument is an in/out parameter which can be used by the
Segher Boessenkool [EMAIL PROTECTED] writes:
What if we didn't try to solve a problem we don't have ?
Yes exactly.
Have we yet encountered an HT device with that sort of bogus capability
list ?
Nope. So whatever fancy time-to-live scheme we come
up with, we cannot even test it, and it
Bub Thomas wrote:
Setting the hop_limit from 64 down to 0 or 1 solved the problem. :-)
Don't ask me where I got that hop_limit from, it must have been an
example I found somewhere.
Can you explain why that hop_limit/is_global makes a difference in
communication between gen1 and gen2? Does the
Eric W. Biederman wrote:
Segher Boessenkool [EMAIL PROTECTED] writes:
What if we didn't try to solve a problem we don't have ?
Yes exactly.
Have we yet encountered an HT device with that sort of bogus capability
list ?
Nope. So whatever fancy time-to-live scheme
Christoph Raisch writes:
The patch is needed. We've seen it on the real system. We did fix it on
the
real system.
I disagree that the ioremap change is needed.
...and it conforms to theory... although theory is a bit confusing
here.
let me try to summarize:
ioremap checks for
The patch is needed. We've seen it on the real system. We did fix it on the
real system.
I disagree that the ioremap change is needed.
Hmm... Paul, what you say makes sense and is what I would have
thought, but Christoph says that the unpatched code really fails on a
real system. So
So Roland, feel free to ignore that line where we do the calculation.
OK, ignore the email I just sent. I'll drop the patch.
thanks
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To
I don't think this is what's needed. The GRH leaves a gap of 40, so
getting rid of the skb_reserve() just means that DMA will start at an
offset of 40 rather than 44.
I think you need to reserve enough to get to a full cacheline
boundary, but I can't remember if that's 64 or 128 bytes.
- R.
Sorry I was not intend to send previous email. Anyway I accidently sent it
out. What I thought was there would be a problem, if the missed_event
always return to 1. Then this napi poll would keep forever.
Well, it's limited by the quota that the net stack gives it, so
there's no possibility
Sundeep,I am sorry. I did not make myself very clear in my questions. I have got the iWARP running on my set-up for the Ammasso and Chelsio cards.To do this, I downloaded the iWARP code from the gen2 branch.Now I was trying to run the OSC MPI tools MVAPICH2 there to run the iWARP
Brice Goglin [EMAIL PROTECTED] writes:
How do you want to detect the following loop in pci_find_capability()
without changing the API?
any cap - any cap - one HT cap - any cap - back to first HT cap
When looking for a HT cap, pci_find_capability() will always succeed, it
will never loop
This is a bug since there are architectures eg PPC64 where the native
address size is u64 but dma_addr_t is u32. You are somehow in a
problem here, since returning an unchopped cpu_addr to the consumer
might cause a memory corruption as they are expecting 32 bit value.
Yes (although ppc64
...although one has to think through the implications for
pci_unmap_addr_set() I guess...
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit
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:
git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git
for-linus
This includes various small fixes for 2.6.19-rc6:
There may be an OpenSM bug with setting hop limit in the path record response.
I'm looking at it now.
-- Hal
From: [EMAIL PROTECTED] on behalf of Sean Hefty
Sent: Mon 11/13/2006 11:26 AM
To: Bub Thomas
Cc: Erez Cohen; openib-general@openib.org
Subject: Re:
Hi David,
My question is why should I have this reference to /usr/local/ofed
there if I do not need to download the OFED distribution code to run
the iWARP.
The variable OPEN_IB_HOME in make.mvapich2.iwarp sets the path to the Gen2
installation that you intend to use for iwarp. The default
I have not been able to reproduce this crash on my systems, and even
instrumenting the code isn't helping me to locate the issue. Can you
apply the following patch on top of the previous patches, and let me
know if you get any additional output?
- Sean
---
diff --git
Hal Rosenstock wrote:
Can you see if this fixes it ? Thanks.
-- Hal
Index: opensm/osm_helper.c
===
--- opensm/osm_helper.c (revision 10089)
+++ opensm/osm_helper.c (working copy)
@@ -1264,7 +1264,7 @@
IN const
I modifiedthe OPEN_IB_HOME to the iWARP directroy. Now it is looking OPEN_IB_HOME/lib64 and OPEN_IB_HOME/lib directories.Sundeep Narravula [EMAIL PROTECTED] wrote: Hi David, My question is why should I have this reference to /usr/local/ofed there if I do not need to download the OFED
The iWARP code does not have these directories. Will it be better if the iWARP makefile is not dependent on the OFED code?david elsen [EMAIL PROTECTED] wrote:I modifiedthe OPEN_IB_HOME to the iWARP directroy. Now it is looking OPEN_IB_HOME/lib64 and OPEN_IB_HOME/lib directories.Sundeep
Sundeep,I do not see any subdirectory for lib64 or lib in either the iWARP branch or in the OFED branch. Can you please tell me the reference for the OPEN_IB_LIB in the iWARP MVAPICH2 makefile?Regards, Daviddavid elsen [EMAIL PROTECTED] wrote:The iWARP code does not have these
Sundeep,I do not see any subdirectory for lib64 or lib in either the iWARP branch or in the OFED branch. Can you please tell me the reference for the OPEN_IB_LIB in the iWARP MVAPICH2 makefile?Regards, Daviddavid elsen [EMAIL PROTECTED] wrote:The iWARP code does not have these
On 11/13/06, Roland Dreier [EMAIL PROTECTED] wrote:
This is a bug since there are architectures eg PPC64 where the native
address size is u64 but dma_addr_t is u32. You are somehow in a
problem here, since returning an unchopped cpu_addr to the consumer
might cause a memory corruption
OK but I won't do this until I get back from SC. Is that soon enough ?
There's 1 other patch that should be there as well.
-- Hal
From: Tziporet Koren [mailto:[EMAIL PROTECTED]
Sent: Mon 11/13/2006 2:32 PM
To: Hal Rosenstock
Cc: [EMAIL PROTECTED];
Hal Rosenstock wrote:
OK but I won't do this until I get back from SC. Is that soon enough ?
sure
There's 1 other patch that should be there as well.
please add it too
Tziporet
___
openib-general mailing list
openib-general@openib.org
Hi Tom,
No, to understand why go look at the implementation of queue_work. BTW,
this
I was describing the implementation of queue_work() in my
previous mail. So sorry to be dense, but I do not understand
why this patch introduces a race. Can you explain the race
that you had found ? What I
http://openib.org/bugzilla/show_bug.cgi?id=263
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Ralph Campbell wrote:
IB/core - Add DMA mapping functions to allow device drivers to interpose
The QLogic InfiniPath HCAs use programmed I/O instead of HW DMA.
This patch allows a verbs device driver to interpose on DMA mapping
function calls in order to avoid relying on bus_to_virt() and
37 matches
Mail list logo
