When I restore from hibernate the screen is often corrupted. I suspect the graphics memory is not being saved. Suspend-to-ram works fine otherwise.

It also looks like the font-cache is corrupted, as all letters are corrupted consistently. The effect seems to target a font at a specific size. E.g. if my terminal window is hit, changing the font and/or the font size will fix it, unless that font with that size is already damaged.

If the font is used elsewhere (other apps, window manager, etc.), then the problem is there as well. Sometimes the font used for the window titles is hit, then all window titles show the same letters corrupted.

Logging out and back in again fixes it, but I don't want to have to do that. I have been logging-out then hibernating, but this is more effort and eliminates most of the benefit of hibernate.

Is there another way to refresh the X11 display? The Ctrl+Alt+F1… does not fix it either. It switches terminal but does not redraw anything: It just shows the old corrupted screen.

Debian 6, acer aspire 5338 integrated graphics. I have had it working in Ubuntu, and suspend to ram works excellent. I suspect it us just not saving graphics ram to disk.
–
richardJun 6 '11 at 15:19

1

That doesn't quite answer the question since that model seems to have been shipped with Intel, Nvidia, and ATI video card options. By "integrated" do you mean yours has the Intel GMA video card?
–
CalebJun 6 '11 at 15:47

It's not clear from what you said - have you tried doing ctrl-alt-F1 before hibernating (i.e. hibernating from text mode, and only switching back to X11 after resuming) ? you may need to find out the command to hibernate from the command line.
–
Random832Sep 9 '11 at 16:47

1

I have updated to debian7, it now works. @terdon the screen shots added to question, look similar to what I had.
–
richardFeb 22 at 22:55

I had a similar situation with my laptop. The screen would often remain black when it woke from suspend. My solution was to use xrandr to reset my displays. You need to find the xrandr command that sets up your layout and run that. For example, on my system, I had two screens and this set it up as I wanted it:

I don't see how this could work. You get a black screen and have no interface...but you run a command? How? Doing alt+Fn won't work because even all X commands throw the error "Can't open display". Trying the export DISPLAY=:0 trick just results in a different error.
–
CerinApr 22 at 4:50

@Cerin on my system, I've assigned a shortcut to that command so I can run it blindly by hitting Alt + F.
–
terdon♦Apr 22 at 8:06

That sounds like you could also run r from the console. I have no r installed. – What should that run, you say? I.e. which package? What is the full name of that r program?
–
Robert SiemerFeb 18 at 21:24

1

@RobertSiemer that's not a program, it's an internal GNOME thing that restarts the DE. I am guessing it runs gnome --replace in the background but I don't know.
–
terdon♦Feb 18 at 22:06

2

