Find the answer to your Linux question:
Results 1 to 8 of 8
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1

    Question Hibernation resumes with scrambled picture

    Upon resume from hibernation, everything works fine except the screen. It either stays black, or is filled with various amount of colourful stripes.

    I am running Nvidia proprietary drivers (nouveau not an option due to poor power management) and TuxOnIce.

    Does someone know how to fix that?

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    I assume it works ok with a reboot? Check the man page for pm-suspend and the config files in /etc/pm/config.d, etc.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Linux Engineer
    Join Date
    Apr 2012
    Virginia, USA
    I have a similar problem with an Nvidia GeForce 9600GT M. My laptop also displays artifacts in Windows after resuming from Hybernation, I've tried various drivers in both operating systems to no avail.

    What works for me is to open a virtual console by pressing ctrl+alt+f2, and restarting the desktop manager.
    sudo service gdm restart (for gnome)
    sudo service mdm restart (for Xfce)

    I'm sure there is another command for the other desktops, but those two are the ones I use.

    Update: Oh yeah, sometimes I have to do this twice in a row, sometimes just once.

  4. $spacer_open
  5. #4
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    When I have had this problem in the past, sometimes just switching to another console (ctrl-alt-f2) and back to the GUI will also work, without needing to restart it. A PITA, but quick (two combo-keypress operations).
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  6. #5
    Ok, here's some extra info:

    1. Yes, reboot and resume from suspend work just fine.
    2. Resume from non-tuxonice hibernation also works (except it takes 5 minutes vs 20 seconds of TOX resume because of some other unexplained bug, but that's not the point of this thread).
    3. I am on systemd and TuxOnIce. pm-utils is removed.
    4. Switching consoles does not help.

  7. #6
    There have been some issues with higher end intel-based integrated graphics cards on laptop motherboards when hibernating in linux, most commonly with gentoo and ubuntu flavors. My thoughts rest with one theory: typical integrated hd graphics cards utilize nested paging of the processor since they lack their own dedicated processing unit,and intel-based graphics cards seem to want to save some of the graphical thread information into the hibernation file for later reloading. Most simple operating systems don't like to restore written values to integrated graphics cards from what it might perceive is a truncated thread, or simply because rebuilding graphics threads from a program that was utilizing them can be a bit tricky, even for a computer (kind of like trying to decompile a C program, pretty ugly even for a "hello world" program), and it doesnt help that the video memory is shared with the rest of the ram that is being saved during hibernation, and the os might not see the difference between what was used by the gpu. When it does happen, an anomoly occurs in the display of the clashing graphical information, which takes the form of malformed and jargled streaks and splats of random colored pixels. This might even temporarily occur with a dedicated graphics card on a desktop pc from a cold boot during the os loading splash screen (my older brothers ubuntu desktop does this for some reason, but corrects itself rather quickly).

    Simply put, linux is doing its job by loading the hibernation file to the memory, but the shared video memory is also loaded, and it might not even be getting loaded in the right sequence, or that what is being loaded as video might not even be video memory at all. None of my AMD systems ever have this issue, not even my laptops, but that doesnt exclude AMD from this bug...i just submit that intel-based hardware seems to have more issues being reported than AMD.

    My suggestion is because you cannot correct this, try avoiding the use of hibernation. It means you're going to experience longer boot times because it is a full cold boot, but at least the display will be correct all of the time instead of never (or most of the time if I'm mistaken on the rate that it occurs). I know hibernation is conveinient with laptops as opposed to a real shutdown, but if it ain't gonna work, just go around it.

  8. #7
    Ok, but there are two things your post does not seem to consider:

    1. I have Nvidia dedicated graphic card, not intel integrated card (though I am on core 2 duo).
    2. Hibernation does resume with proper picture when using non-TuxOnIce hibernation method (even though has its own issues unrelated to this problem).
    3. Hibernation works just fine in windows, each and every time.

  9. #8
    Nvidia Graphics cards are intel-based hardware; Intel owns Nvidia, and AMD own ATI (now its just AMD graphics cards). Therefore, your GPU is Intel based (there's a reason why mixing intel and AMD processors with opposite GPU hardware tends to create problems).

    You didn't specify that your GPU was dedicated, so typically that leaves the assumption that it is onboard graphics. Proprietary graphics drivers that are enabled in Linux don't imply dedicated PCI graphics cards, and I can attest to this as my laptops have to enable these proprietary drivers in Ubuntu when I installed the OS on each of them (intel and AMD laptops as well as a gigabyte AMD motherboard with onboard VGA).

    It might help shed some light to know which Nvidia card you are using in case it is one to be known to cause issues with certain software/configurations, as well as if your BIOS settings are set to detect the PCI card first instead of onboard (if available) when rendering a display during POST. My friend's Desktop was running an AMD motherboard with AMD onboard shared video controller, and he had an Nvidia GeForce 9000 series that he used for his monitor display, but it was always bugging out on him every so often, and never went to full 1080p (which it's supposed to), and he was running Windows 7 at the time. The conflicting AMD and Intel hardware was the problem, so I traded him an older ATI Radeon HD 6450 card for his Nvidia card, and changed his BIOS settings to use the PCI card only as a display adapter, and his troubles were gone.

    Keep in mind also that anything proprietary is getting redesigned everyday to close off support to free and open communities (Apple is a great example of this), so naturally Windows is going to do just fine as the drivers are specifically designed to work properly in this environment, whereas in Linux we have to rely on our community to develop a way to load and run these proprietary drivers in a Linux environment with the kernel version being run; we are bound to run into problems.

    But since the theory I sided with relies on the issue being the GPU/hibernation resume build, I am still open to the possibility that maybe it's an issue with TuxOnIce's own hibernation sequences, in which case my recommendation still stands to just avoid using hibernation to avoid the hassle. You say you have a dedicated card, so I am going to say you are likely using a desktop and not a laptop (although there are some laptops that actually have both integrated and a dedicated GPU), but then again, it is not very common to have a desktop motherboard that is going to have hibernation enabled by default unless you change that setting (my Windows OS allows it if enabled on my high-end PC, but my 12.04 Ubuntu won't offer me the choice for some reason on the same machine). If I am to assume you are using a desktop, then hibernation is not really an effective choice in this case. I don't see why anybody would want to use hibernation on a desktop, since it is still going to be fully powered off (except any USB sleep-and-charge ports), and the boot time difference between a full cold boot and a system resume from hibernation are not far apart enough on a desktop to warrant the need or desire to favor hibernation. If a quicker boot is desired because you want to avoid running it all the time and reduce power consumption, then you may consider using 'suspend' or 'standby' (different than sleep, it actually goes into a low power state, which requires more than just moving the mouse to resume) instead.

    If you surprisingly have a laptop with this, then I can understand why you really want hibernation to work. It may just be TuxOnIce, it may the fact that your computer has an integrated graphics card and a dedicated card, so the dedicated card threads are getting saved and reloaded to the integrated card, so you may want to go into BIOS and switch the usage preference to the dedicated card (beware that the dedicated cards on laptops almost always require AC power to the laptop in order to use them because they drain the battery too fast). If this is the case, remember that if you are suddenly having to switch from AC to battery when hibernating, then you will encounter this issue when the gpu's flip over due to your AC/battery states changing, so the threads will likely get sent to the wrong card. This can also be the case in desktops if the BIOS is not set to use the same card each time, so hibernating from the dedicated card and resuming on the default card (usually the integrated card) would also cause this little problem if the cards are vastly different in size, cache, hardware, and memory type (system RAM for the integrated vs whatever the dedicated happens to have on it).

    So I do concur that I did not consider a couple of details before posting, but that is due to your lack of given information. Please be sure to give as many details as possible when posting for how to resolve issues, especially in Linux forums. I can't tell you how many people I've seen give a simple one-liner with almost no details of their system, and like 4 or 5 posts later it becomes evident in the details that the issue was easily resolved, but lacked the info to know what was going on. It is always good practice to state your system hardware and specs, OS type and version, and any software that is usually running when the issue occurs, not to mention very specific details and observations of what happens before, during, and after the problem. Also sometimes it can help us understand the scope of an issue when we know if certain things ARE behaving properly before, during, and/or after the problem occurs, which helps narrow down the root of the problem.

    Without any more info, and being left with my assumptions, I cannot hazard any other guesses as to why it is occurring (there can be many differing reasons, both hardware and software problems are possible for this), and more importantly, I can't help you figure out how to solve the issue yet.

    When it comes to Intel/AMD specific problems, I tend to have better results in the AMD area, but I do have a good friend who is an Intel whiz, so I can consult him tomorrow after I get some more info. Although he is not much for Linux, and I don't know why, but I'm sure he has seen this issue happen before and he may have more insight that could help me help you.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts