Re: [Bug 111441] New: iscsi fails to attach to targets

[Nicholas A. Bellinger]

Hey Hannes,

On Tue, 2016-02-16 at 20:08 +0100, Hannes Reinecke wrote:
> On 02/08/2016 09:01 AM, Nicholas A. Bellinger wrote:
> > On Tue, 2016-02-02 at 14:56 -0800, Nicholas A. Bellinger wrote:
> >> On Mon, 2016-02-01 at 10:55 -0600, Mike Christie wrote:
> >>> On 01/30/2016 01:38 AM, Nicholas A. Bellinger wrote:
>  On Fri, 2016-01-29 at 17:32 -0600, Mike Christie wrote:



>  Btw, what does misconfigured mean here wrt target ALUA..?
> >>>
> >>> [   25.833195] sd 6:0:0:4: alua: supports implicit and explicit TPGS
> >>> [   25.833360] sd 6:0:0:4: alua: No target port descriptors found
> >>> [   25.833363] sd 6:0:0:4: alua: Attach failed (-22)
> >>> [   25.833365] sd 6:0:0:4: failed to add device handler: -22
> >>>
> >>
> >> Strange, this hasn't changed in forever on the target side..
> >>
> >>> He has LIO configured to report it supports implicit/explicit ALUA, but
> >>> the ports do not seem to be configured.
> >>>
> >>> For the LIO config side, are his LUNs just not in a the default_lu_gp or
> >>> any other group?
> >>
> >> So every non-PSCSI backend device becomes part of default_lu_gp +
> >> default_tg_pt_gp and automatically shows up in EVPD=0x83, without user
> >> needing to do any additional configuration.
> >>
> >> Here's what the output looks like:
> >>
> >> root@haakon3:/usr/src/target-pending.git# sg_inq -Hi /dev/sdb
> >> VPD INQUIRY: Device Identification page
> >>
> >>Designation descriptor number 3, descriptor length: 8
> >>  transport: Serial Attached SCSI Protocol (SPL-2)
> >>  designator_type: Relative target port,  code_set: Binary
> >>  associated with the target port
> >>  designator header(hex): 61 94 00 04
> >>  designator:
> >>   00 00 00 00 02 
> >>Designation descriptor number 4, descriptor length: 8
> >>  transport: Serial Attached SCSI Protocol (SPL-2)
> >>  designator_type: Target port group,  code_set: Binary
> >>  associated with the target port
> >>  designator header(hex): 61 95 00 04
> >>  designator:
> >>   00 00 00 00 00 
> >>Designation descriptor number 5, descriptor length: 8
> >>  designator_type: Logical unit group,  code_set: Binary
> >>  associated with the addressed logical unit
> >>  designator header(hex): 01 06 00 04
> >>  designator:
> >>   00 00 00 00 00 
> >>   
> >>
> >> So AFAICT, the relative target port, target port group, and logical unit
> >> group being returned from target on v4.5-rc1 code looks correct.
> >>
> >> Serguei, can you confirm with 'sg_inq -Hi /dev/sdX' output on your side
> >> with the v3.10 based target..?
> >>
> >> AFAICT the parsing in scsi_vpd_tpg_id() from commit a8aa3978 looks
> >> correct too.
> >>
> >> Hannes, any ideas..?
> >
> > Ping.
> >
> Please try with my latest scsi_dh_alua patchset posted to linux-scsi.
> That should solve the error attaching devices.
> 

Just to confirm, this was not a target side issue, right..?

Also, since Serguei is seeing this on v4.4 we'll still need some hack
for stable, assuming you're entire patchset won't be in 4.4.y code.  ;)

Are you OK with Mike's original patch, or do you have something better
to submit to Greg-KH..?

--
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: [Bug 111441] New: iscsi fails to attach to targets

[Serguei Bezverkhi (sbezverk)]

Hello Hannes,

Thank you for your reply. I am on 4.4.2 kernel, is there any chance to commit 
it in 4.4 as well? If not, could you send me diff for 4.4 kernel.

Best regards

Serguei


Serguei Bezverkhi,
TECHNICAL LEADER.SERVICES
Global SP Services
sbezv...@cisco.com
Phone: +1 416 306 7312
Mobile: +1 514 234 7374

CCIE (R,SP,Sec) - #9527

Cisco.com



 Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click here for Company Registration Information.




-Original Message-
From: Hannes Reinecke [mailto:h...@suse.de] 
Sent: Monday, February 22, 2016 2:08 AM
To: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>; Mike Christie 
<micha...@cs.wisc.edu>
Cc: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org; Christoph 
Hellwig <h...@infradead.org>
Subject: Re: [Bug 111441] New: iscsi fails to attach to targets

On 02/22/2016 01:45 AM, Serguei Bezverkhi (sbezverk) wrote:
> Hi Mike,
> 
> I just wanted to follow up with you to see if the patch got committed to an 
> upstream kernel if yes, please let me into which version it went.
> 
> Thank you
> 
> Serguei
> 
> 
> Serguei Bezverkhi,
> TECHNICAL LEADER.SERVICES
> Global SP Services
> sbezv...@cisco.com
> Phone: +1 416 306 7312
> Mobile: +1 514 234 7374
> 
> CCIE (R,SP,Sec) - #9527
> 
> Cisco.com
> 
> 
> 
>  Think before you print.
> This email may contain confidential and privileged material for the sole use 
> of the intended recipient. Any review, use, distribution or disclosure by 
> others is strictly prohibited. If you are not the intended recipient (or 
> authorized to receive for the recipient), please contact the sender by reply 
> email and delete all copies of this message.
> Please click here for Company Registration Information.
> 
> 
> 
> -Original Message-
> From: Mike Christie [mailto:micha...@cs.wisc.edu]
> Sent: Friday, January 29, 2016 6:33 PM
> To: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>
> Cc: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org; 
> Christoph Hellwig <h...@infradead.org>; Hannes Reinecke <h...@suse.de>
> Subject: Re: [Bug 111441] New: iscsi fails to attach to targets
> 
> On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
>> HI Mike,
>>
>> I tried your patch and it is has eliminated first traceback but I still do 
>> not see my remote targets.
>>
> 
> That is sort of expected. Your target is not setup for ALUA properly. It says 
> it supports ALUA, but when scsi_dh_alua asks about the ports it is reporting 
> there are none. Ccing the people that made the patch that added the issue and 
> own the code.
> 
> Hey Christoph and Hannes,
> 
> The dh/alua changes that added this:
> 
> error = scsi_dh_add_device(sdev);
> if (error) {
> sdev_printk(KERN_INFO, sdev,
> "failed to add device handler: %d\n", error);
> return error;
> }
> 
> to scsi_sysfs_add_sdev are adding a regression.
> 
> 1. If that fails, then we forget to do device_del before doing the return. My 
> patch in this thread added that back, so we do not see the sysfs oopses 
> anymore. But.
> 
> 2. It looks like in older kernels, we would allow misconfigured targets like 
> this one to still setup devices. Do we want that old behavior back?
> Should we just ignore the return value from scsi_dh_add_device above?
> Note that in this case, it is LIO so it can be easily fixed on the target 
> side by just setting it up properly. I do not think other targets would hit 
> this type of issue.
> 
> 
This has been fixed up with my patchset to update the ALUA handler, most 
notably the commit 'scsi: ignore errors from scsi_dh_add_device()' which was 
included in 4.5.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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: [Bug 111441] New: iscsi fails to attach to targets

[Hannes Reinecke]

On 02/22/2016 01:45 AM, Serguei Bezverkhi (sbezverk) wrote:
> Hi Mike,
> 
> I just wanted to follow up with you to see if the patch got committed to an 
> upstream kernel if yes, please let me into which version it went.
> 
> Thank you
> 
> Serguei
> 
> 
> Serguei Bezverkhi,
> TECHNICAL LEADER.SERVICES
> Global SP Services
> sbezv...@cisco.com
> Phone: +1 416 306 7312
> Mobile: +1 514 234 7374
> 
> CCIE (R,SP,Sec) - #9527
> 
> Cisco.com
> 
> 
> 
>  Think before you print.
> This email may contain confidential and privileged material for the sole use 
> of the intended recipient. Any review, use, distribution or disclosure by 
> others is strictly prohibited. If you are not the intended recipient (or 
> authorized to receive for the recipient), please contact the sender by reply 
> email and delete all copies of this message.
> Please click here for Company Registration Information.
> 
> 
> 
> -Original Message-
> From: Mike Christie [mailto:micha...@cs.wisc.edu] 
> Sent: Friday, January 29, 2016 6:33 PM
> To: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>
> Cc: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org; 
> Christoph Hellwig <h...@infradead.org>; Hannes Reinecke <h...@suse.de>
> Subject: Re: [Bug 111441] New: iscsi fails to attach to targets
> 
> On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
>> HI Mike,
>>
>> I tried your patch and it is has eliminated first traceback but I still do 
>> not see my remote targets.
>>
> 
> That is sort of expected. Your target is not setup for ALUA properly. It says 
> it supports ALUA, but when scsi_dh_alua asks about the ports it is reporting 
> there are none. Ccing the people that made the patch that added the issue and 
> own the code.
> 
> Hey Christoph and Hannes,
> 
> The dh/alua changes that added this:
> 
> error = scsi_dh_add_device(sdev);
> if (error) {
> sdev_printk(KERN_INFO, sdev,
> "failed to add device handler: %d\n", error);
> return error;
> }
> 
> to scsi_sysfs_add_sdev are adding a regression.
> 
> 1. If that fails, then we forget to do device_del before doing the return. My 
> patch in this thread added that back, so we do not see the sysfs oopses 
> anymore. But.
> 
> 2. It looks like in older kernels, we would allow misconfigured targets like 
> this one to still setup devices. Do we want that old behavior back?
> Should we just ignore the return value from scsi_dh_add_device above?
> Note that in this case, it is LIO so it can be easily fixed on the target 
> side by just setting it up properly. I do not think other targets would hit 
> this type of issue.
> 
> 
This has been fixed up with my patchset to update the ALUA handler, most
notably the commit 'scsi: ignore errors from scsi_dh_add_device()' which
was included in 4.5.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
--
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: [Bug 111441] New: iscsi fails to attach to targets

