2013-08-01 10:01:37

by Jan Vesely

[permalink] [raw]
Subject: [PATCH 0/2] mpt{2,3}sas remove disconnected phys on topology change

From: Jan Vesely <[email protected]>

These two patches add phy removal on link loss. This change keeps sysfs
up-to-date with actually connected phys. Without these patches,
disconnected phys remain listed under their former ports.

tested on both mpt2sas and mpt3sas hw.

CC: Nagalakshmi Nandigama <[email protected]>
CC: Sreekanth Reddy <[email protected]>
CC: Tomas Henzl <[email protected]>
Signed-off-by: Jan Vesely <[email protected]>

Jan Vesely (2):
mpt2sas: Remove phys on topology change.
mpt3sas: Remove phys on topology change

drivers/scsi/mpt2sas/mpt2sas_transport.c | 5 ++++-
drivers/scsi/mpt3sas/mpt3sas_transport.c | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)


2013-08-01 10:01:40

by Jan Vesely

[permalink] [raw]
Subject: [PATCH 1/2] mpt2sas: Remove phys on topology change.

From: Jan Vesely <[email protected]>

CC: Nagalakshmi Nandigama <[email protected]>
CC: Sreekanth Reddy <[email protected]>
CC: Tomas Henzl <[email protected]>
Signed-off-by: Jan Vesely <[email protected]>
---
drivers/scsi/mpt2sas/mpt2sas_transport.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/mpt2sas/mpt2sas_transport.c b/drivers/scsi/mpt2sas/mpt2sas_transport.c
index 193e7ae..e610a97 100644
--- a/drivers/scsi/mpt2sas/mpt2sas_transport.c
+++ b/drivers/scsi/mpt2sas/mpt2sas_transport.c
@@ -1006,9 +1006,12 @@ mpt2sas_transport_update_links(struct MPT2SAS_ADAPTER *ioc,
&mpt2sas_phy->remote_identify);
_transport_add_phy_to_an_existing_port(ioc, sas_node,
mpt2sas_phy, mpt2sas_phy->remote_identify.sas_address);
- } else
+ } else {
memset(&mpt2sas_phy->remote_identify, 0 , sizeof(struct
sas_identify));
+ _transport_del_phy_from_an_existing_port(ioc, sas_node,
+ mpt2sas_phy);
+ }

if (mpt2sas_phy->phy)
mpt2sas_phy->phy->negotiated_linkrate =
--
1.7.1

2013-08-01 10:01:44

by Jan Vesely

[permalink] [raw]
Subject: [PATCH 2/2] mpt3sas: Remove phys on topology change

From: Jan Vesely <[email protected]>

CC: Nagalakshmi Nandigama <[email protected]>
CC: Sreekanth Reddy <[email protected]>
CC: Tomas Henzl <[email protected]>
Signed-off-by: Jan Vesely <[email protected]>
---
drivers/scsi/mpt3sas/mpt3sas_transport.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c b/drivers/scsi/mpt3sas/mpt3sas_transport.c
index 87ca2b7..45bc98e 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_transport.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_transport.c
@@ -1003,9 +1003,12 @@ mpt3sas_transport_update_links(struct MPT3SAS_ADAPTER *ioc,
&mpt3sas_phy->remote_identify);
_transport_add_phy_to_an_existing_port(ioc, sas_node,
mpt3sas_phy, mpt3sas_phy->remote_identify.sas_address);
- } else
+ } else {
memset(&mpt3sas_phy->remote_identify, 0 , sizeof(struct
sas_identify));
+ _transport_del_phy_from_an_existing_port(ioc, sas_node,
+ mpt3sas_phy);
+ }

if (mpt3sas_phy->phy)
mpt3sas_phy->phy->negotiated_linkrate =
--
1.7.1

2013-08-26 10:23:36

by Reddy, Sreekanth

[permalink] [raw]
Subject: RE: [PATCH 0/2] mpt{2,3}sas remove disconnected phys on topology change

Hi James,

This patch set seem to be fine. Please consider this patch set.

