Resuming after hibernation fails sometimes. After reading the snapshot (the percentage reached 100%), the screen would switch back, but instead the monitor goes black and turns off and the complete system hangs. No ssh or sysreq keys work, everything is dead. Some things I noticed that might help: * It does not occur with nomodeset=1. * You don't need X to reproduce this, just console with modesetting enabled is enough. * It is not reproducible reliably, but the likelyness that it will occur is unfortunately not small (I'd say 3-4 out of 10 attempts). * The fastboot kernel parameter is not related to it. That is all with vanilla kernel. Now enter tuxonice, because it provides more information. Tuxonice reads the atomic copy first (20%..40%..60%..80%->100%). Now, it would switch on tuxoniceui and show the progress for reading in the caches. However, in the problem case the switch does not happen, because the system hangs as described for the vanilla kernel (no ssh, sysreq). At this point, one has to push the reset button to reboot. However, tuxonice has a nice feature: It will detect the image, and that it has resumed from this image before. It then asks the user whether he wants to try resuming from that same image again or remove the image and continue booting. If one presses 'C' to resume from the image, this time everything works and the system is fully functional. In fact, it's a 100% chance that the screen does not get black or the system freezes. The issue does not occur at certain cycles, sometimes three hibernation->resume cycles go well, then the fourth and fifth will not work, then the next four are ok and so on... So, I believe there is some issue with hardware initialization and hibernation. It might be that something does not really finish in time. What could there be wrong? This is with vanilla-3.2-rc5 and 3.2-rc7-tuxonice (see http://git.tuxonice.net/?p=tuxonice-head.git;a=summary), but I guess all 3.2-rc kernels will show the same problem. I had troubles hibernating with vanilla-3.2-final, so I could not test this.
Still reproducible in 3.3-rc1.
I cannot reproduce this anymore in 3.3-rc3, setting resolved fixed.
Ok, just when I thought this has been fixed, the bug strikes back! I still have the same problem and it seems I was a bit lucky that it did not occur until a few days ago. I've tried to investigate further using netconsole, but unfortunately netconsole is of no use here because the network interface is down while reading the atomic copy. The symptoms are still the same, and I cannot reproduce it with nomodeset=1.
As a side note: This does not occur with suspend and resume, only with hibernate and resume. Powering down vs rebooting after hibernating does not make a difference, too.
This problem is still present in 3.3-rc5 (vanilla and tuxonice). > In fact, it's a 100% chance that the screen does not get black or > the system freezes. I have to falsify my previous assumption. It can also happen on the second, third etc. try. But eventually, if you keep trying long enough, it will still succeed to resume. Anyone got an idea what could be wrong here or how to get more info?
The bug is still present with kernel-3.3 final. Further tests confirm that this is an issue specific to the HD6950 card. I swapped the card with a Radeon HD3650 (RV635 chipset) for testing while leaving the rest of the system configuration unchanged, and the problem was no longer reproducible and hibernating and resuming worked fine. If I change the power profile back from low to default, sometimes the system will freeze immediately when hibernating. Maybe some registers still don't get initialized/updated properly?
Still reproducible on linux-3.4.0-rc7.
Still reproducible with 3.4.0 final and "drm/radeon: fix vm deadlocks on cayman" applied, but at least I do not experience freezes anymore.
Still reproducible with 3.8.0.
Solved by setting /sys/power/pm_async to 0.
Reopened because it happens with 3.10 now even with pm_async set to 0. It happens with older kernel releases too when pm_async is set to 0, but is much harder to reproduce.
Just for reference: Since I've never got a response here, I've opened a bug report at kernel bugzilla in the hope of someone helping me collect more debug data: https://bugzilla.kernel.org/show_bug.cgi?id=57381 Since everything's documented there, I'll finally close this bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.