All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"jthumshirn@suse.de" <jthumshirn@suse.de>,
	"hch@lst.de" <hch@lst.de>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"ming.lei@redhat.com" <ming.lei@redhat.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"oleksandr@natalenko.name" <oleksandr@natalenko.name>,
	"hare@suse.com" <hare@suse.com>,
	"mcgrof@kernel.org" <mcgrof@kernel.org>
Subject: Re: [PATCH v7 9/9] block, scsi: Make SCSI quiesce and resume work reliably
Date: Thu, 12 Oct 2017 21:53:57 +0200	[thread overview]
Message-ID: <3970766.W9abtXnTZN@merkaba> (raw)
In-Reply-To: <1507649241.2815.9.camel@wdc.com>

Bart Van Assche - 10.10.17, 15:27:
> On Tue, 2017-10-10 at 09:57 +0200, Martin Steigerwald wrote:
>=20
> > Bart Van Assche - 09.10.17, 16:14:
> >=20
> > > The contexts from which a SCSI device can be quiesced or resumed are:
> > > [ ... ]
> >=20
> >=20
> > Does this as reliably fix the issue as the patches from Ming? I mean in
> > *real world* scenarios? Or is it just about the same approach as Ming
> > has taken.=20
> > I ask cause I don=B4t see any Tested-By:=B4s here? I know I tested Ming=
=B4s
> > patch series and I know it fixes the hang after resume from suspend
> > with blk-mq + BFQ issue for me. I have an uptime of 7 days and I didn=
=B4t
> > see any uptime even remotely like that in a long time (before that issue
> > Intel gfx drivers caused hangs, but thankfully that seems fixed
> > meanwhile).
> >=20
> > I=B4d be willing to test. Do you have a 4.14.x tree available with these
> > patches applied I can just add as a remote and fetch from?

