[Bug 215880] Resume process hangs for 5-6 seconds starting sometime in 5.16

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=215880

--- Comment #46 from Damien Le Moal (damien.lemoal@wdc.com) ---
(In reply to Paul Ausbeck from comment #44)
> I'd like to add that I've also noticed this regression after upgrading from
> Debian 11/5.10 to Debian 12/6.1

> I've copied the resume portion of the dmesg log below. Note that the pci bus
> activity and related gpu messages don't happen until after my 10 year old
> 2TB hdd spins up. Restarting of tasks is also deferred until then. I also
> note that the mouse cursor is also frozen until all those platters spin up..

The GPU related messages are unrelated to ATA subsystem. Obviously, libata does
not attempt to use the GPU for anything :) Restarting of tasks being differed
until the hdd spins up is also normal. hdd spinning up and then starting
responding to commands is part of the normal resume process and tasks will be
resumed only after the kernel has finished resuming all devices. Resuming of
devices is asynchronous and devices that are unrelated can be resumed
simultaneously. So I am not sure why it seems that your GPU and mouse resuming
is delaying only after the HDD spin up. Note that this change to asynchronous
resume did cause some issues with ata/scsi (see below).

> To my mind, it would be a major improvement/tour de force if linux could
> defer spinning up the hdd at all until it is needed. Think of all the drive
> wear and energy savings that would ensue. I use my 2TB hdd for backing up
> smaller drives and for storing movies. It would be quite nice if the drive
> were to not spin up at all until accessed.

Having the drive sleep when unused can be achieved using power state timers
setting on the drive itself. Resume is different: the kernel must ensure that
the device that was there before suspend is still here, and in the case of
storage, that the device is still the same. This is necessary to avoid issues
with file system (that will resume later) and also with tasks that were doing
IOs when the system was suspended. If file systems or tasks were resumed
without the storage device ready and checked first, all sorts of bad things can
happen.

Note that commit 6aa0365a3c85 ("ata: libata-scsi: Avoid deadlock on rescan
after device resume") was added to kernel 6.4 (at rc7) to fix another issue
with resume: a hard hang (not a delay). This patch synchronizes scsi and ata
resume by having scsi resume wait for ata resume to complete, which means
waiting for the device re-scan to complete. And that in turn means that the HDD
must complete spin up first.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.