[Serguei Bezverkhi (sbezverk)]

Hi Mike,

I just wanted to follow up with you to see if the patch got committed to an 
upstream kernel if yes, please let me into which version it went.

Thank you

Serguei


Serguei Bezverkhi,
TECHNICAL LEADER.SERVICES
Global SP Services
sbezv...@cisco.com
Phone: +1 416 306 7312
Mobile: +1 514 234 7374

CCIE (R,SP,Sec) - #9527

Cisco.com



 Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click here for Company Registration Information.



-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu] 
Sent: Friday, January 29, 2016 6:33 PM
To: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>
Cc: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org; Christoph 
Hellwig <h...@infradead.org>; Hannes Reinecke <h...@suse.de>
Subject: Re: [Bug 111441] New: iscsi fails to attach to targets

On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
> HI Mike,
> 
> I tried your patch and it is has eliminated first traceback but I still do 
> not see my remote targets.
> 

That is sort of expected. Your target is not setup for ALUA properly. It says 
it supports ALUA, but when scsi_dh_alua asks about the ports it is reporting 
there are none. Ccing the people that made the patch that added the issue and 
own the code.

Hey Christoph and Hannes,

The dh/alua changes that added this:

error = scsi_dh_add_device(sdev);
if (error) {
sdev_printk(KERN_INFO, sdev,
"failed to add device handler: %d\n", error);
return error;
}

to scsi_sysfs_add_sdev are adding a regression.

1. If that fails, then we forget to do device_del before doing the return. My 
patch in this thread added that back, so we do not see the sysfs oopses 
anymore. But.

2. It looks like in older kernels, we would allow misconfigured targets like 
this one to still setup devices. Do we want that old behavior back?
Should we just ignore the return value from scsi_dh_add_device above?
Note that in this case, it is LIO so it can be easily fixed on the target side 
by just setting it up properly. I do not think other targets would hit this 
type of issue.





> 
> Here is dmesg
> 
> [   26.103812] scsi 3:0:0:2: Direct-Access LIO-ORG  san-disk-2   4.0  
> PQ: 0 ANSI: 5
> [   26.104338] sd 3:0:0:2: alua: supports implicit and explicit TPGS
> [   26.104549] sd 3:0:0:2: alua: No target port descriptors found
> [   26.104552] sd 3:0:0:2: alua: Attach failed (-22)
> [   26.104554] sd 3:0:0:2: failed to add device handler: -22
> [   26.104578] sd 3:0:0:2: [sdc] 20507809792 512-byte logical blocks: (10.4 
> TB/9.54 TiB)
> [   26.104905] sd 3:0:0:2: [sdc] Write Protect is off
> [   26.104908] sd 3:0:0:2: [sdc] Mode Sense: 43 00 10 08
> [   26.105036] sd 3:0:0:2: [sdc] Write cache: enabled, read cache: enabled, 
> supports DPO and FUA
> [   26.112294] scsi host6: iSCSI Initiator over TCP/IP
> [   26.113279] scsi 4:0:0:3: Direct-Access LIO-ORG  san-disk-3   4.0  
> PQ: 0 ANSI: 5
> [   26.113690] sd 4:0:0:3: alua: supports implicit and explicit TPGS
> [   26.113877] sd 4:0:0:3: [sdd] 9765625856 512-byte logical blocks: (5.00 
> TB/4.54 TiB)
> [   26.113948] sd 4:0:0:3: alua: No target port descriptors found
> [   26.113951] sd 4:0:0:3: alua: Attach failed (-22)
> [   26.113953] sd 4:0:0:3: failed to add device handler: -22
> [   26.114292] sd 4:0:0:3: [sdd] Write Protect is off
> [   26.114295] sd 4:0:0:3: [sdd] Mode Sense: 43 00 10 08
> [   26.114503] sd 4:0:0:3: [sdd] Write cache: enabled, read cache: enabled, 
> supports DPO and FUA
> [   26.123875] scsi 5:0:0:1: Direct-Access LIO-ORG  san-disk-1   4.0  
> PQ: 0 ANSI: 5
> [   26.123911] scsi 6:0:0:4: Direct-Access LIO-ORG  san-disk-4   4.0  
> PQ: 0 ANSI: 5
> [   26.124452] sd 6:0:0:4: alua: supports implicit and explicit TPGS
> [   26.124453] sd 5:0:0:1: alua: supports implicit and explicit TPGS
> [   26.124724] sd 5:0:0:1: alua: No target port descriptors found
> [   26.124727] sd 5:0:0:1: alua: Attach failed (-22)
> [   26.124728] sd 5:0:0:1: failed to add device handler: -22
> [   26.124736] sd 6:0:0:4: [sde] 10742171648 512-byte logical blocks: (5.49 
> TB/5.00 TiB)
> [   26.124773] sd 5:0:0:1: [sdf] 7812499389 512-byte logical blocks: (3.99 
> TB/3.63 TiB)
> [   26.124777] sd 6:0:0:4: alua: No target port descriptors found
> [   26.124779] sd 6:0:0:4: alua: Attach failed (-22)
> [   26.124780] sd 6:0:0:4: failed to add device handler: -22
> [   26.125182] sd 

Re: [Bug 111441] New: iscsi fails to attach to targets

[Hannes Reinecke]

On 02/08/2016 09:01 AM, Nicholas A. Bellinger wrote:

On Tue, 2016-02-02 at 14:56 -0800, Nicholas A. Bellinger wrote:

On Mon, 2016-02-01 at 10:55 -0600, Mike Christie wrote:

On 01/30/2016 01:38 AM, Nicholas A. Bellinger wrote:

On Fri, 2016-01-29 at 17:32 -0600, Mike Christie wrote:

On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:

HI Mike,

I tried your patch and it is has eliminated first traceback but I still do not 
see my remote targets.



That is sort of expected. Your target is not setup for ALUA properly. It
says it supports ALUA, but when scsi_dh_alua asks about the ports it is
reporting there are none. Ccing the people that made the patch that
added the issue and own the code.

Hey Christoph and Hannes,

The dh/alua changes that added this:

 error = scsi_dh_add_device(sdev);
 if (error) {
 sdev_printk(KERN_INFO, sdev,
 "failed to add device handler: %d\n",
error);
 return error;
 }

to scsi_sysfs_add_sdev are adding a regression.

1. If that fails, then we forget to do device_del before doing the
return. My patch in this thread added that back, so we do not see the
sysfs oopses anymore. But.

2. It looks like in older kernels, we would allow misconfigured targets
like this one to still setup devices. Do we want that old behavior back?
Should we just ignore the return value from scsi_dh_add_device above?
Note that in this case, it is LIO so it can be easily fixed on the
target side by just setting it up properly. I do not think other targets
would hit this type of issue.



Btw, what does misconfigured mean here wrt target ALUA..?


[   25.833195] sd 6:0:0:4: alua: supports implicit and explicit TPGS
[   25.833360] sd 6:0:0:4: alua: No target port descriptors found
[   25.833363] sd 6:0:0:4: alua: Attach failed (-22)
[   25.833365] sd 6:0:0:4: failed to add device handler: -22



Strange, this hasn't changed in forever on the target side..


He has LIO configured to report it supports implicit/explicit ALUA, but
the ports do not seem to be configured.

For the LIO config side, are his LUNs just not in a the default_lu_gp or
any other group?


So every non-PSCSI backend device becomes part of default_lu_gp +
default_tg_pt_gp and automatically shows up in EVPD=0x83, without user
needing to do any additional configuration.

Here's what the output looks like:

root@haakon3:/usr/src/target-pending.git# sg_inq -Hi /dev/sdb
VPD INQUIRY: Device Identification page
   
   Designation descriptor number 3, descriptor length: 8
 transport: Serial Attached SCSI Protocol (SPL-2)
 designator_type: Relative target port,  code_set: Binary
 associated with the target port
 designator header(hex): 61 94 00 04
 designator:
  00 00 00 00 02 
   Designation descriptor number 4, descriptor length: 8
 transport: Serial Attached SCSI Protocol (SPL-2)
 designator_type: Target port group,  code_set: Binary
 associated with the target port
 designator header(hex): 61 95 00 04
 designator:
  00 00 00 00 00 
   Designation descriptor number 5, descriptor length: 8
 designator_type: Logical unit group,  code_set: Binary
 associated with the addressed logical unit
 designator header(hex): 01 06 00 04
 designator:
  00 00 00 00 00 
  

So AFAICT, the relative target port, target port group, and logical unit
group being returned from target on v4.5-rc1 code looks correct.

Serguei, can you confirm with 'sg_inq -Hi /dev/sdX' output on your side
with the v3.10 based target..?

AFAICT the parsing in scsi_vpd_tpg_id() from commit a8aa3978 looks
correct too.

Hannes, any ideas..?


Ping.


Please try with my latest scsi_dh_alua patchset posted to linux-scsi.
That should solve the error attaching devices.

Cheers,

Hannes
--
Dr. Hannes Reinecke
Kirchenweg 47
D-90419 Nürnberg
Tel.: 0911 - 3 77 76 10
--
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: [Bug 111441] New: iscsi fails to attach to targets

[Nicholas A. Bellinger]

