Hello Michael,

On Wed, 2019-07-10 at 23:56 +0300, Michael Krylov wrote:
> Dear Maintainer,
> after updating to buster, I've noticed quite an annoying problem:
> after
> waking up from suspend, my laptop (that's a Lenovo X220i) doesn't
> wake
> up the hard drive, which basically leads to totally unresponding
> system
> that can be only hard-rebooted or rebooted with Alt-SysRq-B. It
> doesn't
> happen every time, it happens maybe one in 2 or 3 wakeups.
> This didn't occur in stretch and I guess it shouldn't be like that :)

The disk not coming back online is going to be hard to debug issue
then. Because none of the system logs would be written.

From what you have described, this sounds like a know issue. But you'll
have to help confirm it.

Here's a link to the bug:

> I've noticed (by running htop, suspending, and waking up from
> suspend)
> that it is caused either directly by laptop-mode-tools which is
> triggered by udev, or by one of the tools it starts after resuming
> from
> suspend.
> I did a little research on that using the following method:
> 1. Change a setting in /etc/laptop-mode/laptop-mode.conf
> 2. Run something that will make HDD busy (cat /dev/sda > /dev/zero
> for
>    example)
> 3. Suspend and wake up 2 or 3 times
> 4. See if HDD wakes up.
> By such experimentation, I managed to find out that the option that
> causes this problem is CONTROL_MOUNT_OPTIONS. If it is set to 1, one
> in
> 2 or 3 wakeups lead to sleepy HDD. But if it is set to 0, even 20
> suspends/wakeups are successful.
> I also noted that it happens only when the laptop is on battery, but
> I'm
> not sure of that.

I don't think this is the case because the mount setting default to
being enabled, and used by many many users including me, and I haven't
come across this symptom.

> I guess that's quite a broad description, and I'll be glad to help
> you
> with testing various options, if it is possible. For now, I guess
> I'll
> leave CONTROL_MOUNT_OPTIONS=0, but that's probably defies the idea
> behind laptop-mode-tools, at least in terms with HDD.

The best is to get the system logs but it becomes very difficult in
such scenarios where you are doing a swsusp resume and your block layer
is not available for write.

Please go through the bug report I've shared above. I suspect that may
have some pointers to your issue too.


Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to