> A previous version of this patch series passed Oleksandr's tests. This
> series is close to that previous version so I think it is safe to assume
> that this version will also pass Oleksandr's tests. Anyway, more testing =
is
> definitely welcome so if you want to verify this series please start from
> the following tree (Jens' for-next branch + this series):
> https://github.com/bvanassche/linux/tree/blk-mq-pm-v7=20

Several suspend to ram and resume, and suspend to disk and resume cycles=20
without issues. So I think this is good.

Tested-By: Martin Steigerwald <martin@lichtvoll.de>

Thanks,
=2D-=20
Martin

WARNING: multiple messages have this Message-ID (diff)
From: Martin Steigerwald <martin@lichtvoll.de>
To: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	"jthumshirn@suse.de" <jthumshirn@suse.de>,
	"hch@lst.de" <hch@lst.de>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"ming.lei@redhat.com" <ming.lei@redhat.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"oleksandr@natalenko.name" <oleksandr@natalenko.name>,
	"hare@suse.com" <hare@suse.com>,
	"mcgrof@kernel.org" <mcgrof@kernel.org>
Subject: Re: [PATCH v7 9/9] block, scsi: Make SCSI quiesce and resume work reliably
Date: Thu, 12 Oct 2017 21:53:57 +0200	[thread overview]
Message-ID: <3970766.W9abtXnTZN@merkaba> (raw)
In-Reply-To: <1507649241.2815.9.camel@wdc.com>

Bart Van Assche - 10.10.17, 15:27:
> On Tue, 2017-10-10 at 09:57 +0200, Martin Steigerwald wrote:
> 
> > Bart Van Assche - 09.10.17, 16:14:
> > 
> > > The contexts from which a SCSI device can be quiesced or resumed are:
> > > [ ... ]
> > 
> > 
> > Does this as reliably fix the issue as the patches from Ming? I mean in
> > *real world* scenarios? Or is it just about the same approach as Ming
> > has taken. 
> > I ask cause I don´t see any Tested-By:´s here? I know I tested Ming´s
> > patch series and I know it fixes the hang after resume from suspend
> > with blk-mq + BFQ issue for me. I have an uptime of 7 days and I didn´t
> > see any uptime even remotely like that in a long time (before that issue
> > Intel gfx drivers caused hangs, but thankfully that seems fixed
> > meanwhile).
> > 
> > I´d be willing to test. Do you have a 4.14.x tree available with these
> > patches applied I can just add as a remote and fetch from?

> A previous version of this patch series passed Oleksandr's tests. This
> series is close to that previous version so I think it is safe to assume
> that this version will also pass Oleksandr's tests. Anyway, more testing is
> definitely welcome so if you want to verify this series please start from
> the following tree (Jens' for-next branch + this series):
> https://github.com/bvanassche/linux/tree/blk-mq-pm-v7 

Several suspend to ram and resume, and suspend to disk and resume cycles 
without issues. So I think this is good.

Tested-By: Martin Steigerwald <martin@lichtvoll.de>

Thanks,
-- 
Martin

  reply	other threads:[~2017-10-12 19:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-09 23:13 [PATCH v7 0/9] Hello Jens, Bart Van Assche
2017-10-09 23:13 ` [PATCH v7 1/9] md: Rename md_notifier into md_reboot_notifier Bart Van Assche
2017-10-10  7:20   ` Johannes Thumshirn
2017-10-10  7:20     ` Johannes Thumshirn
2017-10-09 23:13 ` [PATCH v7 2/9] md: Introduce md_stop_all_writes() Bart Van Assche
2017-10-10  7:21   ` Johannes Thumshirn
2017-10-10  7:21     ` Johannes Thumshirn
2017-10-09 23:13 ` [PATCH v7 3/9] md: Neither resync nor reshape while the system is frozen Bart Van Assche
2017-10-09 23:13 ` [PATCH v7 4/9] block: Make q_usage_counter also track legacy requests Bart Van Assche
2017-10-10  7:22   ` Johannes Thumshirn
2017-10-10  7:22     ` Johannes Thumshirn
2017-10-09 23:13 ` [PATCH v7 5/9] block: Introduce blk_get_request_flags() Bart Van Assche
2017-10-09 23:13 ` [PATCH v7 6/9] block: Introduce BLK_MQ_REQ_PREEMPT Bart Van Assche
2017-10-09 23:13 ` [PATCH v7 7/9] ide, scsi: Tell the block layer at request allocation time about preempt requests Bart Van Assche
2017-10-09 23:13 ` [PATCH v7 8/9] block: Add the QUEUE_FLAG_PREEMPT_ONLY request queue flag Bart Van Assche
2017-10-09 23:14 ` [PATCH v7 9/9] block, scsi: Make SCSI quiesce and resume work reliably Bart Van Assche
2017-10-10  7:57   ` Martin Steigerwald
2017-10-10  7:57     ` Martin Steigerwald
2017-10-10 15:27     ` Bart Van Assche
2017-10-10 15:27       ` Bart Van Assche
2017-10-12 19:53       ` Martin Steigerwald [this message]
2017-10-12 19:53         ` Martin Steigerwald
2017-10-10 10:56   ` Ming Lei
2017-10-10 17:16     ` Bart Van Assche
2017-10-10 17:16       ` Bart Van Assche
2017-10-17  4:19   ` [block, scsi] f246f66ae5: WARNING:at_block/blk-core.c:#blk_queue_enter kernel test robot
2017-10-17  4:19     ` kernel test robot
2017-10-17  4:19     ` kernel test robot
2017-10-10  0:00 ` [PATCH v7 0/9] Hello Jens, Bart Van Assche
2017-10-10  0:00   ` Bart Van Assche

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=3970766.W9abtXnTZN@merkaba \
    --to=martin@lichtvoll.de \
    --cc=Bart.VanAssche@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=hare@suse.com \
    --cc=hch@lst.de \
    --cc=jthumshirn@suse.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mcgrof@kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=oleksandr@natalenko.name \
    /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.