On Tue, 2016-02-02 at 14:56 -0800, Nicholas A. Bellinger wrote:
> On Mon, 2016-02-01 at 10:55 -0600, Mike Christie wrote:
> > On 01/30/2016 01:38 AM, Nicholas A. Bellinger wrote:
> > > On Fri, 2016-01-29 at 17:32 -0600, Mike Christie wrote:
> > >> On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
> > >>> HI Mike,
> > >>>
> > >>> I tried your patch and it is has eliminated first traceback but I still 
> > >>> do not see my remote targets.
> > >>>
> > >>
> > >> That is sort of expected. Your target is not setup for ALUA properly. It
> > >> says it supports ALUA, but when scsi_dh_alua asks about the ports it is
> > >> reporting there are none. Ccing the people that made the patch that
> > >> added the issue and own the code.
> > >>
> > >> Hey Christoph and Hannes,
> > >>
> > >> The dh/alua changes that added this:
> > >>
> > >> error = scsi_dh_add_device(sdev);
> > >> if (error) {
> > >> sdev_printk(KERN_INFO, sdev,
> > >> "failed to add device handler: %d\n",
> > >> error);
> > >> return error;
> > >> }
> > >>
> > >> to scsi_sysfs_add_sdev are adding a regression.
> > >>
> > >> 1. If that fails, then we forget to do device_del before doing the
> > >> return. My patch in this thread added that back, so we do not see the
> > >> sysfs oopses anymore. But.
> > >>
> > >> 2. It looks like in older kernels, we would allow misconfigured targets
> > >> like this one to still setup devices. Do we want that old behavior back?
> > >> Should we just ignore the return value from scsi_dh_add_device above?
> > >> Note that in this case, it is LIO so it can be easily fixed on the
> > >> target side by just setting it up properly. I do not think other targets
> > >> would hit this type of issue.
> > >>
> > > 
> > > Btw, what does misconfigured mean here wrt target ALUA..?
> > 
> > [   25.833195] sd 6:0:0:4: alua: supports implicit and explicit TPGS
> > [   25.833360] sd 6:0:0:4: alua: No target port descriptors found
> > [   25.833363] sd 6:0:0:4: alua: Attach failed (-22)
> > [   25.833365] sd 6:0:0:4: failed to add device handler: -22
> > 
> 
> Strange, this hasn't changed in forever on the target side..
> 
> > He has LIO configured to report it supports implicit/explicit ALUA, but
> > the ports do not seem to be configured.
> > 
> > For the LIO config side, are his LUNs just not in a the default_lu_gp or
> > any other group?
> 
> So every non-PSCSI backend device becomes part of default_lu_gp +
> default_tg_pt_gp and automatically shows up in EVPD=0x83, without user
> needing to do any additional configuration.
> 
> Here's what the output looks like:
> 
> root@haakon3:/usr/src/target-pending.git# sg_inq -Hi /dev/sdb
> VPD INQUIRY: Device Identification page
>   
>   Designation descriptor number 3, descriptor length: 8
> transport: Serial Attached SCSI Protocol (SPL-2)
> designator_type: Relative target port,  code_set: Binary
> associated with the target port
> designator header(hex): 61 94 00 04
> designator:
>  00 00 00 00 02 
>   Designation descriptor number 4, descriptor length: 8
> transport: Serial Attached SCSI Protocol (SPL-2)
> designator_type: Target port group,  code_set: Binary
> associated with the target port
> designator header(hex): 61 95 00 04
> designator:
>  00 00 00 00 00 
>   Designation descriptor number 5, descriptor length: 8
> designator_type: Logical unit group,  code_set: Binary
> associated with the addressed logical unit
> designator header(hex): 01 06 00 04
> designator:
>  00 00 00 00 00 
>  
> 
> So AFAICT, the relative target port, target port group, and logical unit
> group being returned from target on v4.5-rc1 code looks correct.
> 
> Serguei, can you confirm with 'sg_inq -Hi /dev/sdX' output on your side
> with the v3.10 based target..?
> 
> AFAICT the parsing in scsi_vpd_tpg_id() from commit a8aa3978 looks
> correct too.
> 
> Hannes, any ideas..?

Ping.

--
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: [Bug 111441] New: iscsi fails to attach to targets

[Serguei Bezverkhi (sbezverk)]

Sure thing, I will test it tonight and let you know the result.

Thank you

Serguei

-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu] 
Sent: Tuesday, February 02, 2016 3:12 PM
To: Christoph Hellwig <h...@infradead.org>
Cc: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>; 
bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org; Hannes 
Reinecke <h...@suse.de>
Subject: Re: [Bug 111441] New: iscsi fails to attach to targets

On 02/02/2016 12:09 PM, Christoph Hellwig wrote:
> On Fri, Jan 29, 2016 at 05:32:54PM -0600, Mike Christie wrote:
>> Hey Christoph and Hannes,
>>
>> The dh/alua changes that added this:
>>
>> error = scsi_dh_add_device(sdev);
>> if (error) {
>> sdev_printk(KERN_INFO, sdev,
>> "failed to add device handler: %d\n", 
>> error);
>> return error;
>> }
>>
>> to scsi_sysfs_add_sdev are adding a regression.
>>
>> 1. If that fails, then we forget to do device_del before doing the 
>> return. My patch in this thread added that back, so we do not see the 
>> sysfs oopses anymore. But.
> 
> Ok.
> 
>> 2. It looks like in older kernels, we would allow misconfigured 
>> targets like this one to still setup devices. Do we want that old behavior 
>> back?
>> Should we just ignore the return value from scsi_dh_add_device above?
>> Note that in this case, it is LIO so it can be easily fixed on the 
>> target side by just setting it up properly. I do not think other 
>> targets would hit this type of issue.
> 
> Be liberal in what you accept..  I guess we need to continue allowing 
> to connect to these broken targets, but a warning would be useful.
> 
> Can you send a patch?

Serguei, can you try the attached patch? Drop the other one I sent.
--
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: [Bug 111441] New: iscsi fails to attach to targets

[Mike Christie]

On 02/02/2016 12:09 PM, Christoph Hellwig wrote:
> On Fri, Jan 29, 2016 at 05:32:54PM -0600, Mike Christie wrote:
>> Hey Christoph and Hannes,
>>
>> The dh/alua changes that added this:
>>
>> error = scsi_dh_add_device(sdev);
>> if (error) {
>> sdev_printk(KERN_INFO, sdev,
>> "failed to add device handler: %d\n",
>> error);
>> return error;
>> }
>>
>> to scsi_sysfs_add_sdev are adding a regression.
>>
>> 1. If that fails, then we forget to do device_del before doing the
>> return. My patch in this thread added that back, so we do not see the
>> sysfs oopses anymore. But.
> 
> Ok.
> 
>> 2. It looks like in older kernels, we would allow misconfigured targets
>> like this one to still setup devices. Do we want that old behavior back?
>> Should we just ignore the return value from scsi_dh_add_device above?
>> Note that in this case, it is LIO so it can be easily fixed on the
>> target side by just setting it up properly. I do not think other targets
>> would hit this type of issue.
> 
> Be liberal in what you accept..  I guess we need to continue allowing
> to connect to these broken targets, but a warning would be useful.
> 
> Can you send a patch?

Serguei, can you try the attached patch? Drop the other one I sent.
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 21930c9..7dcc4bf 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1059,9 +1059,12 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 
 	error = scsi_dh_add_device(sdev);
 	if (error) {
+		/*
+		 * Allow device setup to succeed. Attachment can be retried
+		 * from userpsace or device can be still used in degraded mode.
+		 */
 		sdev_printk(KERN_INFO, sdev,
 "failed to add device handler: %d\n", error);
-		return error;
 	}
 
 	device_enable_async_suspend(>sdev_dev);

RE: [Bug 111441] New: iscsi fails to attach to targets

[Serguei Bezverkhi (sbezverk)]

HI Mike,

It is working now, it spits alua related error messages but it attaches remote 
and local targets, so my OpenStack is back to life. Please let me know if you 
plan to commit this fix upstream.

[   27.579303] scsi 3:0:0:2: Direct-Access LIO-ORG  san-disk-2   4.0  
PQ: 0 ANSI: 5
[   27.579797] sd 3:0:0:2: alua: supports implicit and explicit TPGS
[   27.579932] sd 3:0:0:2: [sdc] 20507809792 512-byte logical blocks: (10.4 
TB/9.54 TiB)
[   27.579975] sd 3:0:0:2: alua: No target port descriptors found
[   27.579977] sd 3:0:0:2: alua: Attach failed (-22)
[   27.580640] sd 3:0:0:2: failed to add device handler: -22
[   27.580897] sd 3:0:0:2: [sdc] Write Protect is off
[   27.580899] sd 3:0:0:2: [sdc] Mode Sense: 43 00 10 08
[   27.580922] sd 3:0:0:2: Attached scsi generic sg3 type 0
[   27.581041] sd 3:0:0:2: [sdc] Write cache: enabled, read cache: enabled, 
supports DPO and FUA
[   27.630156] sd 3:0:0:2: [sdc] Attached SCSI disk

Thank you very much

Serguei


Serguei Bezverkhi,
TECHNICAL LEADER.SERVICES
Global SP Services
sbezv...@cisco.com
Phone: +1 416 306 7312
Mobile: +1 514 234 7374

CCIE (R,SP,Sec) - #9527

Cisco.com



 Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click here for Company Registration Information.




-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu] 
Sent: Tuesday, February 02, 2016 3:12 PM
To: Christoph Hellwig <h...@infradead.org>
Cc: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>; 
bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org; Hannes 
Reinecke <h...@suse.de>
Subject: Re: [Bug 111441] New: iscsi fails to attach to targets

On 02/02/2016 12:09 PM, Christoph Hellwig wrote:
> On Fri, Jan 29, 2016 at 05:32:54PM -0600, Mike Christie wrote:
>> Hey Christoph and Hannes,
>>
>> The dh/alua changes that added this:
>>
>> error = scsi_dh_add_device(sdev);
>> if (error) {
>> sdev_printk(KERN_INFO, sdev,
>> "failed to add device handler: %d\n", 
>> error);
>> return error;
>> }
>>
>> to scsi_sysfs_add_sdev are adding a regression.
>>
>> 1. If that fails, then we forget to do device_del before doing the 
>> return. My patch in this thread added that back, so we do not see the 
>> sysfs oopses anymore. But.
> 
> Ok.
> 
>> 2. It looks like in older kernels, we would allow misconfigured 
>> targets like this one to still setup devices. Do we want that old behavior 
>> back?
>> Should we just ignore the return value from scsi_dh_add_device above?
>> Note that in this case, it is LIO so it can be easily fixed on the 
>> target side by just setting it up properly. I do not think other 
>> targets would hit this type of issue.
> 
> Be liberal in what you accept..  I guess we need to continue allowing 
> to connect to these broken targets, but a warning would be useful.
> 
> Can you send a patch?

