https://bugzilla.kernel.org/show_bug.cgi?id=215880 --- Comment #46 from Damien Le Moal (damien.lemoal@xxxxxxx) --- (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.
