Re: [PATCH v1 00/24] New fast registration API

[Bart Van Assche <bart.vanassche@sandisk.com>]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

On 10/01/2015 10:53 AM, Bart Van Assche wrote:
> On 10/01/2015 12:16 AM, Sagi Grimberg wrote:
>> I wander what is the difference between our test environments? I can't
>> look into this if I'm not able to reproduce.
>
> Hello Sagi,
>
> At the target side I see "Sep 30 12:56:06 ibdev1 kernel: [178664.300296]
> ib_srpt: RDMA t 5 for idx 0 failed with status 10." (status 10
> corresponds to IB_WC_REM_ACCESS_ERR). I will try to determine the root
> cause.

(replying to my own e-mail)

Hello Sagi,

To determine which side is causing this issue I captured the traffic 
between initiator and target with the MLNX_OFED ibdump tool (the dump 
has been attached to this e-mail). As one can see in that capture the 
target driver used exactly the same virtual address and length that were 
specified in the SRP_CMD request. To me this means that v1 of this patch 
series introduces a regression at the initiator side - either in the SRP 
initiator driver or in the mlx4 driver.

The only difference between our test setups that could be relevant is 
that in my tests several kernel debugging options were enabled at the 
initiator side (including SLUB_DEBUG_ON=y). As one can see in the 
attached capture the buffer allocated at the initiator side for the SCSI 
INQUIRY request was not aligned on a page boundary.

Bart.

[-- Attachment #2: sniffer.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 56340 bytes --]