Serguei, can you try the attached patch? Drop the other one I sent.
--
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: [Bug 111441] New: iscsi fails to attach to targets

[Nicholas A. Bellinger]

On Mon, 2016-02-01 at 10:55 -0600, Mike Christie wrote:
> On 01/30/2016 01:38 AM, Nicholas A. Bellinger wrote:
> > On Fri, 2016-01-29 at 17:32 -0600, Mike Christie wrote:
> >> On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
> >>> HI Mike,
> >>>
> >>> I tried your patch and it is has eliminated first traceback but I still 
> >>> do not see my remote targets.
> >>>
> >>
> >> That is sort of expected. Your target is not setup for ALUA properly. It
> >> says it supports ALUA, but when scsi_dh_alua asks about the ports it is
> >> reporting there are none. Ccing the people that made the patch that
> >> added the issue and own the code.
> >>
> >> Hey Christoph and Hannes,
> >>
> >> The dh/alua changes that added this:
> >>
> >> error = scsi_dh_add_device(sdev);
> >> if (error) {
> >> sdev_printk(KERN_INFO, sdev,
> >> "failed to add device handler: %d\n",
> >> error);
> >> return error;
> >> }
> >>
> >> to scsi_sysfs_add_sdev are adding a regression.
> >>
> >> 1. If that fails, then we forget to do device_del before doing the
> >> return. My patch in this thread added that back, so we do not see the
> >> sysfs oopses anymore. But.
> >>
> >> 2. It looks like in older kernels, we would allow misconfigured targets
> >> like this one to still setup devices. Do we want that old behavior back?
> >> Should we just ignore the return value from scsi_dh_add_device above?
> >> Note that in this case, it is LIO so it can be easily fixed on the
> >> target side by just setting it up properly. I do not think other targets
> >> would hit this type of issue.
> >>
> > 
> > Btw, what does misconfigured mean here wrt target ALUA..?
> 
> [   25.833195] sd 6:0:0:4: alua: supports implicit and explicit TPGS
> [   25.833360] sd 6:0:0:4: alua: No target port descriptors found
> [   25.833363] sd 6:0:0:4: alua: Attach failed (-22)
> [   25.833365] sd 6:0:0:4: failed to add device handler: -22
> 

Strange, this hasn't changed in forever on the target side..

> He has LIO configured to report it supports implicit/explicit ALUA, but
> the ports do not seem to be configured.
> 
> For the LIO config side, are his LUNs just not in a the default_lu_gp or
> any other group?

So every non-PSCSI backend device becomes part of default_lu_gp +
default_tg_pt_gp and automatically shows up in EVPD=0x83, without user
needing to do any additional configuration.

Here's what the output looks like:

root@haakon3:/usr/src/target-pending.git# sg_inq -Hi /dev/sdb
VPD INQUIRY: Device Identification page
  
  Designation descriptor number 3, descriptor length: 8
transport: Serial Attached SCSI Protocol (SPL-2)
designator_type: Relative target port,  code_set: Binary
associated with the target port
designator header(hex): 61 94 00 04
designator:
 00 00 00 00 02 
  Designation descriptor number 4, descriptor length: 8
transport: Serial Attached SCSI Protocol (SPL-2)
designator_type: Target port group,  code_set: Binary
associated with the target port
designator header(hex): 61 95 00 04
designator:
 00 00 00 00 00 
  Designation descriptor number 5, descriptor length: 8
designator_type: Logical unit group,  code_set: Binary
associated with the addressed logical unit
designator header(hex): 01 06 00 04
designator:
 00 00 00 00 00 
 

So AFAICT, the relative target port, target port group, and logical unit
group being returned from target on v4.5-rc1 code looks correct.

Serguei, can you confirm with 'sg_inq -Hi /dev/sdX' output on your side
with the v3.10 based target..?

AFAICT the parsing in scsi_vpd_tpg_id() from commit a8aa3978 looks
correct too.

Hannes, any ideas..?

--
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: [Bug 111441] New: iscsi fails to attach to targets

[Serguei Bezverkhi (sbezverk)]

 
  Designation descriptor number 6, descriptor length: 80
transport: Internet SCSI (iSCSI)
designator_type: SCSI name string,  code_set: UTF-8
associated with the target port
designator header(hex): 53 98 00 4c
designator:
 00 69 71 6e 2e 32 30 30 33  2d 30 31 2e 6f 72 67 2eiqn.2003-01.org.
 10 6c 69 6e 75 78 2d 69 73  63 73 69 2e 73 62 65 7alinux-iscsi.sbez
 20 76 65 72 6b 2d 73 61 6e  2d 31 2e 78 38 36 36 34verk-san-1.x8664
 30 3a 73 6e 2e 33 64 66 63  66 66 62 64 66 66 34 33:sn.3dfcffbdff43
 40 2c 74 2c 30 78 30 30 30  31 00 00 00,t,0x0001...
  Designation descriptor number 7, descriptor length: 72
transport: Internet SCSI (iSCSI)
designator_type: SCSI name string,  code_set: UTF-8
associated with the target device that contains addressed lu
designator header(hex): 53 a8 00 44
designator:
 00 69 71 6e 2e 32 30 30 33  2d 30 31 2e 6f 72 67 2eiqn.2003-01.org.
 10 6c 69 6e 75 78 2d 69 73  63 73 69 2e 73 62 65 7alinux-iscsi.sbez
 20 76 65 72 6b 2d 73 61 6e  2d 31 2e 78 38 36 36 34verk-san-1.x8664
 30 3a 73 6e 2e 33 64 66 63  66 66 62 64 66 66 34 33:sn.3dfcffbdff43
 40 00 00 00 00   


Let me know if you need any additional info.

Thank you

Serguei


-Original Message-
From: Nicholas A. Bellinger [mailto:n...@linux-iscsi.org] 
Sent: Tuesday, February 02, 2016 5:56 PM
To: Mike Christie <micha...@cs.wisc.edu>
Cc: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>; 
bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org; Christoph 
Hellwig <h...@infradead.org>; Hannes Reinecke <h...@suse.de>
Subject: Re: [Bug 111441] New: iscsi fails to attach to targets

On Mon, 2016-02-01 at 10:55 -0600, Mike Christie wrote:
> On 01/30/2016 01:38 AM, Nicholas A. Bellinger wrote:
> > On Fri, 2016-01-29 at 17:32 -0600, Mike Christie wrote:
> >> On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
> >>> HI Mike,
> >>>
> >>> I tried your patch and it is has eliminated first traceback but I still 
> >>> do not see my remote targets.
> >>>
> >>
> >> That is sort of expected. Your target is not setup for ALUA 
> >> properly. It says it supports ALUA, but when scsi_dh_alua asks 
> >> about the ports it is reporting there are none. Ccing the people 
> >> that made the patch that added the issue and own the code.
> >>
> >> Hey Christoph and Hannes,
> >>
> >> The dh/alua changes that added this:
> >>
> >> error = scsi_dh_add_device(sdev);
> >> if (error) {
> >> sdev_printk(KERN_INFO, sdev,
> >> "failed to add device handler: 
> >> %d\n", error);
> >> return error;
> >> }
> >>
> >> to scsi_sysfs_add_sdev are adding a regression.
> >>
> >> 1. If that fails, then we forget to do device_del before doing the 
> >> return. My patch in this thread added that back, so we do not see 
> >> the sysfs oopses anymore. But.
> >>
> >> 2. It looks like in older kernels, we would allow misconfigured 
> >> targets like this one to still setup devices. Do we want that old behavior 
> >> back?
> >> Should we just ignore the return value from scsi_dh_add_device above?
> >> Note that in this case, it is LIO so it can be easily fixed on the 
> >> target side by just setting it up properly. I do not think other 
> >> targets would hit this type of issue.
> >>
> > 
> > Btw, what does misconfigured mean here wrt target ALUA..?
> 
> [   25.833195] sd 6:0:0:4: alua: supports implicit and explicit TPGS
> [   25.833360] sd 6:0:0:4: alua: No target port descriptors found
> [   25.833363] sd 6:0:0:4: alua: Attach failed (-22)
> [   25.833365] sd 6:0:0:4: failed to add device handler: -22
> 

Strange, this hasn't changed in forever on the target side..

> He has LIO configured to report it supports implicit/explicit ALUA, 
> but the ports do not seem to be configured.
> 
> For the LIO config side, are his LUNs just not in a the default_lu_gp 
> or any other group?

So every non-PSCSI backend device becomes part of default_lu_gp + 
default_tg_pt_gp and automatically shows up in EVPD=0x83, without user needing 
to do any additional configuration.

Here's what the output looks like:

root@haakon3:/usr/src/target-pending.git# sg_inq -Hi /dev/sdb VPD INQUIRY: 
Device Identification page
  
  Designation descriptor number 3, descriptor length: 8
transport: Serial Attached SCSI Protocol (SPL-2)
designator_type: Relative target port,  code_se

Re: [Bug 111441] New: iscsi fails to attach to targets

[Christoph Hellwig]

On Fri, Jan 29, 2016 at 05:32:54PM -0600, Mike Christie wrote:
> Hey Christoph and Hannes,
> 
> The dh/alua changes that added this:
> 
> error = scsi_dh_add_device(sdev);
> if (error) {
> sdev_printk(KERN_INFO, sdev,
> "failed to add device handler: %d\n",
> error);
> return error;
> }
> 
> to scsi_sysfs_add_sdev are adding a regression.
> 
> 1. If that fails, then we forget to do device_del before doing the
> return. My patch in this thread added that back, so we do not see the
> sysfs oopses anymore. But.

Ok.

> 2. It looks like in older kernels, we would allow misconfigured targets
> like this one to still setup devices. Do we want that old behavior back?
> Should we just ignore the return value from scsi_dh_add_device above?
> Note that in this case, it is LIO so it can be easily fixed on the
> target side by just setting it up properly. I do not think other targets
> would hit this type of issue.

Be liberal in what you accept..  I guess we need to continue allowing
to connect to these broken targets, but a warning would be useful.

Can you send a patch?
--
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: [Bug 111441] New: iscsi fails to attach to targets

[Serguei Bezverkhi (sbezverk)]

Hello,

Any chance we could move forward with this investigation? I still cannot attach 
to any remove iscsi targets with either 4.4.0 or 4.4.1 kernels.

Thank you

Serguei


 

-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu] 
Sent: Monday, February 01, 2016 11:55 AM
To: Nicholas A. Bellinger <n...@linux-iscsi.org>
Cc: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>; 
bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org; Christoph 
Hellwig <h...@infradead.org>; Hannes Reinecke <h...@suse.de>
Subject: Re: [Bug 111441] New: iscsi fails to attach to targets

