35

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.

I am using Debian 6.

In this occasion the window title is bad: window title font deranged

Terminal content bad, but title is (still) okay: text is distorted systematically, but only some fonts affected

Improve this question
12
  • 1
    What graphics chip / driver are you using? Distro? Commented Jun 6, 2011 at 13:46
  • 1
    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. Commented Jun 6, 2011 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? Commented Jun 6, 2011 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. Commented Sep 9, 2011 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. Commented Feb 22, 2015 at 22:55

11 Answers 11

Reset to default
15

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: 

xrandr --output DP-3 --auto --output VGA-0 --auto --right-of DP-3 --primary

If you only have a single screen, you could try switching it off and on again:

xrandr --output VGA-1 --off; xrandr --output VGA-1 --auto;

You can see the names of your screens by running xrandr with no arguments. On the system I am using now (one VGA screen), I get:

$ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 VGA-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 477mm x 268mm 1920x1080 60.0*+ 1680x1050 60.0 1280x1024 75.0 60.0 1152x864 75.0 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 60.0 720x400 70.1 DVI-I-1 disconnected (normal left inverted right x axis y axis)

Once you find the right command, assign it a shortcut so you can run it even when the screen is blank.

Improve this answer
6
  • 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. Commented Apr 22, 2015 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. Commented Apr 22, 2015 at 8:06
  • Thanks, that did it for me (getting fancy screen glitches since I started using citrix receiver; that fixed it when all else failed). Note that if you run the command from a different VT on the same computer you may get a Configure crtc 0 failed error; just add a small sleep before the command and switch the VT so it's active when xrandr runs. @Cerin that's probably your issue. sleep 5; xrandr --output VGA-1 --off; xrandr --output VGA-1 --auto Commented Dec 8, 2016 at 21:18
  • Turns out that wasn't really my issue; when switching VTs it appears the windows manager or gnome shell catches up on events and remain unresponsive for some time; the time spent doing these actions was enough to catch up and refresh the screen. OTOH it did help once when I encountered a focus issue where I couldn't click on anything & and keyboard shortcuts were ignored - turning OFF then ON the display fixed it. Commented Jan 8, 2017 at 4:59
  • Is it normal for the above command (for one display) to leave you with a low-res (black) screen with the mouse pointer? If so how do I fix that? Commented Feb 28, 2017 at 11:38
10

In GNOME 3, AltF2renter refreshes the GUI. AltF2 launches the Run Command prompt, and the r command forces a refresh.

Improve this answer
13
  • 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? Commented Feb 18, 2015 at 21:24
  • 2
    @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. Commented Feb 18, 2015 at 22:06
  • 4
    r or restart (it's the same). The console equivalent would be gnome-shell --replace. Commented Feb 18, 2015 at 23:40
  • I run gnome-panel with metacity. Commented Feb 22, 2015 at 20:42
  • @richard, did this work? Commented Feb 23, 2015 at 19:48
7

Did you try the xrefresh command?

Improve this answer
2
  • 1
    Yes, did not work, Commented Nov 15, 2013 at 8:49
  • I will try that next time... FWIW most of the time I get a glitch affecting display, either switching between text and GUI VT's or using the switch user option (which locks one VT and unlock the other) fixes my issues... but on rare occasion it appears only xrandr can fix it. I normally switch VT's using CTRL-ALT-F<n> so I don't have to unlock all the time. Commented Dec 8, 2016 at 21:23
5

I'm having this issue too (Debian Squeeze and Wheezy).

In my experience, it happens mainly when most of the memory is full and the system is using swap memory.

As a partial work-around: if I change the default fonts, the corruption goes away. (Not for good though, I have to change again when the corruption reappears.)

(On Debian Wheezy this is done by gnome-tweak-tool.)

Improve this answer
0
4

Upgrade to Kernel 3.19. – I used the Ubuntu mainline kernel packages, which can be found here:

http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-vivid/ (runs on Ubuntu 14.04 trusty as well)

The following bug report comment mentioned it

https://bugs.freedesktop.org/show_bug.cgi?id=45092#c37

...and tracked down the commit with the following message:

https://github.com/torvalds/linux/commit/656bfa3afc14e45e2d9e1624bf60d79b3beb12f2

“...since we've only ever seen this on gm45 and i965gm.”

I have that Intel GM45 mobile chipset with integrated graphics. The Acer laptop of the OP was also sold with that chipset (not all though).

(It had nothing to do with suspend.)

Improve this answer
3

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.

Problems with ACPI suspend-to-ram - ThinkWiki

If you're using the thinkpad_acpi module that the above quote is addressing, that might be all you need. For more info on this solution, see Suspend2Ram - Powersave Documentation

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.

Debian Suspend and KMS The Debian wiki suggests disabling KMS for a "corrupted video on resume" issue.1

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.

If you think this is related to your issue, you can try disabling KMS as suggested. For insructions for your card see KernelModesetting - Debian Wiki

Debugging Suspend

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.

Some examples and more in-depth debugging info that may help you "drivers that fail to suspend or resume their devices" is available at https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt

Some more debugging ideas for pm-utils at pm-utils - ArchWiki and https://unix.stackexchange.com/a/29090/87728

Here's a full list of Kernel Parameters many being relevant to acpi and suspend.

Good luck.

Improve this answer
5
  • X display is not fine; virtual text terminals are fine Commented Feb 19, 2015 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? Commented Feb 19, 2015 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. Commented Feb 21, 2015 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. Commented Feb 22, 2015 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. Commented Feb 27, 2015 at 19:07
2

This seems to be a reported bug, check the link that follows.

In case of Ubuntu check this link

In case of Debian read this other link specially the Fixing corrupted video on resume part

In case the problem is in a text console: Have you tried refreshing the fonts cache?

fc-cache -f -v

Improve this answer
8
  • Does not help... Commented Feb 22, 2015 at 20:34
  • 1
    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 Commented Feb 25, 2015 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. Commented Feb 25, 2015 at 15:35
  • I have Ubuntu 14.04. Commented Feb 25, 2015 at 16:23
  • 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. Commented Feb 25, 2015 at 16:30
0

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.

Improve this answer
1
  • have tried ctrl-alt-F1 it did not work. Commented Jun 23, 2011 at 12:36
0

The Ctrl+Alt+F1… does not work

Well… then try issuing sudo chvt 1, then switch back to Xorg's vty using Ctrl_Alt_Fn or sudo chvt N (where N is usually 7 or 8). In case chvt would work, you can even try scripting it.

Improve this answer
1
  • sorry I was not clear ctrl+alt+f1 works. It is the ctrl+alt+f1 solution that does not. I can switch virtual terminals, but it does not fix the corruption. Thanks. Commented Apr 17, 2012 at 14:41
0

Try rotating or flipping your screen with xrandr, e.g. upside-down and then back to normal. This might be enough to have it fully redrawn.

Improve this answer
0
-1

Try Crtlalt- then Crtlalt+. That changes the screen resolution back and forth.

Improve this answer
1
  • nothing. May be the keys are not bound. Commented Nov 15, 2011 at 14:53

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.