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() an
http://openib.org/bugzilla/show_bug.cgi?id=263
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 und
I am trying to build the OSC MPI and see the error message with the congratulations message.Please see the attached file for details.Can someone help to find out the problem what I am having with this?Thanks in advance,Daviddavid elsen <[EMAIL PROTECTED]> wrote: I modified the OPEN_IB_HOME to the
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.
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]; openib-gener
On 19:49 Mon 13 Nov , Hal Rosenstock wrote:
> There may be an OpenSM bug with setting hop limit in the path record
> response. I'm looking at it now.
Looks like it is - OpenSM returns the same hop_limit value as was in the
request.
Bub, could you try the patch below?
Thanks,
Sasha
diff --
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 co
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, David david elsen <[EMAIL PROTECTED]> wrote:The iWARP code does not have thes
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, David david elsen <[EMAIL PROTECTED]> wrote:The iWARP code does not have thes
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 modified the OPEN_IB_HOME to the iWARP directroy. Now it is looking OPEN_IB_HOME/lib64 and OPEN_IB_HOME/lib directories.Sundee
I modified the 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 distri
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 cons
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 a/drivers/infiniband/core/mul
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 defaul
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: [ope
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:
H
...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 http://openib.org/mailman/
> 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 pp
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
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 iWAR
> 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 possibili
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.
__
> 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 unsu
> > 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.
> 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:
> > iorem
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 whateve
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
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 tes
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
>
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 sittin
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: Yevge
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
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 unsubsc
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 asm-powe
> 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 :-)
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" <
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 coun
> 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/
39 matches
Mail list logo