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) Software Environment: Problem Description: 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 chipset (??): http://sourceforge.net/mailarchive/message.php?msg_id=36301041 I tried using 2.6.18-rc3 with a single patch from the mm2 tree: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc3/2.6.18-rc3-mm2/broken-out/ide-reprogram-disk-pio-timings-on-resume.patch 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 right now. Alan
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)?
Rafael?
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.
ping Rafael
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* kernels?
Accepting in order to close.
Closing. Please reopen if necessary.