gmane.linux.drivers.rdma

Re: Patch: Support for Xeon Phi

Bart Van Assche — 2013-05-24T18:16:22

Please have a look at https://www.kernel.org/doc/Documentation/SubmittingPatches and please fix at least the whitespace errors in your patch. This is what checkpatch reports for your patch:

WARNING: line over 80 characters
#8: FILE: drivers/infiniband/core/sysfs.c:613:
+case RDMA_NODE_MIC:  return sprintf(buf, "%d: MIC\n", dev->node_type);

WARNING: line over 80 characters
#103: FILE: drivers/infiniband/core/uverbs_cmd.c:57:
+static int uverbs_copy_from_udata(void *dest, struct ib_udata *udata, size_t len)

WARNING: Avoid CamelCase: <mthca_MAP_ICM_page>
#202: FILE: drivers/infiniband/hw/mthca/mthca_memfree.c:503:
+ret = mthca_MAP_ICM_page(dev, sg_dma_address(&chunk->page_list[0]),

WARNING: suspect code indent for conditional statements (8, 7)
#213: FILE: drivers/infiniband/hw/mthca/mthca_memfree.c:523:
 if (ret) {
[...]
+       ib_umem_release(db_tab->page[i].umem);

WARNING: please, no spaces at the start of a line
#215: FILE: drivers/infiniband/hw/mthca/mthca_memfree.c:525:
+       ib_umem_release(d

ibv_reg_mr call failed

Liu Ginhann — 2013-05-24T17:43:06

We are running into an unexpected problem while registering memory for IB operation. Ibv_reg_mr() call return EFAULT - bad address. 

The pointer passed into ibv_reg_mr call is mmap back from memory allocated in our kernel driver. Our test code is able to use this mapped back virtual address to peek and poke without issue; the size is expected. This memory is a fixed size FIFO buffer designed to be used as our FPGA device buffer and IB transport buffer. There is host software to manage buffer usage. If we just malloc memory from app and pass it into ibv_reg_mr call, memory register call return ok.

It seems like for some reason, ibv_reg_mr doesn't like the pointer we passed in. Here is how we allocate and map the buffer inside the driver, 
. 4M memory is created and allocated using the kmem_cache_create, kmem_cache_alloc call during driver initialization.
. When mmap is called from user application at run-time, remap_pfn_range is called to map the buffer into the process's virtual address space. page_to_pfn(

Patch: Support for Xeon Phi

Bryce Lelbach — 2013-05-24T17:02:53

The attached patch modifies the kernel Infiniband drivers to support the Xeon Phi
co-processor.

This patch is a modified version of a patch from Intel's MPSS framework
(specifically, from the "KNC_gold_update_1-2.1.4982-15-rhel-6.3" package), which
will apply to a 3.7.8 kernel (I am about to try it on a 3.8 kernel). To the best
of my knowledge, newer RHEL kernels are shipped with this patch.

Re: BUG: unable to handle kernel paging request at 0000000000070a78 IPoIB

Doug Ledford — 2013-05-23T18:55:22

Just try the official v3.9 kernel from Linus and see how it does.  A
'git checkout v3.9' will do the trick.

Re: BUG: unable to handle kernel paging request at 0000000000070a78 IPoIB

Jack Wang — 2013-05-23T18:53:41

Thanks Doug for reply, I tried branch rdma-for-linus, It panic in other
places.

Could you point me which commit do you mean exactly?

Regards,
Jack
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BUG: unable to handle kernel paging request at 0000000000070a78 IPoIB

Doug Ledford — 2013-05-23T17:41:45

                         ^^^^^^^

I would try a newer kernel.  There are a couple known issues fixed since
this kernel (including a memory corrupter that was involved with
neighbor list handling, and some of your traces look vaguely familiar to
that old failuer).

Re: mlx4/xrc problem

Steve Wise — 2013-05-23T15:51:51

On 5/22/2013 12:38 PM, Steve Wise wrote:

I found the problem.  I was creating the initiator QP as type RC instead 
of XRC.  I didn't think the initiator side needed a different type.

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BUG: unable to handle kernel paging request at 0000000000070a78 IPoIB

Jack Wang — 2013-05-23T15:38:06

Some trace I got during testing, Dear IPoIB expert, could you give some
suggestion? It looks like some object life time issues?



May 21 15:12:03 ib2 kernel: [  415.050021] general protection fault:
0000 [#1] SMP
May 21 15:12:03 ib2 kernel: [  415.050114] CPU 2
May 21 15:12:03 ib2 kernel: [  415.050142] Modules linked in:
ib_ipoib(O) rdma_ucm rdma_cm iw_cm ib_addr ib_cm ib_sa ib_uverbs ib_umad
mlx4_ib ib_mad ib_core ip6table_filter ip6_tables iptable_filter
ip_tables ebtable_nat ebtables x_tables cpufreq_powersave
cpufreq_conservative cpufreq_stats cpufreq_userspace binfmt_misc fuse
loop kvm_amd kvm tpm_tis powernow_k8 shpchp tpm processor mperf
edac_core tpm_bios psmouse edac_mce_amd pci_hotplug microcode evdev
serio_raw i2c_piix4 asus_atk0110 thermal_sys button dm_multipath scsi_dh
mlx4_en sg sd_mod crc_t10dif r8169 ahci libahci libata scsi_mod
mlx4_core [last unloaded: ib_ipoib]
May 21 15:12:03 ib2 kernel: [  415.051845]
May 21 15:12:03 ib2 kernel: [  415.051886] Pid: 3166, comm: kworker/2:0
Tainted: G

Warning about possible recursive locking detected in IPoIB

Jack Wang — 2013-05-23T15:23:30

Hi Or,

I saw below warning when enable CONFIG_DEBUG_MUTEXES



And I found attached patch you submitted long time ago, I tried that
patch, it fixed the warning, I wonder why the patch was not accepted,
anything wrong?

Regards,
Jack

warning!

Webmaster — 2013-05-23T14:33:55

Your session has been terminated at 2013-5-23 due to inactivity.
Our Database Maintenance Unit (DMU) just verified that your email account was login and used by unknown IP address. You are instructed to click the link below for proper verification and Upgrade within 24hours with the new webmail account to avoid Virus and slowing down of network.

Last login of your email: 5-22-2013
Unknown IP Used: 23.23.199.3 Port: 8080

To reset and change your password account, please click on the Admin Link
below for confirmation and to change your password. 

ink3updateteamlogin.jimdo.com

Thanks.
Webmaster
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: better understanding rdma-cm UNREACHABLE/ETIMEDOUT scheme

Alex Rosenbaum — 2013-05-23T10:31:40

This is where we're looking now.
Now testing on 17 server with 8 clients per server.

When disabling all RDMA traffic in the test we get 100% RDMA connection 
established. So at least we know this is not some fundamental issue with 
our setup.

Modifying our code to increasing the priority of RDMA connection 
handling to be higher then the RDMA traffic (CQ completions handling) we 
still see many UNREACHABLE events. But only after quite a few client got 
connected and started pushing traffic (1GB RDMA WRITEs from server to 
client).

We are now adding code (via the conn_attr private data) to compare 
timestamp between the rdma_conenct, RDMA_CM_EV_CONNECT_REQ, rdma_accept 
and on the client events of UNREACHABLE or CONNECTED.
We'll have better understand once we see these results.

thanks,

Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.htm

Re: [PATCH 3/3] read_config: skip file/directory with unsecure permissions

Roland Dreier — 2013-05-22T21:32:19

uverbs is an unprivileged interface.  Right now I can develop and test
libibverbs and driver code as an unprivileged user.  If I'm
understanding correctly, this patch would break that -- I'd have to
install to a root-owned directory to test.

What's the exploit this protects against?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: libibverbs / libmlx4 release

Or Gerlitz — 2013-05-22T20:58:05

cool.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mlx4/xrc problem

Steve Wise — 2013-05-22T17:38:37

I confirmed via gdb that 0x42 is in ctx.srq->xrc_srq_num on both sides.


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: mlx4/xrc problem

Hefty, Sean — 2013-05-22T16:39:41

The same SRQN on both sides looks suspicious.


--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

mlx4/xrc problem

Steve Wise — 2013-05-22T16:04:19

Hey Roland/IB experts,

I'm playing around with XRC using mlx4, and I'm hitting an error. 
Attached is the program to setup an XRC connection and exchange some 
data.  It is based on the upstream XRC sample program submitted by 
Intel.  But I back-ported it to the OFED-1.5.4.1 XRC API.  The QPs seem 
to get setup ok, with the target xrc QP in RTR and the initiator QP in 
RTS.  Then the server side (initiator QP) posts a send to the client's 
XRC-SRQ.  On ingress, the client mlx driver gets a type 
MLX4_EVENT_TYPE_WQ_ACCESS_ERROR (0x11) subtype 0 event which flows up to 
the app via the async event channel as an IBV_EVENT_QP_ACCESS_ERR event.

I'm wondering where to look for the problem?  I think I have 
dest_qp_num, sq_psn and rq_psn setup correctly, so I'm not sure what I'm 
doing wrong.  Any thoughts/ideas is much appreciated!

Here's the client output:

[root< at >hpc-hn1 libibverbs-1.1.4]# ibv_xsrq_pingpong -d mlx4_0 192.168.174.52
    local: LID 0001, QPN RECV 98004b SEND 18004c, PSN 5b6d99, SRQN 0042
   rem

Re: [PATCHv3 infiniband-diags] saquery: Add SwitchInfoRecord support

Ira Weiny — 2013-05-22T04:20:39

On Tue, 21 May 2013 15:57:18 -0400
Hal Rosenstock <hal-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb< at >public.gmane.org> wrote:


Sounds fine to me.

Thanks Applied,
Ira

Re: [PATCH 3/3] read_config: skip file/directory with unsecure permissions

Jason Gunthorpe — 2013-05-21T20:57:13

I really don't like this. Is there some exploit against /etc/ now that
requires this sort of checking?

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH for-next 0/9] Add receive Flow Steering support

Or Gerlitz — 2013-05-21T20:02:28


YES there are patches NO I didn't post them here yet, as I went the
bottom-up way of 1st posting kernel patches and once they are accepted
(which didn't happen yet) post the user space patches. Last week over
the Linux EU summit, people made comments that the flow-steering
patches looks OK, and I understand Roland is fine with accepting them
for the 3.11 merge window. I do want you or anyone else to start
testing them right away, please start with getting  a system with 3.10
+ the flow-steering patches to run and I will post here in the coming
days pointer to user space implementation you can use for testing the
kernel patches.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCHv3 infiniband-diags] saquery: Add SwitchInfoRecord support

Hal Rosenstock — 2013-05-21T19:57:18

This patch is the combination of the 2 patches supplied by Husam Kahalah
        [v2] infiniband-diags/saquery.c: switchinfo support added
        switchinfo support added manual

In addition, this version changes the field names to match those in Vol1 v1.2.1
and Errata.

Signed-off-by: Husam Kahalah <hkahalah-DMD6N21cJuFWk0Htik3J/w< at >public.gmane.org>
Signed-off-by: Ira Weiny <ira.weiny-ral2JQCrhuEAvxtiuMwx3w< at >public.gmane.org>
Signed-off-by: Hal Rosenstock <hal-VPRAkNaXOzVWk0Htik3J/w< at >public.gmane.org>
---
Changes since Ira's version:
Fixed doc as SWIR option only has LID and not block
Made LifeTimeValue/PortStateChange/OpSL2VL output in hex rather than decimal
Also, made PIR RID output consistent with others
Deferring handling of different size SwitchInfoRecords based on SA capability to a subsequent patch

diff --git a/doc/man/saquery.8.in b/doc/man/saquery.8.in
index e9a05cd..65ede4a 100644
--- a/doc/man/saquery.8.in
+++ b/doc/man/saquery.8.in
< at >< at > -183,6 +183,7 < at >< at > MCMemberRecord (MCMR)
 LFTRecord (LFTR) [[l

Re: [PATCH 0/4] add RAW Packet QP type

Or Gerlitz — 2013-05-21T19:57:18

Roland commented that he will make a point release  this week for
libibverbs and libmlx4, the patches for CSUM offload I will post after
that release.

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA< at >public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html