Hi Keith
Thanks for your precious time and kindly response.
On 02/08/2018 11:15 PM, Keith Busch wrote:
> On Thu, Feb 08, 2018 at 10:17:00PM +0800, jianchao.wang wrote:
>> There is a dangerous scenario which caused by nvme_wait_freeze in
>> nvme_reset_work.
>> please consider it.
>>
>> nvme_reset
On Thu, Feb 08, 2018 at 10:17:00PM +0800, jianchao.wang wrote:
> There is a dangerous scenario which caused by nvme_wait_freeze in
> nvme_reset_work.
> please consider it.
>
> nvme_reset_work
> -> nvme_start_queues
> -> nvme_wait_freeze
>
> if the controller no response, we have to rely on t
Hi Keith
Sorry for bothering you again. ;)
There is a dangerous scenario which caused by nvme_wait_freeze in
nvme_reset_work.
please consider it.
nvme_reset_work
-> nvme_start_queues
-> nvme_wait_freeze
if the controller no response, we have to rely on the timeout path.
there are issues be
Hi Keith
Really thanks for your your precious time and kindly directive.
That's really appreciated. :)
On 02/08/2018 12:13 AM, Keith Busch wrote:
> On Wed, Feb 07, 2018 at 10:13:51AM +0800, jianchao.wang wrote:
>> What's the difference ? Can you please point out.
>> I have shared my understandin
On Wed, Feb 07, 2018 at 10:13:51AM +0800, jianchao.wang wrote:
> What's the difference ? Can you please point out.
> I have shared my understanding below.
> But actually, I don't get the point what's the difference you said.
It sounds like you have all the pieces. Just keep this in mind: we don't
Hi Keith
Sorry for bothering you again.
On 02/07/2018 10:03 AM, jianchao.wang wrote:
> Hi Keith
>
> Thanks for your time and kindly response on this.
>
> On 02/06/2018 11:13 PM, Keith Busch wrote:
>> On Tue, Feb 06, 2018 at 09:46:36AM +0800, jianchao.wang wrote:
>>> Hi Keith
>>>
>>> Thanks for
Hi Keith
Thanks for your time and kindly response on this.
On 02/06/2018 11:13 PM, Keith Busch wrote:
> On Tue, Feb 06, 2018 at 09:46:36AM +0800, jianchao.wang wrote:
>> Hi Keith
>>
>> Thanks for your kindly response.
>>
>> On 02/05/2018 11:13 PM, Keith Busch wrote:
>>> but how many requests are
On Tue, Feb 06, 2018 at 09:46:36AM +0800, jianchao.wang wrote:
> Hi Keith
>
> Thanks for your kindly response.
>
> On 02/05/2018 11:13 PM, Keith Busch wrote:
> > but how many requests are you letting enter to their demise by
> > freezing on the wrong side of the reset?
>
> There are only two di
Hi Keith
Thanks for your kindly response.
On 02/05/2018 11:13 PM, Keith Busch wrote:
> but how many requests are you letting enter to their demise by
> freezing on the wrong side of the reset?
There are only two difference with this patch from the original one.
1. Don't freeze the queue for the
On Mon, Feb 05, 2018 at 10:26:03AM +0800, jianchao.wang wrote:
> > Freezing is not just for shutdown. It's also used so
> > blk_mq_update_nr_hw_queues will work if the queue count changes across
> > resets.
> blk_mq_update_nr_hw_queues will freeze the queue itself. Please refer to.
> static void __
Hi Keith
Thanks for your kindly response.
On 02/03/2018 02:24 AM, Keith Busch wrote:
> On Fri, Feb 02, 2018 at 03:00:45PM +0800, Jianchao Wang wrote:
>> Currently, request queue will be frozen and quiesced for both reset
>> and shutdown case. This will trigger ioq requests in RECONNECTING
>> stat
On Fri, Feb 02, 2018 at 03:00:45PM +0800, Jianchao Wang wrote:
> Currently, request queue will be frozen and quiesced for both reset
> and shutdown case. This will trigger ioq requests in RECONNECTING
> state which should be avoided to prepare for following patch.
> Just freeze request queue for sh
12 matches
Mail list logo
