https://bugzilla.kernel.org/show_bug.cgi?id=215880 --- Comment #47 from Paul Ausbeck (paula@xxxxxxxxxxxxxxxxxxx) --- The PCI/GPU messages are only connected to the ATA messages in the sense that the PCI/GPU activity is unexpectedly deferred until after ATA init is complete. Since resuming of devices is supposedly asynchronous, one would have thought that PCI/GPU init activity would be completed long before hdd spin up is complete. I realize that deferring drive spin up until needed would not be easy, that's why I called such an idea a tour de force. In the past it may have been common for an ata device to not resume reliably, but today even the 10 year old ata devices on my Ivy Bridge machine resume just as reliably as they normally operate, which is quite reliably. If it weren't for power outages, I'd have years of continuous uptime. It's just a thought, but it may be time to revisit how disks, especially spinning disks, are resumed. It seems to me that the chance of a hdd failure during resume is not any greater than at any other time. It should be theoretically possible to queue up resume commands and execute them only when needed to service actual demand. The latency would have to eventually be absorbed, but if the api's are designed and implemented properly that would just happen when needed. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
