dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
* [Bug 44772] New: Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes
@ 2012-01-14 10:26 bugzilla-daemon
  2012-01-21 15:42 ` [Bug 44772] " bugzilla-daemon
                   ` (11 more replies)
  0 siblings, 12 replies; 13+ messages in thread
From: bugzilla-daemon @ 2012-01-14 10:26 UTC (permalink / raw)
  To: dri-devel

https://bugs.freedesktop.org/show_bug.cgi?id=44772

             Bug #: 44772
           Summary: Radeon HD6950 (Cayman): Resuming from hibernation
                    fails sometimes
    Classification: Unclassified
           Product: DRI
           Version: XOrg CVS
          Platform: All
        OS/Version: Linux (All)
            Status: NEW
          Severity: major
          Priority: medium
         Component: DRM/Radeon
        AssignedTo: dri-devel@lists.freedesktop.org
        ReportedBy: h.judt@gmx.at


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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-07-11 19:07 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-14 10:26 [Bug 44772] New: Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes bugzilla-daemon
2012-01-21 15:42 ` [Bug 44772] " bugzilla-daemon
2012-02-13  0:22 ` bugzilla-daemon
2012-02-19 23:32 ` bugzilla-daemon
2012-02-21 22:13 ` bugzilla-daemon
2012-02-27 19:34 ` bugzilla-daemon
2012-03-20 18:15 ` bugzilla-daemon
2012-05-15  7:47 ` bugzilla-daemon
2012-06-14 22:02 ` bugzilla-daemon
2013-03-12 12:35 ` bugzilla-daemon
2013-05-26  5:35 ` bugzilla-daemon
2013-07-11 18:52 ` bugzilla-daemon
2013-07-11 19:07 ` bugzilla-daemon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).