Hi,
(please Cc)
I recently upgraded my Lenovo X260 from 4.12 to 4.13 and with the very
same software (Debian/sid) 4.13 does not properly wake up from
suspend to ram.
It wakes up, shows X very quickly, but it seems that the hard disk is
sleeping and not reacting. I can move the mouse, but the unlock screen
is not shown.
Switching to the console I can enter the user name, but then I am waiting
for the prompt indefinitely.
Callng Sysrq-s to sync the disks never returns that the sync completed.
Waiting long enough it completely freezes and only Sysrq-b helps.
I have tried to capture any output, but due to the circumstances
described, nothing can be saved to persist.
I am happy to provide details if someone explains me how to grab them
(sorry, no serial console!), or test patches/suggestions with the kernel.
Thanks
Norbert
please Cc.
--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
On Wed, Sep 20, 2017 at 10:36 PM, Norbert Preining
<[email protected]> wrote:
> Hi,
>
> (please Cc)
>
> I recently upgraded my Lenovo X260 from 4.12 to 4.13 and with the very
> same software (Debian/sid) 4.13 does not properly wake up from
> suspend to ram.
>
> It wakes up, shows X very quickly, but it seems that the hard disk is
> sleeping and not reacting. I can move the mouse, but the unlock screen
> is not shown.
>
> Switching to the console I can enter the user name, but then I am waiting
> for the prompt indefinitely.
>
> Callng Sysrq-s to sync the disks never returns that the sync completed.
Looks your issue is very similar with Oleksandr's report:
https://marc.info/?t=150340250100013&r=3&w=2
And Oleksandr tested the following patchset can fix his issue:
https://marc.info/?l=linux-block&m=150579298505484&w=2
Maybe you can try it to see if it fixes your issue.
--
Ming Lei
Hi Norbert,
from what I can tell 4.13 is really, really stable at resuming from suspend. I would say the most reliable kernel for a long time on my ThinkPad (P50, using nouveau).
Do you use blk-mq? There's a discussion regarding stalled io...
Regards,
Marc
P.S: sent from mobile, might be short.
Am 20. September 2017 16:36:56 MESZ schrieb Norbert Preining <[email protected]>:
>Hi,
>
>(please Cc)
>
>I recently upgraded my Lenovo X260 from 4.12 to 4.13 and with the very
>same software (Debian/sid) 4.13 does not properly wake up from
>suspend to ram.
>
>It wakes up, shows X very quickly, but it seems that the hard disk is
>sleeping and not reacting. I can move the mouse, but the unlock screen
>is not shown.
>
>Switching to the console I can enter the user name, but then I am
>waiting
>for the prompt indefinitely.
>
>Callng Sysrq-s to sync the disks never returns that the sync completed.
>
>Waiting long enough it completely freezes and only Sysrq-b helps.
>
>I have tried to capture any output, but due to the circumstances
>described, nothing can be saved to persist.
>
>I am happy to provide details if someone explains me how to grab them
>(sorry, no serial console!), or test patches/suggestions with the
>kernel.
>
>Thanks
>
>Norbert
>
>please Cc.
>
>--
>PREINING Norbert http://www.preining.info
>Accelia Inc. + JAIST + TeX Live + Debian Developer
>GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
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?
> 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.)
Thanks a lot and all the best
Norbert
--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
On Thu, Sep 21, 2017 at 12:48 AM, Norbert Preining <[email protected]> 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
Hi Ming,
> So could you share us how often it is triggered? and what is your underlying
> disk behind dm-crypt?
It is triggered *every* time I suspend.
Underlying disk is
scsi 1:0:0:0: Direct-Access ATA WDC WD10JPVX-08J 1A07 PQ: 0 ANSI: 5
I checked the values in
/sys/block/dm-?/dm/use_blk_mq
and they are all set to 0.
> BTW, you can debug and collect some dmesg log during system suspend/resume
> without serial console:
I will try that tonight, now I am at work.
> Please get the patches backported to v4.13 in the following tree:
Thanks
Norbert
--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13