-2.6.14
Passed on ia64 with linux-2.6.16
Passed on ia64 with linux-2.6.15
Passed on ia64 with linux-2.6.17
Passed on ia64 with linux-2.6.12
Passed on ia64 with linux-2.6.14
Failed:
Build failed on ia64 with linux-2.6.16.21-0.8-default
Log:
/home/vlad/tmp/ofa_1_2_kernel-20070210-0200_linux-2.6.16.21-0.8
On Fri, 2007-02-09 at 15:19, Michael Arndt wrote:
Hi,
It is strange, I did similar thing (you can see in
management/diags/src/mcm_rereg_test.c) and it worked fine for me.
What location is that?
Which libibumad version you are using? Also I understand you did some
changes in the
+
It seems same goes for
+ mc = kzalloc(sizeof(*mc), GFP_KERNEL);
+ if (!mc)
+ return NULL;
We would need to set events_reported.
IMO, probably worth it to init just this one field rather than use up
initialized memory - and I think it's clearer.
--
IMO, probably worth it to init just this one field rather than use up
initialized memory - and I think it's clearer.
What do you mean by using up initialized memory? kzalloc() just does
a memset(0), and it's not like there's a limit on the number of times
we're allowed to call memset().
-
Here is a patch that Tom and I think fixes the race condition Roland
discovered, plus cleans up the issues Krishna attempted to fix in his
first patch. I'm testing it now with a series of rping tests looping
with random sizes and counts and it seems to work, but the patch needs
more testing and
I updated the latest MVAPICH2 SRPM:
https://www.openfabrics.org/~rowland/ofed_1_2/
I am including a patch to the latest ofed_1_2_scripts git files. Since
these files are the same as those used in the OFED-1.2-20070208-1508.tgz
package, this patch can also be applied there. This patch is
ugh.
There is at least one bug in this patch. I cannot call iw_cm_reject()
inside destroy_cm_id() because both functions grab the iw_cm lock...
On Sat, 2007-02-10 at 13:23 -0600, Steve Wise wrote:
Here is a patch that Tom and I think fixes the race condition Roland
discovered, plus cleans
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: [PATCH 0/5] iw_cxgb3 - misc cleanup and fixes
Michael What about the mthca memory registration patches? I
Michael thought they are on their way. Should I repost?
Sorry, I forgot about that. Yes, please resend the latest
For Tavor, we currently reserve separate MPT and MTT space for
FMRs to avoid abusing the vmalloc space on 32 bit kernels. No
such problem exists on 64 bit kernels so let's not do it there.
This way we have a shared pool for MR and FMR resources, used on
demand. This will also make it possible to
Speed up memory registration by filling in MTTs directly. This
reduces the number of FW commands needed to register an MR by at
least a factor of 2. This applies to all memfree cards, and to
tavor mode on 64 bit systems with the patch I posted earlier.
Signed-off-by: Michael S. Tsirkin [EMAIL
Fix non-cache-coherent CPUs with memfree HCAs.
We allocate the MTT table with alloc_pages() and then do
pci_map_sg(), so we must call pci_dma_sync_sg after the CPU
writes to the MTT table (this works since device never writes the
MTTs on memfree).
For MPTs, both the device and CPU might write
This fixes several issues related to reserved MTTs and memory alignment.
1. MTTs are allocated in non-cache-coherent memory, so we must give
reserved MTTs their own cache line, to prevent both device and
CPU from writing into the same cache line at the same time.
2. reserved_mtts field has
On Sat, 2007-02-10 at 14:36 -0600, Steve Wise wrote:
ugh.
There is at least one bug in this patch. I cannot call iw_cm_reject()
inside destroy_cm_id() because both functions grab the iw_cm lock...
This patch puts the iw_cm_reject() calls back in
cm_conn_req_handler()...
---
iw_cm_id
Thanks, applied this and the previous patch, and pushed out my
for-2.6.21 branch. I also rebased so the cxgb3 net driver builds now.
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To
Roland, the following code in ipoib:
while ((int) priv-tx_tail - (int) priv-tx_head 0) {
seems to rely on integer overflow which seems to be
undefined behaviour.
Should we care?
--
MST
___
openib-general mailing list
while ((int) priv-tx_tail - (int) priv-tx_head 0) {
seems to rely on integer overflow which seems to be
undefined behaviour.
tx_tail and tx_head are unsigned, and overflow is defined for unsigned
integers.
- R.
___
openib-general
Quoting Roland Dreier [EMAIL PROTECTED]:
Subject: Re: integer overflow
while ((int) priv-tx_tail - (int) priv-tx_head 0) {
seems to rely on integer overflow which seems to be
undefined behaviour.
tx_tail and tx_head are unsigned, and overflow is defined for unsigned
Yes but we cast them to signed int here - no?
That's true, I guess it is technically undefined. But time_after() is
relying on the same thing working, so I would say we don't care.
- R.
___
openib-general mailing list
openib-general@openib.org
The following untested patch moves all TX processing in IPoIB CM to common CQ.
This should help reduce the number of interrupts for bi-directional traffic
(such as TCP). Is this a good idea? What do others think?
Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
---
diff --git
On Thu, 2007-02-08 at 18:32 +0100, Stefan Roscher wrote:
Correct directory structure according to new driver loading scheme from
libibverbs
Signed-off-by: Stefan Roscher [EMAIL PROTECTED]
---
--- ofa_user.spec_old 2007-02-08 09:03:33.0 -0800
+++ ofa_user.spec_new 2007-02-08
20 matches
Mail list logo