Regards,
Sreekanth

>-----Original Message-----
>From: Jan Vesely [mailto:[email protected]]
>Sent: Thursday, August 01, 2013 3:31 PM
>To: [email protected]; [email protected]
>Cc: Jan Vesely; Nandigama, Nagalakshmi; Reddy, Sreekanth; Tomas Henzl
>Subject: [PATCH 0/2] mpt{2,3}sas remove disconnected phys on topology
>change
>
>From: Jan Vesely <[email protected]>
>
>These two patches add phy removal on link loss. This change keeps sysfs up-
>to-date with actually connected phys. Without these patches, disconnected
>phys remain listed under their former ports.
>
>tested on both mpt2sas and mpt3sas hw.
>
>CC: Nagalakshmi Nandigama <[email protected]>
>CC: Sreekanth Reddy <[email protected]>
>CC: Tomas Henzl <[email protected]>
>Signed-off-by: Jan Vesely <[email protected]>
>
>Jan Vesely (2):
> mpt2sas: Remove phys on topology change.
> mpt3sas: Remove phys on topology change
>
> drivers/scsi/mpt2sas/mpt2sas_transport.c | 5 ++++-
> drivers/scsi/mpt3sas/mpt3sas_transport.c | 5 ++++-
> 2 files changed, 8 insertions(+), 2 deletions(-)
>

2014-12-02 13:18:24

by Sreekanth Reddy

[permalink] [raw]
Subject: RE: [PATCH 0/2] mpt{2,3}sas remove disconnected phys on topology change

Hi James/Chris

We are observing below issue due to this patch set code changes

Issue Description:
Drives connected Enclosure/Expander won't be visible to the OS if any
one remove and add expander cable with in DMD (Device Missing Delay) time
period (also if any power-off and power-on the Enclosure with in the DMD
period).

i.e.
Due to this code changes; driver will unregister the Enclosure port or
target PHY with SCSI transport layer, whenever driver receives "SAS
TOPOLOGY CHANGE LIST EVENT" with reason code set to "PHY link status
change" and phy link rate is Zero. Firmware usually send this type of "SAS
TOPOLOGY CHANGE LIST EVENT" event whenever drive is missing. but still
here DMD timer has not yet expired so normally driver should not
unregister the target with the SCSI transport layer instead it will move
the state of the drive to blocked state (so it won't receive any IOs from
SML for this drive).

Normally, Driver should only unregister the target with SCSI transport
layer only when driver receives "SAS TOPOLOGY CHANGE LIST EVENT" with
reason code set to "Target Remove". Firmware will send this event when the
DMD timer expires for the missing drive. If drive comes back with in the
DMD period then firmware won't send this target remove event and so driver
won't unregister the target drive with the SCSI transport layer. Driver
will just unblock the target drive to start IOs to this drive.

So, can you please revert this patch set changes back in the latest
upstream kernel and if possible on stable kernels.
I checked with the Redhat team and there are fine to revert back these
patch set changes.

Regards,
Sreekanth

>-----Original Message-----
>From: Jan Vesely [mailto:[email protected]]
>Sent: Thursday, August 01, 2013 3:31 PM
>To: [email protected]; [email protected]
>Cc: Jan Vesely; Nandigama, Nagalakshmi; Reddy, Sreekanth; Tomas Henzl
>Subject: [PATCH 0/2] mpt{2,3}sas remove disconnected phys on topology
>change
>
>From: Jan Vesely <[email protected]>
>
>These two patches add phy removal on link loss. This change keeps sysfs
>up- to-date with actually connected phys. Without these patches,
>disconnected phys remain listed under their former ports.
>
>tested on both mpt2sas and mpt3sas hw.
>
>CC: Nagalakshmi Nandigama <[email protected]>
>CC: Sreekanth Reddy <[email protected]>
>CC: Tomas Henzl <[email protected]>
>Signed-off-by: Jan Vesely <[email protected]>
>
>Jan Vesely (2):
> mpt2sas: Remove phys on topology change.
> mpt3sas: Remove phys on topology change
>
> drivers/scsi/mpt2sas/mpt2sas_transport.c | 5 ++++-
> drivers/scsi/mpt3sas/mpt3sas_transport.c | 5 ++++-
> 2 files changed, 8 insertions(+), 2 deletions(-)
>

2014-12-02 14:07:47

by Tomas Henzl

[permalink] [raw]
Subject: Re: [PATCH 0/2] mpt{2,3}sas remove disconnected phys on topology change

Hi Sreekanth,

I think this should be handled as any other change with an usual
patch sent to the list, 'git revert 3520f9c779' and 'git revert 963ba22b90'
will create the patches for you.

Cheers,
Tomas

On 12/02/2014 02:18 PM, Sreekanth Reddy wrote:
> Hi James/Chris
>
> We are observing below issue due to this patch set code changes
>
> Issue Description:
> Drives connected Enclosure/Expander won't be visible to the OS if any
> one remove and add expander cable with in DMD (Device Missing Delay) time
> period (also if any power-off and power-on the Enclosure with in the DMD
> period).
>
> i.e.
> Due to this code changes; driver will unregister the Enclosure port or
> target PHY with SCSI transport layer, whenever driver receives "SAS
> TOPOLOGY CHANGE LIST EVENT" with reason code set to "PHY link status
> change" and phy link rate is Zero. Firmware usually send this type of "SAS
> TOPOLOGY CHANGE LIST EVENT" event whenever drive is missing. but still
> here DMD timer has not yet expired so normally driver should not
> unregister the target with the SCSI transport layer instead it will move
> the state of the drive to blocked state (so it won't receive any IOs from
> SML for this drive).
>
> Normally, Driver should only unregister the target with SCSI transport
> layer only when driver receives "SAS TOPOLOGY CHANGE LIST EVENT" with
> reason code set to "Target Remove". Firmware will send this event when the
> DMD timer expires for the missing drive. If drive comes back with in the
> DMD period then firmware won't send this target remove event and so driver
> won't unregister the target drive with the SCSI transport layer. Driver
> will just unblock the target drive to start IOs to this drive.
>
> So, can you please revert this patch set changes back in the latest
> upstream kernel and if possible on stable kernels.
> I checked with the Redhat team and there are fine to revert back these
> patch set changes.
>
> Regards,
> Sreekanth
>
>> -----Original Message-----
>> From: Jan Vesely [mailto:[email protected]]
>> Sent: Thursday, August 01, 2013 3:31 PM
>> To: [email protected]; [email protected]
>> Cc: Jan Vesely; Nandigama, Nagalakshmi; Reddy, Sreekanth; Tomas Henzl
>> Subject: [PATCH 0/2] mpt{2,3}sas remove disconnected phys on topology
>> change
>>
>> From: Jan Vesely <[email protected]>
>>
>> These two patches add phy removal on link loss. This change keeps sysfs
>> up- to-date with actually connected phys. Without these patches,
>> disconnected phys remain listed under their former ports.
>>
>> tested on both mpt2sas and mpt3sas hw.
>>
>> CC: Nagalakshmi Nandigama <[email protected]>
>> CC: Sreekanth Reddy <[email protected]>
>> CC: Tomas Henzl <[email protected]>
>> Signed-off-by: Jan Vesely <[email protected]>
>>
>> Jan Vesely (2):
>> mpt2sas: Remove phys on topology change.
>> mpt3sas: Remove phys on topology change
>>
>> drivers/scsi/mpt2sas/mpt2sas_transport.c | 5 ++++-
>> drivers/scsi/mpt3sas/mpt3sas_transport.c | 5 ++++-
>> 2 files changed, 8 insertions(+), 2 deletions(-)
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html

2014-12-02 14:14:42

by Sreekanth Reddy

[permalink] [raw]
Subject: Re: [PATCH 0/2] mpt{2,3}sas remove disconnected phys on topology change

Ok. Thanks Tomas, I will follow the same and will send the revert
patch to Upstream.

Thanks,
Sreekanth.