On 01/30/2016 01:38 AM, Nicholas A. Bellinger wrote:
> On Fri, 2016-01-29 at 17:32 -0600, Mike Christie wrote:
>> On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
>>> HI Mike,
>>>
>>> I tried your patch and it is has eliminated first traceback but I still do 
>>> not see my remote targets.
>>>
>>
>> That is sort of expected. Your target is not setup for ALUA properly. 
>> It says it supports ALUA, but when scsi_dh_alua asks about the ports 
>> it is reporting there are none. Ccing the people that made the patch 
>> that added the issue and own the code.
>>
>> Hey Christoph and Hannes,
>>
>> The dh/alua changes that added this:
>>
>> error = scsi_dh_add_device(sdev);
>> if (error) {
>> sdev_printk(KERN_INFO, sdev,
>> "failed to add device handler: %d\n", 
>> error);
>> return error;
>> }
>>
>> to scsi_sysfs_add_sdev are adding a regression.
>>
>> 1. If that fails, then we forget to do device_del before doing the 
>> return. My patch in this thread added that back, so we do not see the 
>> sysfs oopses anymore. But.
>>
>> 2. It looks like in older kernels, we would allow misconfigured 
>> targets like this one to still setup devices. Do we want that old behavior 
>> back?
>> Should we just ignore the return value from scsi_dh_add_device above?
>> Note that in this case, it is LIO so it can be easily fixed on the 
>> target side by just setting it up properly. I do not think other 
>> targets would hit this type of issue.
>>
> 
> Btw, what does misconfigured mean here wrt target ALUA..?

[   25.833195] sd 6:0:0:4: alua: supports implicit and explicit TPGS
[   25.833360] sd 6:0:0:4: alua: No target port descriptors found
[   25.833363] sd 6:0:0:4: alua: Attach failed (-22)
[   25.833365] sd 6:0:0:4: failed to add device handler: -22

He has LIO configured to report it supports implicit/explicit ALUA, but the 
ports do not seem to be configured.

For the LIO config side, are his LUNs just not in a the default_lu_gp or any 
other group?
--
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: [Bug 111441] New: iscsi fails to attach to targets

[Mike Christie]

On 01/30/2016 01:38 AM, Nicholas A. Bellinger wrote:
> On Fri, 2016-01-29 at 17:32 -0600, Mike Christie wrote:
>> On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
>>> HI Mike,
>>>
>>> I tried your patch and it is has eliminated first traceback but I still do 
>>> not see my remote targets.
>>>
>>
>> That is sort of expected. Your target is not setup for ALUA properly. It
>> says it supports ALUA, but when scsi_dh_alua asks about the ports it is
>> reporting there are none. Ccing the people that made the patch that
>> added the issue and own the code.
>>
>> Hey Christoph and Hannes,
>>
>> The dh/alua changes that added this:
>>
>> error = scsi_dh_add_device(sdev);
>> if (error) {
>> sdev_printk(KERN_INFO, sdev,
>> "failed to add device handler: %d\n",
>> error);
>> return error;
>> }
>>
>> to scsi_sysfs_add_sdev are adding a regression.
>>
>> 1. If that fails, then we forget to do device_del before doing the
>> return. My patch in this thread added that back, so we do not see the
>> sysfs oopses anymore. But.
>>
>> 2. It looks like in older kernels, we would allow misconfigured targets
>> like this one to still setup devices. Do we want that old behavior back?
>> Should we just ignore the return value from scsi_dh_add_device above?
>> Note that in this case, it is LIO so it can be easily fixed on the
>> target side by just setting it up properly. I do not think other targets
>> would hit this type of issue.
>>
> 
> Btw, what does misconfigured mean here wrt target ALUA..?

[   25.833195] sd 6:0:0:4: alua: supports implicit and explicit TPGS
[   25.833360] sd 6:0:0:4: alua: No target port descriptors found
[   25.833363] sd 6:0:0:4: alua: Attach failed (-22)
[   25.833365] sd 6:0:0:4: failed to add device handler: -22

He has LIO configured to report it supports implicit/explicit ALUA, but
the ports do not seem to be configured.

For the LIO config side, are his LUNs just not in a the default_lu_gp or
any other group?
--
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: [Bug 111441] New: iscsi fails to attach to targets

[Mike Christie]

On 01/29/2016 02:01 AM, Michael Christie wrote:
> Can you send me your lio config?
> 

Not sure what I was thinking. Don't send me anything. Could you just try
the attached patch?
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 21930c9..4269cbc 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1061,6 +1061,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 	if (error) {
 		sdev_printk(KERN_INFO, sdev,
 "failed to add device handler: %d\n", error);
+		device_del(>sdev_gendev);
 		return error;
 	}
 

RE: [Bug 111441] New: iscsi fails to attach to targets

[Serguei Bezverkhi (sbezverk)]

ipmi_msghandler mfd_core 
auth_rpcgss acpi_power_meter wmi nfs_acl lockd br_netfilter grace sunrpc bridge 
stp llc dm_multipath ip_tables xfs libcrc32c sd_mod mgag200 drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ixgbe(O) fnic i40e 
libfcoe igb crc32c_intel megaraid_sas enic libfc vxlan ip6_udp_tunnel 
udp_tunnel ptp scsi_transport_fc i2c_algo_bit i2c_core pps_core dca dm_mirror 
dm_region_hash dm_log dm_mod
[ 1064.276682] CPU: 1 PID: 10652 Comm: iscsiadm Tainted: GW  O4.4.0 
#1
[ 1064.276683] Hardware name: Cisco Systems Inc UCSC-C240-M3S/UCSC-C240-M3S, 
BIOS C240M3.2.0.8.0.071620152208 07/16/2015
[ 1064.276684]   80e19618 882e7aa0b948 
81329090
[ 1064.276686]  882e7aa0b990 882e7aa0b980 810862c6 
882f9fed7000
[ 1064.276688]  885f9f16f2d0 885fa5329e10 0001 
ffef
[ 1064.276689] Call Trace:
[ 1064.276695]  [] dump_stack+0x44/0x64
[ 1064.276698]  [] warn_slowpath_common+0x86/0xc0
[ 1064.276700]  [] warn_slowpath_fmt+0x5c/0x80
[ 1064.276703]  [] ? kernfs_path+0x48/0x60
[ 1064.276704]  [] sysfs_warn_dup+0x64/0x80
[ 1064.276706]  [] sysfs_do_create_link_sd.isra.2+0xaa/0xb0
[ 1064.276708]  [] sysfs_create_link+0x25/0x40
[ 1064.276711]  [] bus_add_device+0x10b/0x1f0
[ 1064.276712]  [] device_add+0x3b5/0x610
[ 1064.276716]  [] scsi_sysfs_add_sdev+0xa5/0x290
[ 1064.276718]  [] scsi_probe_and_add_lun+0xb65/0xd80
[ 1064.276722]  [] ? __pm_runtime_resume+0x5c/0x70
[ 1064.276724]  [] __scsi_scan_target+0xf7/0x260
[ 1064.276725]  [] ? __pm_runtime_resume+0x5c/0x70
[ 1064.276727]  [] scsi_scan_target+0xd7/0xf0
[ 1064.276734]  [] 
iscsi_user_scan_session.part.14+0x105/0x140 [scsi_transport_iscsi]
[ 1064.276738]  [] ? 
iscsi_user_scan_session.part.14+0x140/0x140 [scsi_transport_iscsi]
[ 1064.276742]  [] iscsi_user_scan_session+0x1e/0x30 
[scsi_transport_iscsi]
[ 1064.276743]  [] device_for_each_child+0x50/0x90
[ 1064.276747]  [] iscsi_user_scan+0x3d/0x60 
[scsi_transport_iscsi]
[ 1064.276749]  [] store_scan+0xa6/0x100
[ 1064.276753]  [] ? __kmalloc+0x1b8/0x250
[ 1064.276757]  [] dev_attr_store+0x18/0x30
[ 1064.276759]  [] sysfs_kf_write+0x3a/0x50
[ 1064.276760]  [] kernfs_fop_write+0x120/0x170
[ 1064.276762]  [] __vfs_write+0x37/0x100
[ 1064.276765]  [] ? selinux_file_permission+0xc3/0x110
[ 1064.276769]  [] ? security_file_permission+0x3d/0xc0
[ 1064.276772]  [] ? percpu_down_read+0x1f/0x50
[ 1064.276773]  [] vfs_write+0xa2/0x1a0
[ 1064.276776]  [] ? do_audit_syscall_entry+0x66/0x70
[ 1064.276777]  [] SyS_write+0x55/0xc0
[ 1064.276780]  [] entry_SYSCALL_64_fastpath+0x12/0x71
[ 1064.276781] ---[ end trace bcfb1475313b5f67 ]---
[ 1064.276817] scsi 7:0:0:0: failed to add device: -17


   

