On Thu, 2017-02-23 at 12:34 +0000, Yuri Arabadji wrote:
On 31 December 2015 James Harvey wrote:
> If I run "ibsrpdm -c" it shows:
> a
>
id_ext=0002c90300001678,ioc_guid=0002c90300001678,dgid=fe800000000000000002c90300001679,pkey=ffff,service_id=0002c90300001678
>
> But, srp_daemon with "-n" sends i_port_id
0x7916000003c90200:0x2c90300001e79
>
> The 0x7916000003c90200 part is what I couldn't figure out how to see,
> before a failed connection attempt. It's not in the ibsrpdm output.
Hi. I stumbled upon exactly the same issue. It's a bug in srp_daemon, and not
in your understanding of how things should be configured.
--- a/srp_daemon.c 2015-02-11 06:41:49.000000000 -0500
+++ b/srp_daemon.c 2017-02-23 07:10:56.509572959 -0500
@@ -541,7 +541,7 @@
len += snprintf(target_config_str+len,
MAX_TARGET_CONFIG_STR_STRING - len,
",initiator_ext=%016llx",
- (unsigned long long) ntohll(target->h_guid));
+ (unsigned long long) target->h_guid);
if (len >= MAX_TARGET_CONFIG_STR_STRING) {
pr_err("Target config string is too long, ignoring target\n");
It's indeed an "-n" option that causes havoc. In EL7 distro,
/usr/sbin/srp_daemon.sh should be edited to remove it, if you don't like
it. The right command to get the params the will be passed to ib_srp is:
"srp_daemon -n -o -c". It will give you an idea what actually is going to
be created.
On a side note, it would be totally wonderful to have a user-friendly
explanation from DEVs of all these i_port_id, t_port_id, guid, LIDs, port
GIDs, port GUIDs, UUIDs and all other shmooids that often pop up in my
dmesg output, along with explanation on how they are crafted.
Thanks for having reported this. A fix is available in the rdma-core package,
available at
https://github.com/linux-rdma/rdma-core. The rdma-core package
includes the srptools package.
Bart.