Re: [PATCH v8] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

[Bryant G. Ly]

On 6/29/16, 9:54 AM, "Bart Van Assche"  wrote:

On 06/29/2016 04:43 PM, Bryant G. Ly wrote:
>> It looks like the masking fixes the device mapper’s ability to find the 
>> disk….

> Is the multipath client available in your initrd? If so, running 
> multipath -ll -v with n >= 3 should reveal why multipathd ignored 
> certain disks.

I enabled it on the initiator:

[root@vscsi-bry ~]# multipath -ll
[root@vscsi-bry ~]# multipath -ll -v with n >= 3
-bash: n: No such file or directory
[root@vscsi-bry ~]# mpathconf
multipath is enabled
find_multipaths is enabled
user_friendly_names is enabled
dm_multipath module is loaded
multipathd is running
[root@vscsi-bry ~]#

But it seems to not do much.

--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html




--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

[Bart Van Assche]

On 06/29/2016 04:43 PM, Bryant G. Ly wrote:

It looks like the masking fixes the device mapper’s ability to find the disk….


Is the multipath client available in your initrd? If so, running 
multipath -ll -v with n >= 3 should reveal why multipathd ignored 
certain disks.


Bart.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

[Bryant G. Ly]

On 6/29/16, 12:49 AM, "Bart Van Assche"  wrote:

>> I was hoping someone in the community can help answer this:
>>
>> If I were to remove the masking off of the lun addressing method prior to 
>> target_submit_cmd/target_submit_tmr then I get a hang within scsi probe
>> on bootup. (srp->lun.scsi_lun[0] &= 0x3f; and srp_tsk->lun.scsi_lun[0] &= 
>> 0x3f;)
>>
>> [0.842648] ibmvscsi 300d: sent SRP login
>> [0.842667] ibmvscsi 300d: SRP_LOGIN succeeded
>> [0.842682] scsi 0:0:2:0: CD-ROMAIX  VOPTA
>>  PQ: 0 ANSI: 4
>> [  OK  ] Started Show Plymouth Boot Screen.
>> [  OK  ] Reached target Paths.
>> [  OK  ] Reached target Basic System.
>> [0.886179] sr 0:0:2:0: [sr0] scsi-1 drive
>> [0.886199] cdrom: Uniform CD-ROM driver Revision: 3.20
>> [0.888582] sd 0:0:1:0: [sda] 41943040 512-byte logical blocks: (21.4 
>> GB/20.0 GiB)
>> [0.888657] sd 0:0:1:0: [sda] Write Protect is off
>> [0.888712] sd 0:0:1:0: [sda] Cache data unavailable
>> [0.888722] sd 0:0:1:0: [sda] Assuming drive cache: write through
>> [0.901443]  sda: sda1 sda2 sda3
>> [0.901838] sd 0:0:1:0: [sda] Attached SCSI disk
>> [  124.522778] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
>> starting timeout scripts
>> [  125.151242] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
>> starting timeout scripts
>> [  125.662808] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
>> starting timeout scripts
>>
>> Does anyone know of the reasoning for having to mask off the addressing 
>> method prior
>> to submitting to target?

> How long have you waited before giving up waiting? The SCSI initiator 
> sends a REPORT LUN and other SCSI commands to LUN 0. If LUN 0 is missing 
> these commands will time out but that should not cause a hang. Anyway, 
> SysRq-w should help to determine the cause of the hang.

[0.852777] ibmvscsi 3002: SRP_LOGIN succeeded
[  OK  ] Reached target System Initialization.
 Starting dracut initqueue hook...
 Starting Show Plymouth Boot Screen...
[0.872421] ibmvscsi 300d: SRP_VERSION: 16.a
[0.872561] scsi 0:0:1:0: Direct-Access AIX  VDASD0001 
PQ: 0 ANSI: 3
[0.872635] scsi host1: IBM POWER Virtual SCSI Adapter 1.5.9
[0.872846] ibmvscsi 300d: partner initialization complete
[0.872897] ibmvscsi 300d: host srp version: 16.a, host partition  (0), 
OS 2, max io 8388608
[0.872917] ibmvscsi 300d: sent SRP login
[0.872937] ibmvscsi 300d: SRP_LOGIN succeeded
[0.872953] scsi 0:0:2:0: CD-ROMAIX  VOPTA 
PQ: 0 ANSI: 4
[  OK  ] Started Show Plymouth Boot Screen.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Basic System.
[0.915670] sr 0:0:2:0: [sr0] scsi-1 drive
[0.915690] cdrom: Uniform CD-ROM driver Revision: 3.20
[0.917957] sd 0:0:1:0: [sda] 41943040 512-byte logical blocks: (21.4 
GB/20.0 GiB)
[0.918035] sd 0:0:1:0: [sda] Write Protect is off
[0.918092] sd 0:0:1:0: [sda] Cache data unavailable
[0.918104] sd 0:0:1:0: [sda] Assuming drive cache: write through
[0.929717]  sda: sda1 sda2 sda3
[0.930107] sd 0:0:1:0: [sda] Attached SCSI disk
[  124.662745] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  125.311128] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  125.822847] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  126.332803] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  126.842856] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  127.352800] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  127.862721] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  128.372729] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  128.882699] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  129.392709] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  129.902698] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  130.412724] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  130.922700] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  131.432729] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  131.942724] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  132.452690] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  132.962679] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting 

Re: [PATCH v8] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

[Bart Van Assche]

