http://bugzilla.kernel.org/show_bug.cgi?id=12155
------- Comment #19 from [EMAIL PROTECTED] 2008-12-10 00:25 ------- (In reply to comment #18) > right, two problems here. > > Problem 1, long latency when resuming from disk. > Problem 2, suspend to disk failed after two successful try. > > Fabio, can you verify if the first problem can be reproduced in 2.6.27.8 or > the > latest 2.6.28-rc release? > Well, it seems that there is some communication problem between me and you kernel developers. Sorry about that but I'm not an English native speaker and probably I didn't make myself clear enough. Let's try to summarize. The system _never_ had problems during resume. It always resumed correctly. The main problem is that after a successful resume from disk, when userspace has already been up and running (i.e. I am usually able to unlock my gnome session), sometimes the system freezes for about 4-5 minutes. After that the laptop usually "revives" (I don't known how to explain differently, sorry). It usually does it without printing anything in the logs (post #16 is an example of that). Tejun, the delay before the HPET line is present in every hibernate/resume cycle, good or bad. Only two times there were some lines in the logs that pointed to ATA, as in post #10 quoted by Zhang Rui. In this post you can see that ATA froze _after_ userspace was done, i.e. after the line "Restarting tasks: done". Only once ATA did not come back and the disk was gone. My rootfs journal aborted and my laptop was totally unusable. I had to powercycle it and go through a full fsck. Of course, I don't have logs for this, I just read those information from a dmesg command output. Let's try to summarize the facts so far: * the latency problem after resume (after, not during) is present with every stable release between 2.6.27.5 and 2.6.27.8 included. It never happened with .4; * it's present in every 2.6.28-rc I tried and it's also present in current mainline; * it's also present if I use Tuxonice instead of in-kernel hibernation; * it can be reproduced with and without fglrx / cisco_ipsec binary only modules (without fglrx the kernel was compiled to support my radeon card and the xorg.conf file has been modified accordingly); * my hard disk survived a smartctl -t long test without problems; * windows on the same laptop (dual boot) does not show the problem and a full hd test that I ran on Windows completed succesfullly. The log in post #14 is in my opinion a separate issue as the system refused to suspend; this happened only once and I did not want to lose those information. If something is not clear enough, please ask. Thanks to all of you for your time, Fabio -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ acpi-bugzilla mailing list acpi-bugzilla@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
