Freeze

Revision 35 as of 2012-04-14 01:51:22

Clear message

Symptoms

  • X stops responding to input (sometimes mouse cursor can still move, but clicking has no effect)
  • The screen displays but does not update. Sometimes there is screen corruption too, but usually there isn't.
  • Often, X cannot be killed; only a reboot clears the state
  • The system operates fine over SSH but not on the graphical console

  • Error messages such as "GPU lockup" are (sometimes) present in your dmesg output

Non-Symptoms

  • A backtrace appears in Xorg.0.log - most of the time this indicates a crash, not a freeze. Collect a full backtrace

  • X seems to be working, but the monitor appears to just be "off" (See X/Troubleshooting/BlankScreen instead)

  • The caps lock key blinks - this indicates a kernel failure, not X
  • X CPU or memory load is high, making system laggy or freeze up. This usually indicates a client application has lost its marbles.
  • Screen still updates (look at clock), but can't be interacted with - probably is an input bug, not a GPU freeze
  • System freezes for a period but then comes back. Real freezes never come back.

How It Works

In general, most freezes are due to Graphical Processor Unit (GPU) lockups. GPU's have registers that the driver interacts with to produce graphical effects; if the driver interacts incorrectly, the GPU can get stuck and require power cycling to come back.

Some GPU lockups are triggerable and easily reproduced. Others are situational and "tend" to occur with certain programs loaded, certain load levels, or certain periods of time passing. Still others are seemingly random and impossible to tie to any definite set of preconditions. Knowing which of these three classes your bug fits in can provide a clue, as different types of driver errors can lead to the different classes.

GPU lockups are always handled as driver-specific bugs. Typically the source of the error is the handling of memory or command registers, graphics state, or other parameters of the hardware that the driver is responsible for. Often with the open source drivers (-intel, -ati, and -nouveau) the bug requires fixed in the kernel's drm driver, thus many "X freeze" bugs technically are actually kernel bugs.

Reporting GPU lockup Bugs

Reproduce the freeze, and with your system frozen ssh into it (over ethernet) and collect:

  • dmesg > dmesg.txt

  • /var/log/Xorg.0.log
  • /sys/kernel/debug/dri/0/i915_error_state [Intel graphics only]

Important questions to answer in your report:

  • Have you experienced just one lockup, or have you had a series of these lockups?
    • If you've had several, how often does it occur? Every few hours? Once or twice a day? Couple times a week?
  • When did you first notice it?
    • Shortly after upgrading?
    • After updating?
    • After changing compositing (Desktop Effects) settings?
  • Under what conditions does it seem most likely to reproduce?
    • Only at boot time?
    • When resuming from suspend or hibernate?
    • Only when using compositing (Unity, et al)
    • When changing resolution or enabling/disabling monitors
    • When the screensaver (or power saving mode) kicks in
    • Visiting particular web pages or loading particular files
    • Switching between desktops
    • When performing a specific sequence of actions (List them!)

Problem: New hardware freezes

With the open source drivers, support sometimes lags hardware availability a bit. In some cases, basic support is available in Ubuntu, and then by the next release much more complete support is available, but it's buggy for certain hardware combinations.

In these circumstances, a good place to start is to test newer upstream code. First test newer kernels, then test newer X components:

If you find a newer kernel version that works, include this fact in your bug report and it may help the maintainers locate the hardware support patches necessary. If you want to be particularly helpful, you can do a bisection search to find exactly when the needed support landed for your hardware.

Problem: Solid white or purple screen after logging in

In general unexpected whiteness on the screen tends to point to a compositing issue. Try disabling compiz, or try disabling DRI in your xorg.conf.

In recent Ubuntu versions, the early boot process sets the background to a shade of purple before starting up X. So a frozen purple screen can indicate a failure getting X up and running.

Problem: Freezes occur when idle and screensaver is set to random settings or OpenGL

A lot of freezes occur in the 3D code, and go unnoticed by users that don't otherwise use 3D stuff, except when an OpenGL screensaver activates.

One common situation is when the screensavers are set to "random", and allowed to mix in OpenGL 3D screensavers with the regular 2D ones. Not all 3D screensavers will trigger the freeze, and some will trigger it only a portion of the time.

An obvious workaround would be to set the screensaver to blank screen (or avoid the problematic OpenGL screensaver).

Problem: Freezes when screensaver or video player changes DPMS settings

Display Power Management (DPMS) allows controlling the standby, suspend, and off time for your video monitor. Various software apps utilize this to do things like prevent the screensaver from turning on while watching a movie, or to power off the monitor after it has been idle a while.

Freezes that occur when the machine has been idle, that aren't due to OpenGL screensavers, may indicate bugs in how DPMS is working. Freezes that seem associated with exiting applications or switching to or from full screen, can suggest possibly the app tried to poke at DPMS and triggered a bug.

You can manually invoke and control DPMS using the xset command line tool: 

 sleep 1; xset s activate

Or to turn the screensaver off: 

 sleep 1; xset dpms force off

You can also use commands standby, suspend, or on instead of off.

Another workaround is to disable DPMS in xorg.conf, by adding an option to your Monitor section: 

Section "Monitor"
...
        Option  "DPMS" "Off"
EndSection

Problem: Freeze began after a system update

Regression bugs that freeze the system reliably are ironically the most productive to solve.

If you updated your system and it started to freeze, start reverting package updates backwards until the freezes stop occurring.

The first thing to try is booting an earlier kernel. Hold down the left shift key during boot, so that the grub bootloader menu comes up. Look through the set of available kernels for one you used prior to the update; boot that and attempt to reproduce the freeze. If it does not freeze, then you now have a "Good" and "Bad" kernel and can proceed with a kernel bisection search to isolate what patch caused the failure. (Yes, compiling kernels sounds intimidating and time consuming, but stick with it - the process is well documented and it has a *very* high likelihood of narrowing it to a specific cause!)

If booting an earlier kernel didn't do the trick, /var/log/dpkg.log lists other packages it has updated in date order. Older versions of debs are often cached for a time in your /var/cache/apt/archives/ directory, or can be located on launchpad with a little digging. Go to https://launchpad.net/ubuntu/+source/<suspect-package>/, click on "View full publishing history", find and click on the version you want, under Builds click on the appropriate architecture for your system, then under "Built files" download and install any/all .deb files you need.

While a variety of packages *might* cause a freeze regression, the most likely culprits are: kernel, mesa, libdrm, xserver-xorg-video-[intel|ati|nouveau], xorg-server, compiz, unity, nux, and kwin. Generally you can rule out anything not graphical or X-related in nature.

Stock Reply for "random freeze" bugs

Thanks for reporting this bug and helping to make Ubuntu better. What you have described is a generic X freeze. It could be caused by any number of things, and you need to take some additional steps to provide a complete report.

When did you upgrade to this version of Ubuntu? When did you first notice the freezes occurring?

How frequently do the freezes occur? How many per day would you say you experience?

List the applications you typically have open at the time of the freeze.

Think back to the last few times it froze. What activities were you doing in each of those times?

Do you have compiz enabled? Does the issue go away if you disable it?

If your system is a laptop, do you suspend/resume it? Had you resumed at some point prior to the freezes?

Finally, and most importantly, please collect a GPU dump after reproducing the bug. Packages to install and directions for doing this are available at:

With the GPU dump in hand, we will be able to upstream this bug.

For more tips on troubleshooting freeze bugs, please refer to this link: