From: Jason Yan <yanaijie@huawei.com>
To: John Garry <john.garry@huawei.com>,
martin.petersen@oracle.com, jejb@linux.vnet.ibm.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
zhaohongjiang@huawei.com, hare@suse.com,
dan.j.williams@intel.com, jthumshirn@suse.de, hch@lst.de,
huangdaode@hisilicon.com, chenxiang66@hisilicon.com,
xiexiuqi@huawei.com, tj@kernel.org, miaoxie@huawei.com,
Xiaofei Tan <tanxiaofei@huawei.com>,
Ewan Milne <emilne@redhat.com>, Tomas Henzl <thenzl@redhat.com>
Subject: Re: [PATCH v2 6/7] scsi: libsas: reset the phy address if discover failed
Date: Thu, 31 Jan 2019 10:13:08 +0800 [thread overview]
Message-ID: <5C5259B4.10005@huawei.com> (raw)
In-Reply-To: <e6bb5696-b2ad-d546-5571-1e2fe39edb61@huawei.com>
On 2019/1/31 1:36, John Garry wrote:
> On 30/01/2019 08:24, Jason Yan wrote:
>> When we failed to discover the device, the phy address is still kept
>> in ex_phy. So when the next time we revalidate this phy the
>> address and device type is the same, it will be considered as flutter
>> and will not be discovered again. So the device will not be brought up.
>>
>> Fix this by reset the phy address to the initial value. Then
>> in the next revalidation the device will be discovered agian.
>
> Why fail to discover the device? I wonder in which scenario you have
> seen this, such that it is worth rediscovery.
>
The test guys have seen this for several times, especially after LLDD
changed the logic of lldd_dev_found and may return error now.
>>
>> Tested-by: Chen Liangfei <chenliangfei1@huawei.com>
>> Signed-off-by: Jason Yan <yanaijie@huawei.com>
>> CC: Xiaofei Tan <tanxiaofei@huawei.com>
>> CC: John Garry <john.garry@huawei.com>
>> CC: Johannes Thumshirn <jthumshirn@suse.de>
>> CC: Ewan Milne <emilne@redhat.com>
>> CC: Christoph Hellwig <hch@lst.de>
>> CC: Tomas Henzl <thenzl@redhat.com>
>> CC: Dan Williams <dan.j.williams@intel.com>
>> CC: Hannes Reinecke <hare@suse.com>
>> ---
>> drivers/scsi/libsas/sas_expander.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/scsi/libsas/sas_expander.c
>> b/drivers/scsi/libsas/sas_expander.c
>> index 6e56ebdc2148..e781941a7088 100644
>> --- a/drivers/scsi/libsas/sas_expander.c
>> +++ b/drivers/scsi/libsas/sas_expander.c
>> @@ -1100,6 +1100,13 @@ static int sas_ex_discover_dev(struct
>> domain_device *dev, int phy_id)
>> i, SAS_ADDR(ex->ex_phy[i].attached_sas_addr));
>> }
>> }
>> + } else {
>> + /* if we failed to discover this device, we have to
>> + * reset the expander phy attached address so that we
>> + * will not treat the phy as flutter in the next
>> + * revalidation
>> + */
>> + memset(ex_phy->attached_sas_addr, 0, SAS_ADDR_SIZE);
>> }
>>
>> return res;
>>
>
>
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: Jason Yan <yanaijie@huawei.com>
To: John Garry <john.garry@huawei.com>, <martin.petersen@oracle.com>,
<jejb@linux.vnet.ibm.com>
Cc: <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<zhaohongjiang@huawei.com>, <hare@suse.com>,
<dan.j.williams@intel.com>, <jthumshirn@suse.de>, <hch@lst.de>,
<huangdaode@hisilicon.com>, <chenxiang66@hisilicon.com>,
<xiexiuqi@huawei.com>, <tj@kernel.org>, <miaoxie@huawei.com>,
Xiaofei Tan <tanxiaofei@huawei.com>,
Ewan Milne <emilne@redhat.com>, Tomas Henzl <thenzl@redhat.com>
Subject: Re: [PATCH v2 6/7] scsi: libsas: reset the phy address if discover failed
Date: Thu, 31 Jan 2019 10:13:08 +0800 [thread overview]
Message-ID: <5C5259B4.10005@huawei.com> (raw)
In-Reply-To: <e6bb5696-b2ad-d546-5571-1e2fe39edb61@huawei.com>
On 2019/1/31 1:36, John Garry wrote:
> On 30/01/2019 08:24, Jason Yan wrote:
>> When we failed to discover the device, the phy address is still kept
>> in ex_phy. So when the next time we revalidate this phy the
>> address and device type is the same, it will be considered as flutter
>> and will not be discovered again. So the device will not be brought up.
>>
>> Fix this by reset the phy address to the initial value. Then
>> in the next revalidation the device will be discovered agian.
>
> Why fail to discover the device? I wonder in which scenario you have
> seen this, such that it is worth rediscovery.
>
The test guys have seen this for several times, especially after LLDD
changed the logic of lldd_dev_found and may return error now.
>>
>> Tested-by: Chen Liangfei <chenliangfei1@huawei.com>
>> Signed-off-by: Jason Yan <yanaijie@huawei.com>
>> CC: Xiaofei Tan <tanxiaofei@huawei.com>
>> CC: John Garry <john.garry@huawei.com>
>> CC: Johannes Thumshirn <jthumshirn@suse.de>
>> CC: Ewan Milne <emilne@redhat.com>
>> CC: Christoph Hellwig <hch@lst.de>
>> CC: Tomas Henzl <thenzl@redhat.com>
>> CC: Dan Williams <dan.j.williams@intel.com>
>> CC: Hannes Reinecke <hare@suse.com>
>> ---
>> drivers/scsi/libsas/sas_expander.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/scsi/libsas/sas_expander.c
>> b/drivers/scsi/libsas/sas_expander.c
>> index 6e56ebdc2148..e781941a7088 100644
>> --- a/drivers/scsi/libsas/sas_expander.c
>> +++ b/drivers/scsi/libsas/sas_expander.c
>> @@ -1100,6 +1100,13 @@ static int sas_ex_discover_dev(struct
>> domain_device *dev, int phy_id)
>> i, SAS_ADDR(ex->ex_phy[i].attached_sas_addr));
>> }
>> }
>> + } else {
>> + /* if we failed to discover this device, we have to
>> + * reset the expander phy attached address so that we
>> + * will not treat the phy as flutter in the next
>> + * revalidation
>> + */
>> + memset(ex_phy->attached_sas_addr, 0, SAS_ADDR_SIZE);
>> }
>>
>> return res;
>>
>
>
>
> .
>
next prev parent reply other threads:[~2019-01-31 2:13 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 8:24 [PATCH v2 0/7] libsas: fix issue of swapping or replacing disks Jason Yan
2019-01-30 8:24 ` Jason Yan
2019-01-30 8:24 ` [PATCH v2 1/7] scsi: libsas: reset the negotiated_linkrate when phy is down Jason Yan
2019-01-30 8:24 ` Jason Yan
2019-01-30 13:08 ` John Garry
2019-01-30 13:08 ` John Garry
2019-01-31 1:11 ` Jason Yan
2019-01-31 1:11 ` Jason Yan
2019-01-31 9:00 ` John Garry
2019-01-31 9:00 ` John Garry
2019-01-30 8:24 ` [PATCH v2 2/7] scsi: libsas: only clear phy->in_shutdown after shutdown event done Jason Yan
2019-01-30 8:24 ` Jason Yan
2019-01-30 16:26 ` John Garry
2019-01-30 16:26 ` John Garry
2019-01-31 1:13 ` Jason Yan
2019-01-31 1:13 ` Jason Yan
2019-01-30 8:24 ` [PATCH v2 3/7] scsi: libsas: optimize the debug print of the revalidate process Jason Yan
2019-01-30 8:24 ` Jason Yan
2019-01-30 16:41 ` John Garry
2019-01-30 16:41 ` John Garry
2019-01-31 1:31 ` Jason Yan
2019-01-31 1:31 ` Jason Yan
2019-01-31 10:25 ` John Garry
2019-01-31 10:25 ` John Garry
2019-01-30 8:24 ` [PATCH v2 4/7] scsi: libsas: split the replacement of sas disks in two steps Jason Yan
2019-01-30 8:24 ` Jason Yan
2019-01-30 17:22 ` John Garry
2019-01-30 17:22 ` John Garry
2019-01-31 2:04 ` Jason Yan
2019-01-31 2:04 ` Jason Yan
2019-01-31 10:29 ` John Garry
2019-01-31 10:29 ` John Garry
2019-01-31 16:38 ` John Garry
2019-01-31 16:38 ` John Garry
2019-02-01 1:58 ` Jason Yan
2019-02-01 1:58 ` Jason Yan
2019-02-01 9:34 ` John Garry
2019-02-01 9:34 ` John Garry
2019-01-30 8:24 ` [PATCH v2 5/7] scsi: libsas: check if the same device when flutter Jason Yan
2019-01-30 8:24 ` Jason Yan
2019-01-30 8:24 ` [PATCH v2 6/7] scsi: libsas: reset the phy address if discover failed Jason Yan
2019-01-30 8:24 ` Jason Yan
2019-01-30 17:36 ` John Garry
2019-01-30 17:36 ` John Garry
2019-01-31 2:13 ` Jason Yan [this message]
2019-01-31 2:13 ` Jason Yan
2019-01-31 9:10 ` John Garry
2019-01-31 9:10 ` John Garry
2019-01-30 8:24 ` [PATCH v2 7/7] scsi: libsas: fix issue of swapping two sas disks Jason Yan
2019-01-30 8:24 ` Jason Yan
2019-01-30 17:53 ` John Garry
2019-01-30 17:53 ` John Garry
2019-01-31 2:55 ` Jason Yan
2019-01-31 2:55 ` Jason Yan
2019-01-31 16:34 ` John Garry
2019-01-31 16:34 ` John Garry
2019-02-01 2:04 ` Jason Yan
2019-02-01 2:04 ` Jason Yan
2019-02-01 9:27 ` John Garry
2019-02-01 9:27 ` John Garry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5C5259B4.10005@huawei.com \
--to=yanaijie@huawei.com \
--cc=chenxiang66@hisilicon.com \
--cc=dan.j.williams@intel.com \
--cc=emilne@redhat.com \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=huangdaode@hisilicon.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=john.garry@huawei.com \
--cc=jthumshirn@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=miaoxie@huawei.com \
--cc=tanxiaofei@huawei.com \
--cc=thenzl@redhat.com \
--cc=tj@kernel.org \
--cc=xiexiuqi@huawei.com \
--cc=zhaohongjiang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.