r or restart (it's the same). The console equivalent would be gnome-shell --replace.
–
don_crisstiFeb 18 at 23:40

If a driver is failing to resume a device properly, then I believe the only solution you will find will be in debugging and identifying where the problem is so you can decide what to do from there. For example, I don't see how you can refresh if the video card is not reinitialized.

ACPI handles suspend/resume and display. For example, the following ACPI issue that occurs on some ThinkPads may address the symptoms your are describing:

When resuming from suspend-to-ram the text console displays may show
garbage instead of actual text. The machine is otherwise still
responsive and X displays fine. If all of this is true, then adding
the kernel option acpi_sleep=s3_bios,s3_mode in your menu.lst or
lilo.conf may solve the problem.

First, there are several kernel parameters, that can be tried out.
Just add them to your "kernel"-line in /boot/grub/menu.lst. More
information about those can be found in
/usr/src/linux/Documentation/power/video.txt.

From video.txt:

During S3 resume, hardware needs to be reinitialized. For most
devices, this is easy, and kernel driver knows how to do it.
Unfortunately there's one exception: video card. Those are usually
initialized by BIOS, and kernel does not have enough information to
boot video card. (Kernel usually does not even contain video card
driver -- vesafb and vgacon are widely used).

More at video.txt Refer to the table here to see if a known acpi_sleep=<hack> is listed for your video card model.

A very common issue found after the computer resumes is corrupted
video (or black screen, or no LCD backlight). The first step is to
check whether the system is still running, which can be simply done by
pressing the Capslock button and check whether the Capslock LED is
changing accordingly. If the system is still running, in most cases we
need to add a video quirk for your video card.

Debian now has kernel mode setting (KMS) enabled by default for most
Intel, nVidia and ATI video cards. But pm-utils' video quirk does [not]
support KMS yet. So in most cases you should try disabling KMS first.
The detail steps for your specific video card can be found on the
KernelModesetting page.

After disabled KMS, if the video after resume still corrupts, you can
try to suspend the system by using some video quirks. Read the manpage
of the pm-suspend program for a very detail explanation of all the
quirks available, and try the combinations of them from commandline.
If you successfully find one combination of quirks that works for your
system, you can add them into /usr/lib/pm-utils/video-quirks to make
them permanent. At the same time, please help to file a bug against
the pm-utils package with a patch about your changes so it can benefit
the mass.

A common issue found on systems upgrading from old versions of Debian
is the enabling of quirk-s3-bios freezes the system during suspend. If
your system freezes during suspend, check the pm-suspend.log carefully
after enabled debugging and make sure quirk-s3-bios is not used.

The log of suspend and resume processes are in file
/var/log/pm-suspend.log. It contains moderately verbose information by
default. More information can be enabled for debugging by inserting
line export PM_DEBUG=true into the beginning of file
/usr/lib/pm-utils/pm-functions.

For more, check out the info on Kernel testing facility mentioned at Suspend - Debian Wiki as well. This can help you debug and isolate the problem.

X display is not fine; virtual text terminals are fine
–
Robert SiemerFeb 19 at 16:25

Did you check /var/log/pm-suspend.log? Did you enable debugging in /usr/lib/pm-utils/pm-functions and check it after that?
–
iyrinFeb 19 at 16:56

You can test suspend with quirks from the terminal using pm-suspend --quirk-s3-bios --quirk-s3-mode. See the options section in man pm-action.
–
iyrinFeb 21 at 16:51

I checked /var/log/pm-suspend.log. Nothing unusual. I’m using KMS. – Disabling KMS is no option these days (xorg intel driver needs it); that wiki you pointed to was last updated 2012.
–
Robert SiemerFeb 22 at 22:08

Just want to say that dmesg | tail -50 command can be useful for debugging. I actually discovered low memory corruption related to suspend that I was able to resolve with kernel parameters in grub memmap=64K$0 memory_corruption_check=0. I believe it will tell you if there is an error initializing the video card.
–
iyrinFeb 27 at 19:07

This is almost certainly because the graphics driver has bugs for the display device. It probably won't matter too much which it is, because either way it's not something you can likely fix. But you should file a bug about the kernel driver for the device (once you figure out what it is (lspci may help here)).

Something you could try, though, as a work around: when coming out of hibernate, try hitting "ctrl-alt-F4" to switch to another virtual terminal and then switching back (which is likely either ctrl-alt-F1 or ctrl-alt-F7 or maybe F8). This may do enough of a screen refresh that it'll make the display recover. Maybe.

This seems to be a reported bug, check the link that follows. If your distro is not Ubuntu, the bug may not be specific to a distro but some libraries that may affect other distros. Dig into the bug/s and see if it is solved for your distro... bugs.launchpad.net/ubuntu/+source/linux/+bug/659434
–
YoMismoFeb 25 at 15:33

Sorry I didn't see your distro was Debian. Check the next link: wiki.debian.org/Suspend specially the Fixing corrupted video on resume part.
–
YoMismoFeb 25 at 15:35

OK, question stated "I am using Debian 6." before the first screenshot. Then I guess you will find your answer in launchpad's bugs... Anyway, Ubuntu is based on Debian so maybe a solution from the Debian's link can help you out.
–
YoMismoFeb 25 at 16:30