Thank you

Serguei


-Original Message-
From: Michael Christie [mailto:micha...@cs.wisc.edu] 
Sent: Friday, January 29, 2016 3:02 AM
To: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>
Cc: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
Subject: Re: [Bug 111441] New: iscsi fails to attach to targets

Can you send me your lio config?

Are you running lio on the same box as the initiator so it is also changing 
kernel version with each test?

It looks like the scsi scan code is not handling the lack of LUN 0 correctly. I 
think I know what patch is causing it, but cannot get my lio config to return 
the same info as you for the non existent LUNs, so I think I am hitting 
slightly different error paths.


> On Jan 28, 2016, at 8:55 PM, Serguei Bezverkhi (sbezverk) 
> <sbezv...@cisco.com> wrote:
> 
> HI Mike,
> 
> Thank you for looking into this issue.
> I reproduced this issue  this using both mainline compiled kernel and the one 
> posted by El Repo.  I used both of these kernels with RHEL 7.2, both kernels 
> showed exactly the same issue. When I rollback to the original kernel 
> 3.10.0-327.4.4, I do not see the issue.
> 
> As per your request attaching kernel config file. Please let me know if you 
> need any additional info or if you want to take a look at the router, I can 
> setup a webex meeting to show you the issue.
> 
> Thank you
> 
> Serguei
> 
> 
> 
> 
> Serguei Bezverkhi,
> TECHNICAL LEADER.SERVICES
> Global SP Services
> sbezv...@cisco.com
> Phone: +1 416 306 7312
> Mobile: +1 514 234 7374
> 
> CCIE (R,SP,Sec) - #9527
> 
> Cisco.com
> 
> 
> 
>  Think before you print.
> This email may contain confidential and privileged material for the sole use 
> of the intended recipient. Any review, use, distribution or disclosure by 
> others is strictly prohibited. If you are not the intended recipient (or 
> authorized to receive for the recipient), please contact the sender by reply 
> email and delete all copies of this message.
> Please click here for Company Registration Information.
> 
> 
> 

Re: [Bug 111441] New: iscsi fails to attach to targets

[Michael Christie]

Can you send me your lio config?

Are you running lio on the same box as the initiator so it is also changing 
kernel version with each test?

It looks like the scsi scan code is not handling the lack of LUN 0 correctly. I 
think I know what patch is causing it, but cannot get my lio config to return 
the same info as you for the non existent LUNs, so I think I am hitting 
slightly different error paths.