On 06/28/2016 10:57 PM, Bryant G. Ly wrote:

I was hoping someone in the community can help answer this:

If I were to remove the masking off of the lun addressing method prior to 
target_submit_cmd/target_submit_tmr then I get a hang within scsi probe
on bootup. (srp->lun.scsi_lun[0] &= 0x3f; and srp_tsk->lun.scsi_lun[0] &= 0x3f;)

[0.842648] ibmvscsi 300d: sent SRP login
[0.842667] ibmvscsi 300d: SRP_LOGIN succeeded
[0.842682] scsi 0:0:2:0: CD-ROMAIX  VOPTA 
PQ: 0 ANSI: 4
[  OK  ] Started Show Plymouth Boot Screen.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Basic System.
[0.886179] sr 0:0:2:0: [sr0] scsi-1 drive
[0.886199] cdrom: Uniform CD-ROM driver Revision: 3.20
[0.888582] sd 0:0:1:0: [sda] 41943040 512-byte logical blocks: (21.4 
GB/20.0 GiB)
[0.888657] sd 0:0:1:0: [sda] Write Protect is off
[0.888712] sd 0:0:1:0: [sda] Cache data unavailable
[0.888722] sd 0:0:1:0: [sda] Assuming drive cache: write through
[0.901443]  sda: sda1 sda2 sda3
[0.901838] sd 0:0:1:0: [sda] Attached SCSI disk
[  124.522778] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  125.151242] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  125.662808] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts

Does anyone know of the reasoning for having to mask off the addressing method 
prior
to submitting to target?


How long have you waited before giving up waiting? The SCSI initiator 
sends a REPORT LUN and other SCSI commands to LUN 0. If LUN 0 is missing 
these commands will time out but that should not cause a hang. Anyway, 
SysRq-w should help to determine the cause of the hang.


Bart.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8] ibmvscsis: Initial commit of IBM VSCSI Tgt Driver

[Bryant G. Ly]

On 6/27/16, 3:17 PM, "Michael Cyr"  wrote:



+   cmd->se_cmd.tag = be64_to_cpu(srp->tag);
+
+   spin_lock_bh(>intr_lock);
+   list_add_tail(>list, >active_q);
+   spin_unlock_bh(>intr_lock);
+
+   srp->lun.scsi_lun[0] &= 0x3f;
+
+   pr_debug("calling submit_cmd, se_cmd %p, lun 0x%llx, cdb 0x%x, 
attr:%d\n",
+>se_cmd, scsilun_to_int(>lun), (int)srp->cdb[0],
+attr);
+
+   rc = target_submit_cmd(>se_cmd, nexus->se_sess, srp->cdb,
+  cmd->sense_buf, scsilun_to_int(>lun),
+  data_len, attr, dir, 0);
+   if (rc) {



+ * ibmvscsis_parse_task() - Parse SRP Task Management Request
+ *
+ * Parse the srp task management request; if it is valid then submit it to tcm.
+ * Note: The return code does not reflect the status of the task management
+ * request.
+ *
+ * EXECUTION ENVIRONMENT:
+ * Processor level
+ */
+static void ibmvscsis_parse_task(struct scsi_info *vscsi,
+struct ibmvscsis_cmd *cmd)
+{


+   spin_lock_bh(>intr_lock);
+   list_add_tail(>list, >active_q);
+   spin_unlock_bh(>intr_lock);
+
+   srp_tsk->lun.scsi_lun[0] &= 0x3f;
+
+   pr_debug("calling submit_tmr, func %d\n",
+srp_tsk->tsk_mgmt_func);
+   rc = target_submit_tmr(>se_cmd, nexus->se_sess, NULL,
+  scsilun_to_int(_tsk->lun), srp_tsk,
+  tcm_type, GFP_KERNEL, tag_to_abort, 0);
+   if (rc) {


I was hoping someone in the community can help answer this:

If I were to remove the masking off of the lun addressing method prior to 
target_submit_cmd/target_submit_tmr then I get a hang within scsi probe 
on bootup. (srp->lun.scsi_lun[0] &= 0x3f; and srp_tsk->lun.scsi_lun[0] &= 0x3f;)

[0.842648] ibmvscsi 300d: sent SRP login
[0.842667] ibmvscsi 300d: SRP_LOGIN succeeded
[0.842682] scsi 0:0:2:0: CD-ROMAIX  VOPTA 
PQ: 0 ANSI: 4
[  OK  ] Started Show Plymouth Boot Screen.
[  OK  ] Reached target Paths.
[  OK  ] Reached target Basic System.
[0.886179] sr 0:0:2:0: [sr0] scsi-1 drive
[0.886199] cdrom: Uniform CD-ROM driver Revision: 3.20
[0.888582] sd 0:0:1:0: [sda] 41943040 512-byte logical blocks: (21.4 
GB/20.0 GiB)
[0.888657] sd 0:0:1:0: [sda] Write Protect is off
[0.888712] sd 0:0:1:0: [sda] Cache data unavailable
[0.888722] sd 0:0:1:0: [sda] Assuming drive cache: write through
[0.901443]  sda: sda1 sda2 sda3
[0.901838] sd 0:0:1:0: [sda] Attached SCSI disk
[  124.522778] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  125.151242] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts
[  125.662808] dracut-initqueue[353]: Warning: dracut-initqueue timeout - 
starting timeout scripts

Does anyone know of the reasoning for having to mask off the addressing method 
prior
to submitting to target?

Thanks,

Bryant


--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html