Hi all,
Today's linux-next merge of the infiniband tree got a conflict in
drivers/infiniband/core/uverbs_main.c between commit
ce916e2b935f8b3402da1457ff23b9f9f786c09b ("switch infiniband uverbs to
anon_inodes") from the vfs tree and commit
4169c4a9735d6434c9e39fa81ae5517e3afd4cd8 ("IB/uverbs: Use
On Thu, 2010-02-25 at 12:15 -0800, Roland Dreier wrote:
> > When using connected mode, ipoib_cm_create_tx() kmallocs a
> > struct ipoib_cm_tx which contains pointers to ipoib_neigh and
> > ipoib_path. If the paths are flushed or the struct neighbour is
> > destroyed, the pointers held by struct
> | atomic_response = *va
> | if (((cmp XOR *va) AND cmp_mask) is ZERO) then
> | *va = (*va AND NOT(swap_mask)) OR (swap AND swap_mask)
> |
> | return atomic_response
This is a great, terse description of the masked compare and swap
operation. Do you think it would be more readable with
On Thu, 2010-02-25 at 12:03 -0800, Arthur Kepner wrote:
> On Thu, Feb 25, 2010 at 11:29:02AM -0800, Ralph Campbell wrote:
> >
>
> I haven't looked carefully at the whole patch, but this bit
> looks wrong:
>
> > @@ -848,61 +823,112 @@ static void ipoib_neigh_cleanup(struct neighbour *n)
> >
I think I'd be OK adding this for 2.6.34, if there were some case made
that this would be useful for someone working on code that used this.
So what case can be made for adding this to 2.6.34 without an in-tree user?
> - Add a new IB_WR_ATOMIC_MASKED_CMP_AND_SWP and
> IB_WR_ATOMIC_MASKED_FETCH_
> > The kernel calls this device ID "MT26438 ConnectX EN 40GigE PCIe gen2
> > 5GT/s". Maybe we should just delete these comments, since we can't seem
> > to get them right?
>
> I guess it would be best if we take the description from
> http://pciids.sourceforge.net/v2.2/pci.ids
I wonder wh
On Thu, Feb 25, 2010 at 2:37 PM, Dries Kimpe wrote:
>
> * Hal Rosenstock [2010-02-25 09:45:04]:
>
>> The link won't renegotiate automatically. The link needs to be reset
>> after updating the speed/width enabled values. Was that done ?
>
> I assumed OpenSM was resetting the link. Are you saying I
On Wed, Feb 24, 2010 at 02:07:20PM -0800, Roland Dreier wrote:
> > + HCA(MELLANOX, 0x6746), /* MT26438 ConnectX VPI PCIe 2.0 5GT/s - IB QDR
> / 10GigE Virt+ */
>
> The kernel calls this device ID "MT26438 ConnectX EN 40GigE PCIe gen2
> 5GT/s". Maybe we should just delete these comments, since
> I have a question about the SRP initiator available in the Linux
> kernel. While consulting the SRP spec (r16a) I noticed that all
> multi-byte integer fields of SRP information units must be sent using
> the big endian byte order. This holds e.g. for the 64-bit tag fields
> present in sever
On Thu, Feb 25, 2010 at 11:29:02AM -0800, Ralph Campbell wrote:
>
I haven't looked carefully at the whole patch, but this bit
looks wrong:
> @@ -848,61 +823,112 @@ static void ipoib_neigh_cleanup(struct neighbour *n)
> struct ipoib_neigh *neigh;
> struct ipoib_dev_priv *priv =
> When using connected mode, ipoib_cm_create_tx() kmallocs a
> struct ipoib_cm_tx which contains pointers to ipoib_neigh and
> ipoib_path. If the paths are flushed or the struct neighbour is
> destroyed, the pointers held by struct ipoib_cm_tx can reference
> freed memory. The fix is to add re
* Hal Rosenstock [2010-02-25 09:45:04]:
> The link won't renegotiate automatically. The link needs to be reset
> after updating the speed/width enabled values. Was that done ?
I assumed OpenSM was resetting the link. Are you saying I need to run
ibportstate reset in addition to running a modifi
>From 4a2f3a9685fd82b57e75a31d04d6967d7d9b33c2 Mon Sep 17 00:00:00 2001
From: Ralph Campbell
Date: Thu, 25 Feb 2010 11:22:02 -0800
Subject: [PATCH] IB/ipoib: fix dangling pointer references to ipoib_neigh and
ipoib_path
When using connected mode, ipoib_cm_create_tx() kmallocs a
struct ipoib_cm_t
> > Iris is an XFP card. NetEffect didn't make that many and maybe a few
> > were given out as evals. The biggest reason for removing the support
> > is I don't have a card to test code changes. There are other cards that
> > I am supporting even though we no longer make them as Intel. I will
>
> Iris is an XFP card. NetEffect didn't make that many and maybe a few
> were given out as evals. The biggest reason for removing the support
> is I don't have a card to test code changes. There are other cards that
> I am supporting even though we no longer make them as Intel. I will
> ke
System2 is still up (although with Iometer I have run into system 2 hanging).
Once the test fails, I can do pretty much nothing. Ibv_devinfo says Failed to
get IB device list. The ping was my test to figure out if things were still ok
between the two systems. And, its failure told me that the l
>--- Comment #1 from usha.sriniva...@qlogic.com 2010-02-25 09:05 ---
>This morning, I ran ib_send_bw between my two connectx systems and ran into a
>send problem there as well.
>
>At system1 I ran these tests:
>ib_send_bw -c UD
>ib_send_bw -c UD -all
>ib_send_bw -c UD -all -t 1500 -n 1500
>By "deprecate NES_PHY_TYPE_IRIS" it seems you mean remove all support
>for this PHY type?
yes, see below.
>Were cards of this type sold? Because I think it's way too early to
>drop support for any PHY variant (it's not like these are some 10BASE2
>cards from decades ago -- these are 10 gigabit
On Thu, Feb 25, 2010 at 1:39 AM, Dries Kimpe wrote:
>
> Hi,
>
> for various reasons I'm trying to force a specific setting for
> the link speed and link width of an IB link.
>
> I know opensm has an option to force link speed to a certain value. I
> modified OpenSM (3.3.5) and added a similar op
On 2010-02-25 02:06 Or Gerlitz said the following:
Can you elaborate what does it take to reproduce that?
I am not sure. I am writing custom scripts for a Linux cluster of iSCSI
targets and initiators. I start and kill (including SIGKILL) iscsid,
start and kill (including SIGKILL), add and re
OFED 1.5.1-rc2 is available
Notes:
The tarball is available on:
http://www.openfabrics.org/downloads/OFED/ofed-1.5.1/OFED-1.5.1-rc2.tgz
To get BUILD_ID run ofed_info
Please report any issues in bugzilla https://bugs.openfabrics.org/ for OFED
1.5.1
Vladimir & Tziporet
==
Thu, Feb 25, 2010 at 09:00:07AM CET, ogerl...@voltaire.com wrote:
>Jiri Pirko wrote:
>> --- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
>> +++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
>> @@ -767,11 +767,8 @@ void ipoib_mcast_dev_flush(struct net_device *dev)
>> -static int ipoib_mcast_
Roman Kononov wrote:
> The same with 2.6.32.9
> kernel: BUG: unable to handle kernel paging request at 621ae010
> kernel: IP: [] iscsi_conn_failure+0x1e/0xc0 [libiscsi]
Can you elaborate what does it take to reproduce that?
Or.
--
To unsubscribe from this list: send the line "unsubscribe
Jiri Pirko wrote:
> --- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
> +++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
> @@ -767,11 +767,8 @@ void ipoib_mcast_dev_flush(struct net_device *dev)
> -static int ipoib_mcast_addr_is_valid(const u8 *addr, unsigned int addrlen,
> -
24 matches
Mail list logo
