Most recent kernel where this bug did not occur: 2.6.18-rc3
Distribution: Suse Linux Enterprise Desktop 10
Hardware Environment: Sony Vaio A-190 Laptop (686)
I can suspend to ram either using Suse's powersave daemon or from the
commandline using s2ram. As a specific example I can use 's2ram -r -f' to
suspend my machine. When I hit a key to wake it the screen comes back to life
and (when using powersave) some text is displayed (saying processes will be
restarted). The machine then sits there for 30 seconds before coming back to
life. Also, even after it comes back to life I can use the disk for a few
seconds but then suddenly all disk access stalls for another period (10-30 secs,
never timed it) and then I can hear the disk whir up and respond again. From
the suspend-devel mailing list I found out that most machines resume from a
suspend to ram in 2-4 seconds which is definately much more desirable.
I have discussed this at length on the suspend mailing list and the developers
there believe it is a problem with the piix.c driver and my particular ide
I tried using 2.6.18-rc3 with a single patch from the mm2 tree:
This was supposed to add suspend/resume support at the level of the general ide
drivers but it did not resolve my issue.
The consensus on the suspend-devel mailing list that this is an ide timeout issue.
Steps to reproduce:
Run 's2ram -r -f' only any kernel using the piix driver. This might be a bios
issue. It might be that my bios is not good at restarting the ide subsystem
while others are so this might not show up for every card using the piix driver
but it does so on mine.
I would be glad to help test any fixes.
*** Bug 7136 has been marked as a duplicate of this bug. ***
Does the lack of activity mean there hasn't been any progress?
Matthew Garrett and others have been working on the general case of
suspend/resume and ACPI handling for ATA (libata and old drivers/ide). AFAIK
nobody is working on specific problem reports with the legacy IDE layer, merely
with libata which is the better long term project although it doesn't help you
From the quick look I don't see anything suspicious in piix.c.
Seems like the problem is caused by lack of ACPI handling in IDE. There were
draft patches floating around for that but it seems they never got worked into
something ready to merge and submitted (or maybe I have missed them?). Rafael,
could you please investigate further what is the current state of IDE ACPI
patches (I think that SuSE has them in their tree and if they are in some
semi-proper state we can merge them to -mm and give them a spin)?
Ouch, I have missed the previous post (sorry Bartlomiej).
As far as I can tell right now, there seem to be some patches like that in -mm,
though I'm not sure.
I'll ask SUSE people anyway.
I think the ACPI IDE patch went into the Bart's tree some time ago. I spotted
it in -mm, but I'm not sure whether or not it's been merged.
As far as the libata version is concerned, I've seen some submissions recently
and I think they are in -mm.
ACPI IDE patch has been merged for 2.6.21-rc1. Please note that some features
are not used automatically ATM and may require usage of kernel parameters to be
enabled. I would like to have it changed but this needs to be verified with the
original authors and get some testing.
libata ACPI support has also been merged into 2.6.21 but incomplete PATA support
has been disabled recently (commit df33c77e3981e71afc8727ee5c432ba1a1bba68c).
Thanks for the update. :-)
Sheer, can you confirm that the problem is fixed for you in recent -rc*
Accepting in order to close.
Please reopen if necessary.