All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Yan <yanaijie@huawei.com>
To: John Garry <john.g.garry@oracle.com>,
	"Li, Eric (Honggang)" <Eric.H.Li@Dell.com>,
	"james.bottomley@hansenpartnership.com"
	<James.Bottomley@HansenPartnership.com>,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: Issue in sas_ex_discover_dev() for multiple level of SAS expanders in a domain
Date: Thu, 25 Apr 2024 10:57:43 +0800	[thread overview]
Message-ID: <b1a5552c-689e-d220-88d3-56d24752be5b@huawei.com> (raw)
In-Reply-To: <09dd80bb-09f9-481f-a7a7-b9227b6f928f@oracle.com>

On 2024/4/24 18:46, John Garry wrote:
> On 24/04/2024 09:59, Li, Eric (Honggang) wrote:
>> Hi,
>>
>> There is an issue in the function sas_ex_discover_dev() when I have 
>> multiple SAS expanders chained under one SAS port on SAS controller.
> 
> I think typically we can't and so don't test such a setup.

Eric,

I also don't understand why you need such a setup. Can you explain more 
details of your topology?

> 
>>
>> In this function, we first check whether the PHY’s 
>> attached_sas_address is already present in the SAS domain, and then 
>> check if this PHY belongs to an existing port on this SAS expander.
>> I think this has an issue if this SAS expander use a wide port 
>> connecting a downstream SAS expander.
>> This is because if the PHY belongs to an existing port on this SAS 
>> expander, the attached SAS address of this port must already be 
>> present in the domain and it results in disabling that port.
>> I don’t think that is what we expect.
>>
>> In old release (4.x), at the end of this function, it would make 
>> addition sas_ex_join_wide_port() call for any possibly PHYs that could 
>> be added into the SAS port.
>> This will make subsequent PHYs (other than the first PHY of that port) 
>> being marked to DISCOVERED so that this function would not be invoked 
>> on those subsequent PHYs (in that port).
>> But potential question here is we didn’t configure the per-PHY routing 
>> table for those PHYs.
>> As I don’t have such SAS expander on hand, I am not sure what’s impact 
>> (maybe just performance/bandwidth impact).
>> But at least, it didn’t impact the functionality of that port.
>>
>> But in v5.3 or later release, that part of code was removed (in the 
>> commit a1b6fb947f923).
> 
> Jason, can you please check this?

The removed code is only for races before we serialize the event 
processing. All PHYs will still be scanned one by one and add to the 
wide port if they have the same address. So are you encountering a real 
issue? If so, can you share the full log?

Thanks,
Jason

祝一切顺利!

> 
> Thanks!
> 
>> And this caused this problem occurred (downstream port of that SAS 
>> expander was disabled and all downstream SAS devices were removed from 
>> the domain).
>>
>> Regards.
>> Eric Li
>>
>> SPE, DellEMC
>> 3/F KIC 1, 252# Songhu Road, YangPu District, SHANGHAI
>> +86-21-6036-4384
>>
>>
>> Internal Use - Confidential
> 
> .

  reply	other threads:[~2024-04-25  2:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-24  8:59 Issue in sas_ex_discover_dev() for multiple level of SAS expanders in a domain Li, Eric (Honggang)
2024-04-24 10:46 ` John Garry
2024-04-25  2:57   ` Jason Yan [this message]
2024-04-25  5:03     ` Li, Eric (Honggang)
2024-04-30 14:22       ` Li, Eric (Honggang)
2024-05-01 14:23         ` John Garry
2024-05-03  3:15           ` Li, Eric (Honggang)
2024-05-03  8:33             ` John Garry
2024-05-06  1:49               ` Li, Eric (Honggang)
2024-05-07  8:03                 ` John Garry
2024-05-07  8:44                 ` Li, Eric (Honggang)
2024-05-07  9:17                   ` John Garry
2024-05-07 11:17                     ` Li, Eric (Honggang)

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=b1a5552c-689e-d220-88d3-56d24752be5b@huawei.com \
    --to=yanaijie@huawei.com \
    --cc=Eric.H.Li@Dell.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=john.g.garry@oracle.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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.