Hi, I'm sorry to say that I have to stop the libsas hotplug improvement work, I
will resign from
Huawei, so I have no time and hardware to continue to work at this issue. John
is very familiar with
this work, and provide a lot of good suggestions. So if John like, I am glad he
could join to work
在 2017/7/14 14:51, Hannes Reinecke 写道:
> On 07/10/2017 09:06 AM, Yijing Wang wrote:
>> Introduce wait-complete for libsas sas event processing,
>> execute sas port create/destruct in sync.
>>
>> Signed-off-by: Yijing Wang
>> CC: John Garry
>> CC: Johannes Thumshirn
>> CC: Ewan Milne
>> CC: Ch
在 2017/7/14 0:10, John Garry 写道:
> On 10/07/2017 08:06, Yijing Wang wrote:
>> Disco mutex was introudced to prevent domain rediscovery competing
>> with ata error handling(87c8331). If we have already hold the lock
>> in sas_revalidate_domain and sync executing probe, deadlock caused,
>> because,
在 2017/7/13 16:08, John Garry 写道:
> On 13/07/2017 02:37, wangyijing wrote:
>>> > So much nicer. BTW, /dev/sdb is a SATA disk, the rest are SAS.
>> Oh, I take a mistake ? The result you tested the hotplug which applied this
>> patchset is fine ?
>>
>> Tha
在 2017/7/13 0:50, John Garry 写道:
> On 10/07/2017 08:06, Yijing Wang wrote:
>> Sometimes, we want sync libsas probe or destruct in sas discovery work,
>> like when libsas revalidate domain. We need to split probe and destruct
>> work from the scsi host workqueue.
>>
>> Signed-off-by: Yijing Wang
在 2017/7/12 21:51, John Garry 写道:
> On 10/07/2017 08:06, Yijing Wang wrote:
>>
>> static void sas_chain_event(int event, unsigned long *pending,
>> @@ -592,9 +596,9 @@ int sas_discover_event(struct asd_sas_port *port, enum
>> discover_event ev)
>> {
>> struct sas_discovery *disc;
>>
>> +
There is no special meaning for the pool size, if flutter of > 25 events,
notify sas events will return error, and the further step work is
depending on LLDD drivers.
I hope libsas could do more work in this case, but now it seems a little
difficult, this patch may be a
在 2017/7/12 17:59, John Garry 写道:
> On 10/07/2017 08:06, Yijing Wang wrote:
>> This patchset is based Johannes's patch
>> "scsi: sas: scsi_queue_work can fail, so make callers aware"
>>
>> Now the libsas hotplug has some issues, Dan Williams report
>> a similar bug here before
>> https://www.mail
在 2017/7/12 17:59, John Garry 写道:
> On 10/07/2017 08:06, Yijing Wang wrote:
>> This patchset is based Johannes's patch
>> "scsi: sas: scsi_queue_work can fail, so make callers aware"
>>
>> Now the libsas hotplug has some issues, Dan Williams report
>> a similar bug here before
>> https://www.mail
在 2017/7/12 16:17, John Garry 写道:
> On 12/07/2017 03:06, wangyijing wrote:
>>>> -unsigned long port_events_pending;
>>>> -unsigned long phy_events_pending;
>>>> +struct asd_sas_event port_events[PORT_POOL_SIZE];
>>>> +
在 2017/7/11 23:54, John Garry 写道:
> On 10/07/2017 08:06, Yijing Wang wrote:
>> No one uses the port_gone_completion in struct asd_sas_port,
>> clean it out.
>
> This seems like a reasonable tidy-up patch which could be taken in isolation,
> having no dependency on the rest of the series.
Yes.
>> -unsigned long port_events_pending;
>> -unsigned long phy_events_pending;
>> +struct asd_sas_event port_events[PORT_POOL_SIZE];
>> +struct asd_sas_event phy_events[PHY_POOL_SIZE];
>>
>> int error;
>
> Hi Yijing,
>
> So now we are creating a static pool of events per PH
在 2017/6/15 16:00, John Garry 写道:
> On 15/06/2017 08:37, wangyijing wrote:
>>
>>
>> 在 2017/6/14 21:08, John Garry 写道:
>>> On 14/06/2017 10:04, wangyijing wrote:
>>>>>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event
在 2017/6/14 21:08, John Garry 写道:
> On 14/06/2017 10:04, wangyijing wrote:
>>>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event
>>>> event)
>>>> >> {
>>>> >> +struct sas_ha_
在 2017/6/14 17:18, Johannes Thumshirn 写道:
> On 06/14/2017 11:04 AM, wangyijing wrote:
>>>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event
>>>> event)
>>>> {
>>>> + struct sas_ha_event *ev;
>>>> +
>>
>> In this patch, we try to solve these issues in following steps:
>> 1. create a new workqueue used to run sas event work, instead of scsi host
>> workqueue,
>>because we may block sas event work, we cannot block the normal scsi
>> works.
>>When libsas receive a phy down event, sas_defor
>> static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event
>> event)
>> {
>> +struct sas_ha_event *ev;
>> +
>> BUG_ON(event >= HA_NUM_EVENTS);
>>
>> -sas_queue_event(event, &sas_ha->pending,
>> -&sas_ha->ha_events[event].work, sas_ha);
>> +e
Hi John, thanks for your review and comments!
在 2017/5/25 17:04, John Garry 写道:
> Hi,
>
> There are some comments, inline.
>
> In general, if it works, it looks ok.
>
> Other reviews would be greatly appreciated - Hannes, Christoph, Johannes, Dan
> - please.
>
>> Libsas complete a hotplug eve
>>
>
> I have seen this scenario on our development board when we have a bad
> physical cable connection - the PHY continually goes up and down in a loop.
>
> So, in this regard, it is worth safeguarding against this scenario.
OK, I will reconsider this case.
Thanks!
Yijing.
>
> John
>
>
Hi Dan, thanks for your review and comments!
在 2017/5/21 11:44, Dan Williams 写道:
> On Fri, May 19, 2017 at 11:39 PM, Yijing Wang wrote:
>> Now libsas hotplug work is static, LLDD driver queue
>> the hotplug work into shost->work_q. If LLDD driver
>> burst post lots hotplug events to libsas, the h
>>
>> Please repost the series against the current tree. Also a cover
>> letter with a bit more explanation would be good.
>>
>
> Great, I think that my colleagues can send an updated version next week.
I will send a new version with a cover letter these days, before that, we need
to do a detai
Reviewed-by: Yijing Wang
在 2017/1/11 23:44, Bjorn Helgaas 写道:
> PCI: Enumerate switches below PCI-to-PCIe bridges
>
> A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary
> interface and a PCI Express secondary interface. The PCIe interface is a
> Downstream Port that originates
>>> I want to make sure that the set_capacity call that happens on cache
>>> attachment is not necessary when a backing device is attached without
>>
>> Hi Eric, set_capacity() which removed in this patch is happened at
>> cached_dev_init()
>> which is called when register a backing device, what
>>> It probably is a duplicate set_capacity, but has anyone tested bringing on
>>> a writeback volume, and late-attaching the cache volume with this patch
>>> applied?
>>>
>>> Otherwise stated, is it possible to get the backing device attached
>>> without setting the capacity?
>>
>> Hi Eric, I
在 2016/11/30 4:49, Eric Wheeler 写道:
> On Fri, 25 Nov 2016, Yijing Wang wrote:
>
>> set_capacity() has been called in bcache_device_init(),
>> remove the redundant one.
>>
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/md/bcache/super.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --g
在 2016/11/27 16:00, Coly Li 写道:
> On 2016/11/25 上午9:40, Yijing Wang wrote:
>> Parameter bio is no longer used, clean it.
>>
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/md/bcache/request.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/md/bca
在 2016/11/27 15:57, Coly Li 写道:
> On 2016/11/25 上午9:39, Yijing Wang wrote:
>> set_capacity() has been called in bcache_device_init(),
>> remove the redundant one.
>>
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/md/bcache/super.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/d
>>
>> The events are not lost.
>
> In sas_queue_event(), if there is a particular event pending for a port/PHY,
> we cannot queue further same event types for that port/PHY. I think my
> colleagues found issue where we try to enqueue multiple complementary events.
Yes, we found this issue in ou
>>> I have not seen the flutter issue. I am just trying to solve the horrible
>>> WARN dump.
>>> However I do understand that there may be a issue related to how we queue
>>> the events; there was a recent attempt to fix this, but it came to nothing:
>>> https://www.spinics.net/lists/linux-scsi/m
Hi James, sorry to bother you, these two patches try to fix several issues
in libsas, Dan Williams and John Garry also found similar issue, and post
some patches before. Dan Williams's solution fix the sysfs warning calltrace,
but may introduce new flutter issue.
In these two patches, we introduce
>
> They're not the same. I don't see how your solution properly deals with
> remote sas_port deletion.
>
> When we unplug a device connected to an expander, can't the sas_port be
> deleted twice, in sas_unregister_devs_sas_addr() from domain revalidation and
> also now in sas_destruct_devices
在 2016/7/4 13:49, Coly Li 写道:
> 在 16/7/4 上午9:23, Yijing Wang 写道:
>> There is no return in continue_at(), update the documentation.
>>
>
> Thanks.
>
> Acked-by: Coly Li
Thanks very much!
>
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/md/bcache/closure.c |2 +-
>> drivers/md/bcache/c
在 2016/7/1 12:21, Coly Li 写道:
> 在 16/7/1 上午9:51, wangyijing 写道:
>> Hi Coly, thanks to your review and comments.
>>
>> Commit 77b5a08427e875 ("bcache: don't embed 'return' statements in closure
>> macros")
>> remove the return in contin
在 2016/7/1 12:24, Coly Li 写道:
> 在 16/7/1 上午10:09, wangyijing 写道:
>>
>>
>> 在 2016/6/29 18:20, Coly Li 写道:
>>> 在 16/6/22 上午10:10, Yijing Wang 写道:
>>>> Cache_sb is not used in cache_alloc, and we have copied
>>>> sb info to cache->sb
在 2016/6/29 18:20, Coly Li 写道:
> 在 16/6/22 上午10:10, Yijing Wang 写道:
>> Cache_sb is not used in cache_alloc, and we have copied
>> sb info to cache->sb already, remove it.
>>
>> Signed-off-by: Yijing Wang
>> ---
>> drivers/md/bcache/super.c |4 ++--
>> 1 files changed, 2 insertions(+), 2 del
Hi Coly, thanks to your review and comments.
Commit 77b5a08427e875 ("bcache: don't embed 'return' statements in closure
macros")
remove the return in continue_at(), so I think we should update the document
info
about continue_at().
Thanks!
Yijing.
在 2016/6/29 18:16, Coly Li 写道:
> 在 16/6/22 上午1
在 2016/6/21 23:03, Bjorn Helgaas 写道:
> On Tue, Jun 21, 2016 at 07:58:08PM +0800, wangyijing wrote:
>> Hi Bjorn, use devm_request_resource() for host bridge resource is cool,
>> what about do the similar change for x86, now we request host bridge resource
>> in pci_acpi_ro
Hi Bjorn, use devm_request_resource() for host bridge resource is cool,
what about do the similar change for x86, now we request host bridge resource
in pci_acpi_root_add_resources() in x86, and we would release the host bridge
resource when host bridge device refcount reach 0. This logic may intro
>
> Doesn't apply to v4.4-rc2. Please refresh and repost if this is still
> relevant.
Hi Bjorn, this is still relevant, I will refresh it and post the new version
soon.
Thanks!
Yijing.
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mess
39 matches
Mail list logo