Jon Mason wrote:
There are new dependencies on the ib_core module from the NFS-RDMA
modules. Since the NFS-RDMA modules are not unloaded in the current
version, the ib_core module cannot be removed and the openibd stop will
fail.
By stopping all of the NFS services and unloading any dependent m
There are new dependencies on the ib_core module from the NFS-RDMA
modules. Since the NFS-RDMA modules are not unloaded in the current
version, the ib_core module cannot be removed and the openibd stop will
fail.
By stopping all of the NFS services and unloading any dependent modules,
the ib_core
To the usual place. Should be included in the nightly 1.4.1 build.
--
Jeff Squyres
Cisco Systems
___
ewg mailing list
ewg@lists.openfabrics.org
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
Yossi Etigin wrote:
Vladimir Sokolovsky wrote:
Hi Yossi,
Please send this patch in the "OFED" format:
kernel_patches/fixes/ipoib... with backports (if required).
Thanks,
Vladimir
Applied,
Regards,
Vladimir
___
ewg mailing list
ewg@lists.openfabri
Vladimir Sokolovsky wrote:
> Hi Yossi,
> Please send this patch in the "OFED" format:
> kernel_patches/fixes/ipoib... with backports (if required).
>
> Thanks,
> Vladimir
Here is:
diff --git a/kernel_patches/fixes/ipoib_0560_clear_admin_up_flag.patch
b/kernel_patches/fixes/ipoib_0560_clear_admi
Yossi Etigin wrote:
If ipoib_open() fails, it should clear IPOIB_FLAG_ADMIN_UP bit and not
leave if on.
This is already fixed in 2.6.30.
Reported-by: Jack Morgenstein
Signed-off-by: Yossi Etigin
---
Index: b/drivers/infiniband/ulp/ipoib/ipoib_main.c
If ipoib_open() fails, it should clear IPOIB_FLAG_ADMIN_UP bit and not
leave if on.
This is already fixed in 2.6.30.
Reported-by: Jack Morgenstein
Signed-off-by: Yossi Etigin
---
Index: b/drivers/infiniband/ulp/ipoib/ipoib_main.c
==
Jack Morgenstein wrote:
> On Friday 17 April 2009 18:26, Yossi Etigin wrote:
>> - ipoib_dbg(priv, "bringing up interface\n");
>> -
>> -- if (!test_and_set_bit(IPOIB_FLAG_ADMIN_UP, &priv->flags))
>> -- napi_enable(&priv->napi);
>> -+ set_bit(IPOIB_FLAG_ADMIN_UP, &priv->
On Wednesday 22 April 2009 04:10:18 pm michael wrote:
> Hi,
>
> I don't take the point, if it is not import use the vmalloc. Why you try
> with a kmalloc
> alloc first? and why do not use kzalloc?
Because kmalloc() is faster than vmalloc() causing a huge performance win
when someone allocates a
In case of large queue pairs there is the possibillity of allocation failures
due to memory fragmentationo with kmalloc().To ensure the memory is allocated
even
if kmalloc() can not find chunks which are big enough, we try to allocate the
memory
with vmalloc().
Signed-off-by: Stefan Roscher
--
Steve Wise wrote:
What is the cut-off date to have all the backports done (not new
features, just backports of 2.6.30 functionality to the older kernels)?
Is it RC1?
Target should be RC1, but I am sure some of the OSes will be only done
in RC2
Tziporet
_
Tung, Chien Tin wrote:
Vlad,
Please pull nes OFED 1.4.1 RC4 update from:
git://git.openfabrics.org/~ctung/ofed-1.4.1.git ofed_kernel
It contains commit 4abc408a8605ac8e5f1829e3e79d6c56dbac1ce7
* Turn off dynamic interrupt moderation as default
Thanks,
Chien
--
Chien Tung | chien.tin.t..
Hi Roland,
thanks for the quick review. I was hoping you could apply these changes
for 2.6.30 because this will be the codebase for the next OFED release.
The patch is well tested in HPC environment and we haven't seen any
issues.
Regarding Antons patch you are right. If a user allocates an
unr
13 matches
Mail list logo
