MIME-Version: 1.0
In-Reply-To: <20170920164809.s4mnlzjykroe5tn3@burischnitzel.preining.info>
References: <CACVXFVMf0UvATYLbUncXVsaLL-ACpijXiRiAxFAqRf-WGwkYPQ@mail.gmail.com>
 <20170920164809.s4mnlzjykroe5tn3@burischnitzel.preining.info>
From: Ming Lei <tom.leiming@gmail.com>
Date: Thu, 21 Sep 2017 09:29:14 +0800
Message-ID: <CACVXFVPBfiQitQrkyKN8K3HYxsdVaSLsN1RS17W+in3r0jS7wQ@mail.gmail.com>
Subject: Re: 4.13 breaks suspend to ram wakeup
To: Norbert Preining <preining@logic.at>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2590
Lines: 67

On Thu, Sep 21, 2017 at 12:48 AM, Norbert Preining <preining@logic.at> wrote:
> Dear all,
>
> thanks for the quick feedback.
>
> On Wed, 20 Sep 2017, Ming Lei wrote:
>> Looks your issue is very similar with Oleksandr's report:
>
> Indeed, I am using dm-crypt (full disk encryption) and
>         CONFIG_DEFAULT_IOSCHED="cfq"
> Any suggestion what should be selected instead?

The previous reports are all with blk-mq enabled, since it is quite easy to
reproduce on blk-mq, but in theory there should be such issue on
block legacy when the request pool is used up, that means it can be
a bit hard to trigger in this case.

So could you share us how often it is triggered? and what is your underlying
disk behind dm-crypt?

BTW, you can debug and collect some dmesg log during system suspend/resume
without serial console:

1) pass 'no_console_suspend' to kernel cmdline

2) start a vga console via 'ctrl + alt + F1/F2/...'

3) run the following commands to start system suspend test:

echo 9 > /proc/sys/kernel/printk
echo devices > /sys/power/pm_test
echo mem > /sys/power/state

4) system will be waken up after 5 seconds

5) if the current console is hang after system resume, either you
wait for the hang log is triggered in console after 2 minutes, or you
can try to login from another vga console via 'ctrl + alt + F2/F3/...' and
try to collect dmesg log to see if there is hang

>
>> And Oleksandr tested the following patchset can fix his issue:
>>        https://marc.info/?l=linux-block&m=150579298505484&w=2
>
> Do you have a patch against 4.13? I tried applying the following
> patches from git format-patch ebb2c2437d8008d467969
>         0001-blk-mq-only-run-hw-queues-for-blk-mq.patch
>         0002-block-tracking-request-allocation-with-q_usage_count.patch
>         0003-blk-mq-rename-blk_mq_-freeze-unfreeze-_queue.patch
>         0004-blk-mq-rename-blk_mq_freeze_queue_wait-as-blk_freeze.patch
>         0005-block-rename-.mq_freeze_wq-and-.mq_freeze_depth.patch
>         0006-block-pass-flags-to-blk_queue_enter.patch
>         0007-block-introduce-preempt-version-of-blk_-freeze-unfre.patch
>         0008-block-allow-to-allocate-req-with-RQF_PREEMPT-when-qu.patch
>         0009-SCSI-transport_spi-resume-a-quiesced-device.patch
>         0010-SCSI-preempt-freeze-block-queue-when-SCSI-device-is-.patch
> to current 4.13, but without success.
> (I don't want to play with .14-pre kernels by now.)
>

Please get the patches backported to v4.13 in the following tree:

          https://github.com/ming1/linux/tree/my_v4.13-safe-scsi-quiesce_V5_for_test


-- 
Ming Lei