> On Jan 28, 2016, at 8:55 PM, Serguei Bezverkhi (sbezverk) 
> <sbezv...@cisco.com> wrote:
> 
> HI Mike,
> 
> Thank you for looking into this issue.
> I reproduced this issue  this using both mainline compiled kernel and the one 
> posted by El Repo.  I used both of these kernels with RHEL 7.2, both kernels 
> showed exactly the same issue. When I rollback to the original kernel 
> 3.10.0-327.4.4, I do not see the issue.
> 
> As per your request attaching kernel config file. Please let me know if you 
> need any additional info or if you want to take a look at the router, I can 
> setup a webex meeting to show you the issue.
> 
> Thank you
> 
> Serguei
> 
> 
> 
> 
> Serguei Bezverkhi,
> TECHNICAL LEADER.SERVICES
> Global SP Services
> sbezv...@cisco.com
> Phone: +1 416 306 7312
> Mobile: +1 514 234 7374
> 
> CCIE (R,SP,Sec) - #9527
> 
> Cisco.com
> 
> 
> 
>  Think before you print.
> This email may contain confidential and privileged material for the sole use 
> of the intended recipient. Any review, use, distribution or disclosure by 
> others is strictly prohibited. If you are not the intended recipient (or 
> authorized to receive for the recipient), please contact the sender by reply 
> email and delete all copies of this message.
> Please click here for Company Registration Information.
> 
> 
> 
> 
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org 
> [mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Mike Christie
> Sent: Thursday, January 28, 2016 8:53 PM
> To: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
> Subject: Re: [Bug 111441] New: iscsi fails to attach to targets
> 
> On 01/28/2016 04:51 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=111441
>> 
>>Bug ID: 111441
>>   Summary: iscsi fails to attach to targets
>>   Product: IO/Storage
>>   Version: 2.5
>>Kernel Version: 4.4.0-1
>>  Hardware: x86-64
>>OS: Linux
>>  Tree: Mainline
>>Status: NEW
> 
> 
>> 4.4.0-1.el7.elrepo.x86_64 #1
> 
> I have not seen this oops before. We saw similar ones around 5 or 6 years 
> ago, but they were due to some sysfs or block or scsi issue (I cannot 
> remember exacty) and fixed there.
> 
> Is this a distro kernel or mainline. BZ says mainline, but the kernel name in 
> bug looks like a red hat related one. Where did you get it?
> 
> I do not hit this in 4.4 mainline. Send me your kernel .config, so I can make 
> sure I have the same options.
> 
> --
> 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


config-4.4.0
Description: Binary data
> 

Re: [Bug 111441] New: iscsi fails to attach to targets

[Mike Christie]

ck 2563476132, async 
> page read
> [   26.238897] Buffer I/O error on dev sdd, logical block 1220703182, async 
> page read
> [   26.245773] ixgbe :04:00.1: SR-IOV enabled with 8 VFs
> [   26.245775] ixgbe :04:00.1: configure port vlans to keep your VFs 
> secure
> [   26.274544] scsi 6:0:0:0: Unexpected response from lun 4 while scanning, 
> scan aborted
> [   26.283173] scsi 3:0:0:0: Unexpected response from lun 2 while scanning, 
> scan aborted
> [   26.288571] scsi 4:0:0:0: Unexpected response from lun 3 while scanning, 
> scan aborted
> [   26.288618] scsi 5:0:0:0: Unexpected response from lun 1 while scanning, 
> scan aborted
> 
> 
> Second traceback is gone too, but still no luck attaching local iscsi targets 
> either.
> 
> 
> [  639.148875] TARGET_CORE[iSCSI]: Expected Transfer Length: 264 does not 
> match SCSI CDB Length: 8 for SAM Opcode: 0x12
> [  639.148911] sd 7:0:0:0: [sdc] 115343360 512-byte logical blocks: (59.0 
> GB/55.0 GiB)
> [  639.148925] sd 7:0:0:0: alua: No target port descriptors found
> [  639.148928] sd 7:0:0:0: alua: Attach failed (-22)
> [  639.149186] sd 7:0:0:0: [sdc] Write Protect is off
> [  639.149188] sd 7:0:0:0: [sdc] Mode Sense: 43 00 10 08
> [  639.149279] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, 
> supports DPO and FUA
> [  639.149298] iSCSI/iqn.1994-05.com.redhat:cf7f1fafca4b: Unsupported SCSI 
> Opcode 0xa3, sending CHECK_CONDITION.
> [  639.149530] sd 7:0:0:0: failed to add device handler: -22
> [  639.154762] sd 7:0:0:0: [sdc] Attached SCSI disk
> [  639.154857] sd 7:0:0:0: [sdc] Synchronizing SCSI cache
> [  655.279047] scsi 7:0:0:0: Direct-Access LIO-ORG  IBLOCK   4.0  
> PQ: 0 ANSI: 5
> [  655.279397] sd 7:0:0:0: alua: supports implicit and explicit TPGS
> [  655.279503] TARGET_CORE[iSCSI]: Expected Transfer Length: 264 does not 
> match SCSI CDB Length: 8 for SAM Opcode: 0x12
> [  655.279533] sd 7:0:0:0: alua: No target port descriptors found
> [  655.279535] sd 7:0:0:0: alua: Attach failed (-22)
> [  655.279587] sd 7:0:0:0: [sdc] 115343360 512-byte logical blocks: (59.0 
> GB/55.0 GiB)
> [  655.279848] sd 7:0:0:0: [sdc] Write Protect is off
> [  655.279849] sd 7:0:0:0: [sdc] Mode Sense: 43 00 10 08
> [  655.279981] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, 
> supports DPO and FUA
> [  655.280034] iSCSI/iqn.1994-05.com.redhat:cf7f1fafca4b: Unsupported SCSI 
> Opcode 0xa3, sending CHECK_CONDITION.
> [  655.280171] sd 7:0:0:0: failed to add device handler: -22
> [  655.286008] sd 7:0:0:0: [sdc] Attached SCSI disk
> [  655.286132] sd 7:0:0:0: [sdc] Synchronizing SCSI cache
> 
> 
> Serguei Bezverkhi,
> TECHNICAL LEADER.SERVICES
> Global SP Services
> sbezv...@cisco.com
> Phone: +1 416 306 7312
> Mobile: +1 514 234 7374
> 
> CCIE (R,SP,Sec) - #9527
> 
> Cisco.com
> 
> 
> 
>  Think before you print.
> This email may contain confidential and privileged material for the sole use 
> of the intended recipient. Any review, use, distribution or disclosure by 
> others is strictly prohibited. If you are not the intended recipient (or 
> authorized to receive for the recipient), please contact the sender by reply 
> email and delete all copies of this message.
> Please click here for Company Registration Information.
> 
> 
> 
> 
> -Original Message-
> From: Mike Christie [mailto:micha...@cs.wisc.edu] 
> Sent: Friday, January 29, 2016 2:27 PM
> To: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>
> Cc: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
> Subject: Re: [Bug 111441] New: iscsi fails to attach to targets
> 
> 
> 
> On 01/29/2016 01:11 PM, Serguei Bezverkhi (sbezverk) wrote:
>> If you send me the diff for your patch, I will build new kernel myself.
>>
> 
> Bugzilla must be messing something up. I attached to one of the previous 
> mails. Attaching it here again.
> 
> Email me offlist and without bugzilla if you do not get it here.
> 
> The patch will fix the syfs bug ons you are hitting.
> 
> I am not sure if it will fix the genhd one. We can deal with that one next if 
> it is a different issue.
> 
> 
>> Serguei
>>
>>
>> Serguei Bezverkhi,
>> TECHNICAL LEADER.SERVICES
>> Global SP Services
>> sbezv...@cisco.com
>> Phone: +1 416 306 7312
>> Mobile: +1 514 234 7374
>>
>> CCIE (R,SP,Sec) - #9527
>>
>> Cisco.com
>>
>>
>>
>>  Think before you print.
>> This email may contain confidential and privileged material for the sole use 
>> of the intended recipient. Any review, use, distribution or disclosure by 
>> others is strictly prohibited. I

RE: [Bug 111441] New: iscsi fails to attach to targets

[Serguei Bezverkhi (sbezverk)]

 LIO-ORG  IBLOCK   4.0  
PQ: 0 ANSI: 5
[  655.279397] sd 7:0:0:0: alua: supports implicit and explicit TPGS
[  655.279503] TARGET_CORE[iSCSI]: Expected Transfer Length: 264 does not match 
SCSI CDB Length: 8 for SAM Opcode: 0x12
[  655.279533] sd 7:0:0:0: alua: No target port descriptors found
[  655.279535] sd 7:0:0:0: alua: Attach failed (-22)
[  655.279587] sd 7:0:0:0: [sdc] 115343360 512-byte logical blocks: (59.0 
GB/55.0 GiB)
[  655.279848] sd 7:0:0:0: [sdc] Write Protect is off
[  655.279849] sd 7:0:0:0: [sdc] Mode Sense: 43 00 10 08
[  655.279981] sd 7:0:0:0: [sdc] Write cache: enabled, read cache: enabled, 
supports DPO and FUA
[  655.280034] iSCSI/iqn.1994-05.com.redhat:cf7f1fafca4b: Unsupported SCSI 
Opcode 0xa3, sending CHECK_CONDITION.
[  655.280171] sd 7:0:0:0: failed to add device handler: -22
[  655.286008] sd 7:0:0:0: [sdc] Attached SCSI disk
[  655.286132] sd 7:0:0:0: [sdc] Synchronizing SCSI cache


Serguei Bezverkhi,
TECHNICAL LEADER.SERVICES
Global SP Services
sbezv...@cisco.com
Phone: +1 416 306 7312
Mobile: +1 514 234 7374

CCIE (R,SP,Sec) - #9527

Cisco.com



 Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click here for Company Registration Information.




-Original Message-
From: Mike Christie [mailto:micha...@cs.wisc.edu] 
Sent: Friday, January 29, 2016 2:27 PM
To: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>
Cc: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
Subject: Re: [Bug 111441] New: iscsi fails to attach to targets



On 01/29/2016 01:11 PM, Serguei Bezverkhi (sbezverk) wrote:
> If you send me the diff for your patch, I will build new kernel myself.
> 

Bugzilla must be messing something up. I attached to one of the previous mails. 
Attaching it here again.

Email me offlist and without bugzilla if you do not get it here.

The patch will fix the syfs bug ons you are hitting.

I am not sure if it will fix the genhd one. We can deal with that one next if 
it is a different issue.


> Serguei
> 
> 
> Serguei Bezverkhi,
> TECHNICAL LEADER.SERVICES
> Global SP Services
> sbezv...@cisco.com
> Phone: +1 416 306 7312
> Mobile: +1 514 234 7374
> 
> CCIE (R,SP,Sec) - #9527
> 
> Cisco.com
> 
> 
> 
>  Think before you print.
> This email may contain confidential and privileged material for the sole use 
> of the intended recipient. Any review, use, distribution or disclosure by 
> others is strictly prohibited. If you are not the intended recipient (or 
> authorized to receive for the recipient), please contact the sender by reply 
> email and delete all copies of this message.
> Please click here for Company Registration Information.
> 
> 
> 
> 
> -Original Message-
> From: Michael Christie [mailto:micha...@cs.wisc.edu]
> Sent: Friday, January 29, 2016 2:09 PM
> To: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>
> Cc: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
> Subject: Re: [Bug 111441] New: iscsi fails to attach to targets
> 
> 
>> On Jan 29, 2016, at 6:04 AM, Serguei Bezverkhi (sbezverk) 
>> <sbezv...@cisco.com> wrote:
>>
>> Actually this server uses both cases: Local taregts (since it is OpenStack 
>> server) and remote targets as it tries to mount 4 remotefile systems.  
>>
>> You are correct, I always use the same box I just change the kernel it is 
>> using to boot. No other changes to the environment. I do not mind to load a 
>> test kernel without that suspected patch, just get me the RPM.
>>
> 
> I do not know what you mean. I think the patch I sent will fix the sysfs 
> errors caused due to alua not being setup properly on your system and 
> scsi_dh_alua failing to attach. That patch should be applied to the 4.4 
> upstream kernel. Are you saying you want me to make you a kernel rpm?
> --
> 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
> 

--
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: [Bug 111441] New: iscsi fails to attach to targets

[Nicholas A. Bellinger]

On Fri, 2016-01-29 at 17:32 -0600, Mike Christie wrote:
> On 01/29/2016 04:21 PM, Serguei Bezverkhi (sbezverk) wrote:
> > HI Mike,
> > 
> > I tried your patch and it is has eliminated first traceback but I still do 
> > not see my remote targets.
> > 
> 
> That is sort of expected. Your target is not setup for ALUA properly. It
> says it supports ALUA, but when scsi_dh_alua asks about the ports it is
> reporting there are none. Ccing the people that made the patch that
> added the issue and own the code.
> 
> Hey Christoph and Hannes,
> 
> The dh/alua changes that added this:
> 
> error = scsi_dh_add_device(sdev);
> if (error) {
> sdev_printk(KERN_INFO, sdev,
> "failed to add device handler: %d\n",
> error);
> return error;
> }
> 
> to scsi_sysfs_add_sdev are adding a regression.
> 
> 1. If that fails, then we forget to do device_del before doing the
> return. My patch in this thread added that back, so we do not see the
> sysfs oopses anymore. But.
> 
> 2. It looks like in older kernels, we would allow misconfigured targets
> like this one to still setup devices. Do we want that old behavior back?
> Should we just ignore the return value from scsi_dh_add_device above?
> Note that in this case, it is LIO so it can be easily fixed on the
> target side by just setting it up properly. I do not think other targets
> would hit this type of issue.
> 

Btw, what does misconfigured mean here wrt target ALUA..?

--
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: [Bug 111441] New: iscsi fails to attach to targets

[Serguei Bezverkhi (sbezverk)]

If you send me the diff for your patch, I will build new kernel myself.

Serguei


Serguei Bezverkhi,
TECHNICAL LEADER.SERVICES
Global SP Services
sbezv...@cisco.com
Phone: +1 416 306 7312
Mobile: +1 514 234 7374

CCIE (R,SP,Sec) - #9527

Cisco.com



 Think before you print.
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Please click here for Company Registration Information.




-Original Message-
From: Michael Christie [mailto:micha...@cs.wisc.edu] 
Sent: Friday, January 29, 2016 2:09 PM
To: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>
Cc: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
Subject: Re: [Bug 111441] New: iscsi fails to attach to targets


> On Jan 29, 2016, at 6:04 AM, Serguei Bezverkhi (sbezverk) 
> <sbezv...@cisco.com> wrote:
> 
> Actually this server uses both cases: Local taregts (since it is OpenStack 
> server) and remote targets as it tries to mount 4 remotefile systems.  
> 
> You are correct, I always use the same box I just change the kernel it is 
> using to boot. No other changes to the environment. I do not mind to load a 
> test kernel without that suspected patch, just get me the RPM.
> 

I do not know what you mean. I think the patch I sent will fix the sysfs errors 
caused due to alua not being setup properly on your system and scsi_dh_alua 
failing to attach. That patch should be applied to the 4.4 upstream kernel. Are 
you saying you want me to make you a kernel rpm?
--
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: [Bug 111441] New: iscsi fails to attach to targets

[Michael Christie]

> On Jan 29, 2016, at 6:04 AM, Serguei Bezverkhi (sbezverk) 
>  wrote:
> 
> Actually this server uses both cases: Local taregts (since it is OpenStack 
> server) and remote targets as it tries to mount 4 remotefile systems.  
> 
> You are correct, I always use the same box I just change the kernel it is 
> using to boot. No other changes to the environment. I do not mind to load a 
> test kernel without that suspected patch, just get me the RPM.
> 

I do not know what you mean. I think the patch I sent will fix the sysfs errors 
caused due to alua not being setup properly on your system and scsi_dh_alua 
failing to attach. That patch should be applied to the 4.4 upstream kernel. Are 
you saying you want me to make you a kernel rpm?--
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: [Bug 111441] New: iscsi fails to attach to targets

[Mike Christie]

On 01/29/2016 01:11 PM, Serguei Bezverkhi (sbezverk) wrote:
> If you send me the diff for your patch, I will build new kernel myself.
> 

Bugzilla must be messing something up. I attached to one of the previous
mails. Attaching it here again.

Email me offlist and without bugzilla if you do not get it here.

The patch will fix the syfs bug ons you are hitting.

I am not sure if it will fix the genhd one. We can deal with that one
next if it is a different issue.


> Serguei
> 
> 
> Serguei Bezverkhi,
> TECHNICAL LEADER.SERVICES
> Global SP Services
> sbezv...@cisco.com
> Phone: +1 416 306 7312
> Mobile: +1 514 234 7374
> 
> CCIE (R,SP,Sec) - #9527
> 
> Cisco.com
> 
> 
> 
>  Think before you print.
> This email may contain confidential and privileged material for the sole use 
> of the intended recipient. Any review, use, distribution or disclosure by 
> others is strictly prohibited. If you are not the intended recipient (or 
> authorized to receive for the recipient), please contact the sender by reply 
> email and delete all copies of this message.
> Please click here for Company Registration Information.
> 
> 
> 
> 
> -Original Message-
> From: Michael Christie [mailto:micha...@cs.wisc.edu] 
> Sent: Friday, January 29, 2016 2:09 PM
> To: Serguei Bezverkhi (sbezverk) <sbezv...@cisco.com>
> Cc: bugzilla-dae...@bugzilla.kernel.org; linux-scsi@vger.kernel.org
> Subject: Re: [Bug 111441] New: iscsi fails to attach to targets
> 
> 
>> On Jan 29, 2016, at 6:04 AM, Serguei Bezverkhi (sbezverk) 
>> <sbezv...@cisco.com> wrote:
>>
>> Actually this server uses both cases: Local taregts (since it is OpenStack 
>> server) and remote targets as it tries to mount 4 remotefile systems.  
>>
>> You are correct, I always use the same box I just change the kernel it is 
>> using to boot. No other changes to the environment. I do not mind to load a 
>> test kernel without that suspected patch, just get me the RPM.
>>
> 
> I do not know what you mean. I think the patch I sent will fix the sysfs 
> errors caused due to alua not being setup properly on your system and 
> scsi_dh_alua failing to attach. That patch should be applied to the 4.4 
> upstream kernel. Are you saying you want me to make you a kernel rpm?
> --
> 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
> 

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 21930c9..4269cbc 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1061,6 +1061,7 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
 	if (error) {
 		sdev_printk(KERN_INFO, sdev,
 "failed to add device handler: %d\n", error);
+		device_del(>sdev_gendev);
 		return error;
 	}
 

[Bug 111441] New: iscsi fails to attach to targets

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=111441

Bug ID: 111441
   Summary: iscsi fails to attach to targets
   Product: IO/Storage
   Version: 2.5
Kernel Version: 4.4.0-1
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: SCSI
  Assignee: linux-scsi@vger.kernel.org
  Reporter: sbezv...@cisco.com
Regression: No

The issue is whenever iscsi tries to attach remote iscsi target, there is this
traceback generated in dmesg buffer and it fails to attach.  Here is the
traceback and it is 100% reproducible. I would appreciate if you let me know if
it is a known issue and if there is a patch to address it.

[ 4693.175319] WARNING: CPU: 27 PID: 17353 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x64/0x80()
[ 4693.175320] sysfs: cannot create duplicate filename
'/bus/scsi/devices/8:0:0:0'
[ 4693.175321] Modules linked in: target_core_user target_core_pscsi
target_core_file target_core_iblock binfmt_misc xt_REDIRECT nf_nat_redirect
xt_nat xt_mark xt_conntrack xt_CHECKSUM iptable_raw ebtable_filter ebtables
ip6table_filter ip6_tables iscsi_tcp libiscsi_tcp bnx2fc cnic uio fcoe 8021q
garp mrp openvswitch nf_defrag_ipv6 bonding rpcrdma ib_isert iscsi_target_mod
ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp
scsi_transport_srp ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm
iw_cm ib_sa ib_mad usnic_verbs ib_core ib_addr xt_comment xt_multiport
iptable_filter iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat
nf_conntrack iptable_mangle x86_pkg_temp_thermal intel_powerclamp coretemp
kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul aesni_intel
[ 4693.175362]  lrw gf128mul glue_helper ablk_helper cryptd ipmi_devintf ses
enclosure sg ipmi_si 8250_fintek ipmi_msghandler joydev input_leds sb_edac
iTCO_wdt iTCO_vendor_support pcspkr shpchp lpc_ich edac_core mfd_core wmi
acpi_power_meter nfsd auth_rpcgss nfs_acl lockd grace sunrpc dm_multipath
ip_tables xfs libcrc32c sd_mod crc32c_intel mgag200 megaraid_sas drm_kms_helper
syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm libfcoe libfc
scsi_transport_fc enic ixgbe(O) i40e vxlan ip6_udp_tunnel igb udp_tunnel ptp
pps_core dca i2c_algo_bit fjes dm_mirror dm_region_hash dm_log dm_mod [last
unloaded: fnic]
[ 4693.175391] CPU: 27 PID: 17353 Comm: iscsiadm Tainted: GW  O   
4.4.0-1.el7.elrepo.x86_64 #1
[ 4693.175392] Hardware name: Cisco Systems Inc UCSC-C240-M3S/UCSC-C240-M3S,
BIOS C240M3.2.0.8.0.071620152208 07/16/2015
[ 4693.175393]   e6fae80d 885cff49b948
813273f0
[ 4693.175395]  885cff49b990 885cff49b980 8107c816
882c2b7e5000
[ 4693.175396]  882fa36885d0 885fa53b8d98 0001
ffef
[ 4693.175398] Call Trace:
[ 4693.175402]  [] dump_stack+0x44/0x64
[ 4693.175405]  [] warn_slowpath_common+0x86/0xc0
[ 4693.175407]  [] warn_slowpath_fmt+0x5c/0x80
[ 4693.175409]  [] ? kernfs_path+0x48/0x60
[ 4693.175410]  [] sysfs_warn_dup+0x64/0x80
[ 4693.175412]  [] sysfs_do_create_link_sd.isra.2+0xaa/0xb0
[ 4693.175414]  [] sysfs_create_link+0x25/0x40
[ 4693.175417]  [] bus_add_device+0x10b/0x1f0
[ 4693.175419]  [] device_add+0x3b5/0x610
[ 4693.175422]  [] scsi_sysfs_add_sdev+0xa5/0x290
[ 4693.175424]  [] scsi_probe_and_add_lun+0xb65/0xd80
[ 4693.175427]  [] ? __pm_runtime_resume+0x5c/0x70
[ 4693.175429]  [] __scsi_scan_target+0xf7/0x260
[ 4693.175430]  [] ? __pm_runtime_resume+0x5c/0x70
[ 4693.175432]  [] scsi_scan_target+0xd7/0xf0
[ 4693.175440]  []
iscsi_user_scan_session.part.14+0x105/0x140 [scsi_transport_iscsi]
[ 4693.175443]  [] ?
iscsi_user_scan_session.part.14+0x140/0x140 [scsi_transport_iscsi]
[ 4693.175446]  [] iscsi_user_scan_session+0x1e/0x30
[scsi_transport_iscsi]
[ 4693.175448]  [] device_for_each_child+0x50/0x90
[ 4693.175451]  [] iscsi_user_scan+0x3d/0x60
[scsi_transport_iscsi]
[ 4693.175453]  [] store_scan+0xa6/0x100
[ 4693.175456]  [] ? __kmalloc+0x1b8/0x250
[ 4693.175458]  [] dev_attr_store+0x18/0x30
[ 4693.175459]  [] sysfs_kf_write+0x3a/0x50
[ 4693.175461]  [] kernfs_fop_write+0x120/0x170
[ 4693.175464]  [] __vfs_write+0x37/0x100
[ 4693.175467]  [] ? selinux_file_permission+0xc3/0x110
[ 4693.175469]  [] ? security_file_permission+0x3d/0xc0
[ 4693.175485]  [] ? percpu_down_read+0x1f/0x50
[ 4693.175486]  [] vfs_write+0xa2/0x1a0
[ 4693.175489]  [] ? do_audit_syscall_entry+0x66/0x70
[ 4693.175491]  [] SyS_write+0x55/0xc0
[ 4693.175493]  [] entry_SYSCALL_64_fastpath+0x12/0x71
[ 4693.175495] ---[ end trace 67e92c68518cd764 ]---
[ 4693.175516] scsi 8:0:0:0: failed to add device: -17
[ 4702.252060] scsi 8:0:0:0: Direct-Access LIO-ORG  IBLOCK   4.0 
PQ: 0 ANSI: 5
[ 4702.252482] [ cut here ]
[ 4702.252488] WARNING: CPU: 2 PID: 17390 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x64/0x80()
[ 4702.252489] sysfs: cannot create duplicate filename

Re: [Bug 111441] New: iscsi fails to attach to targets

[Mike Christie]

On 01/28/2016 04:51 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=111441
> 
> Bug ID: 111441
>Summary: iscsi fails to attach to targets
>Product: IO/Storage
>Version: 2.5
> Kernel Version: 4.4.0-1
>   Hardware: x86-64
> OS: Linux
>   Tree: Mainline
> Status: NEW


> 4.4.0-1.el7.elrepo.x86_64 #1

I have not seen this oops before. We saw similar ones around 5 or 6
years ago, but they were due to some sysfs or block or scsi issue (I
cannot remember exacty) and fixed there.

Is this a distro kernel or mainline. BZ says mainline, but the kernel
name in bug looks like a red hat related one. Where did you get it?

I do not hit this in 4.4 mainline. Send me your kernel .config, so I can
make sure I have the same options.

--
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: [Bug 111441] New: iscsi fails to attach to targets

[Mike Christie]

I thought you could just reply to kernel bugzilla mails and it would
automatically add your reply to the bz, but I got some errors. Ccing the
bug reporter here, so I do not have to make an account and go through bz.

Serguei see below. I need some extra info.

On 01/28/2016 07:53 PM, Mike Christie wrote:
> On 01/28/2016 04:51 PM, bugzilla-dae...@bugzilla.kernel.org wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=111441
>>
>> Bug ID: 111441
>>Summary: iscsi fails to attach to targets
>>Product: IO/Storage
>>Version: 2.5
>> Kernel Version: 4.4.0-1
>>   Hardware: x86-64
>> OS: Linux
>>   Tree: Mainline
>> Status: NEW
> 
> 
>> 4.4.0-1.el7.elrepo.x86_64 #1
> 
> I have not seen this oops before. We saw similar ones around 5 or 6
> years ago, but they were due to some sysfs or block or scsi issue (I
> cannot remember exacty) and fixed there.
> 
> Is this a distro kernel or mainline. BZ says mainline, but the kernel
> name in bug looks like a red hat related one. Where did you get it?
> 
> I do not hit this in 4.4 mainline. Send me your kernel .config, so I can
> make sure I have the same options.
> 
> --
> 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
> 

--
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