On Tue, Dec 2, 2014 at 7:37 PM, Tomas Henzl <[email protected]> wrote:
> Hi Sreekanth,
>
> I think this should be handled as any other change with an usual
> patch sent to the list, 'git revert 3520f9c779' and 'git revert 963ba22b90'
> will create the patches for you.
>
> Cheers,
> Tomas
>
> On 12/02/2014 02:18 PM, Sreekanth Reddy wrote:
>> Hi James/Chris
>>
>> We are observing below issue due to this patch set code changes
>>
>> Issue Description:
>> Drives connected Enclosure/Expander won't be visible to the OS if any
>> one remove and add expander cable with in DMD (Device Missing Delay) time
>> period (also if any power-off and power-on the Enclosure with in the DMD
>> period).
>>
>> i.e.
>> Due to this code changes; driver will unregister the Enclosure port or
>> target PHY with SCSI transport layer, whenever driver receives "SAS
>> TOPOLOGY CHANGE LIST EVENT" with reason code set to "PHY link status
>> change" and phy link rate is Zero. Firmware usually send this type of "SAS
>> TOPOLOGY CHANGE LIST EVENT" event whenever drive is missing. but still
>> here DMD timer has not yet expired so normally driver should not
>> unregister the target with the SCSI transport layer instead it will move
>> the state of the drive to blocked state (so it won't receive any IOs from
>> SML for this drive).
>>
>> Normally, Driver should only unregister the target with SCSI transport
>> layer only when driver receives "SAS TOPOLOGY CHANGE LIST EVENT" with
>> reason code set to "Target Remove". Firmware will send this event when the
>> DMD timer expires for the missing drive. If drive comes back with in the
>> DMD period then firmware won't send this target remove event and so driver
>> won't unregister the target drive with the SCSI transport layer. Driver
>> will just unblock the target drive to start IOs to this drive.
>>
>> So, can you please revert this patch set changes back in the latest
>> upstream kernel and if possible on stable kernels.
>> I checked with the Redhat team and there are fine to revert back these
>> patch set changes.
>>
>> Regards,
>> Sreekanth
>>
>>> -----Original Message-----
>>> From: Jan Vesely [mailto:[email protected]]
>>> Sent: Thursday, August 01, 2013 3:31 PM
>>> To: [email protected]; [email protected]
>>> Cc: Jan Vesely; Nandigama, Nagalakshmi; Reddy, Sreekanth; Tomas Henzl
>>> Subject: [PATCH 0/2] mpt{2,3}sas remove disconnected phys on topology
>>> change
>>>
>>> From: Jan Vesely <[email protected]>
>>>
>>> These two patches add phy removal on link loss. This change keeps sysfs
>>> up- to-date with actually connected phys. Without these patches,
>>> disconnected phys remain listed under their former ports.
>>>
>>> tested on both mpt2sas and mpt3sas hw.
>>>
>>> CC: Nagalakshmi Nandigama <[email protected]>
>>> CC: Sreekanth Reddy <[email protected]>
>>> CC: Tomas Henzl <[email protected]>
>>> Signed-off-by: Jan Vesely <[email protected]>
>>>
>>> Jan Vesely (2):
>>> mpt2sas: Remove phys on topology change.
>>> mpt3sas: Remove phys on topology change
>>>
>>> drivers/scsi/mpt2sas/mpt2sas_transport.c | 5 ++++-
>>> drivers/scsi/mpt3sas/mpt3sas_transport.c | 5 ++++-
>>> 2 files changed, 8 insertions(+), 2 deletions(-)
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>

2014-12-03 09:28:24

by Christoph Hellwig

[permalink] [raw]
Subject: Re: [PATCH 0/2] mpt{2,3}sas remove disconnected phys on topology change

On Tue, Dec 02, 2014 at 03:07:14PM +0100, Tomas Henzl wrote:
> Hi Sreekanth,
>
> I think this should be handled as any other change with an usual
> patch sent to the list, 'git revert 3520f9c779' and 'git revert 963ba22b90'
> will create the patches for you.

Exactly. And now I'll need a review for them..