laptop hangs when switching video mode

When Ubuntu changes video mode (switching to a VC, restarting, hibernating, suspending, turning off, etc.), sometimes my laptop hangs with a black with some garbage screen. Keyboard doesn't respond (not SysRq, Suspend hotkey, etc.). The only solution is a hard power-off.

This usually happens when compiz has been enabled, and the last message in Xorg.0.log is "XAA: Evicting pixmaps".

I've seen cases where this last message doesn't even get written in the log file when the laptop hangs, and once I've seen more messages written:
***
(II) XAA: Evicting pixmaps
(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) PM Event received: Capability Changed
I830PMEvent: Capability change
Synaptics DeviceOff called
(II) intel(0): [drm] removed 1 reserved context for kernel
(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xf89c1000 at 0xb7b65000
(EE) intel(0): I830 Vblank Pipe Setup Failed 0
***

I'll provide more info if needed.

ProblemType: Bug
Architecture: i386
Date: Fri Jul 20 01:52:56 2007
DistroRelease: Ubuntu 7.10
Package: xserver-xorg-core 2:1.3.0.0.dfsg-6ubuntu2
PackageArchitecture: i386
SourcePackage: xorg-server
Uname: Linux snifer-laptop 2.6.22-8-generic #1 SMP Thu Jul 12 15:59:45 GMT 2007 i686 GNU/Linux

This is the longest log I've seen, but it usually ends with this line:

(II) XAA: Evicting pixmaps

I also saw this bug on Feisty, and can confirm it on gutsy (updated 2 hours ago). I get the "(II) XAA: Evicting pixmaps" entry in Xorg.0.log and the X lockup (but I can ssh in, and alt-sysreq works) as soon as I try to start compiz - which, btw, did work for me until last Friday. I'm only seeing this bug since then. My hardware is a Fujitsu-Siemens Amilo Pi1505 laptop, with intel 945GM chipset, a T2300 core duo, and 2GB ram.

I can confirm I'm also using the intel driver. I'll try later to switch to the i810 driver.

I've also tried switching to EXA acceleration, and now compiz will restart my X server without adding anything to Xorg.0.log.
I used the settings here - http://ubuntuforums.org/showpost.php?p=3017867&postcount=3

Juan,

I actually have two similar bugs reported upstream, see: https://bugs.freedesktop.org/show_bug.cgi?id=10809 and https://bugs.freedesktop.org/show_bug.cgi?id=11432

I recommend you thoroughly read through them, and if you decide the issue is similar, then you can associate your bug here with the upstream version which will hopefully speed up the bug-fixing process.

Sorry for marking your bug as an incorrect duplicate earlier on.

NOTE: The first bug is probably related to your issue, and the second bug mainly focuses on an "instant" crash when closing the lid or pressing the Fn+F8 (CRT/LCD) key - if you are on a laptop I'd appreciate if you could verify that too. I believe the two issues are closely related, however. The common denominator is that all these bugs appeared since the "i810" driver's modesetting code was introduced (in the 2.0pre versions) up to the release of the "intel" driver.

The "XAA: Evicting pixmaps" message no longer appears for me on a clean tribes 4 install. I am now rebuilding xorg-xserver-core as per bug #126425 to see if EXA will work (it now dies as described in that bug).

Conn,

Thanks for pointing me to that bug reports, but none of them are related to this bug. I've not experienced crashes, but only hangs after the "xaa: evicting pixmaps" message. As Jose Bernardo said, the message no longer appears on a clean tribe 4 install, and I'm not sure how to trigger it, so I'm not sure if my system will hang after it appears. Any help on this would be appreciated.

Jose Bernardo,

The 120_fedora_disable_offscreen_pixmaps.diff patch shouldn't change your EXA behaviour.

Video attached to show how the screen looks when my laptop hangs.
I tried pinging and connecting to ssh, but it was not possible.

In an up-to-date fresh tribe 4 install, I've seen the "evicting pixmaps" message, but it looks it has no relation with the hangs (my laptop has hanged without this message and I've seen this message without a hang).

However it looks like the following lines are important:

(II) intel(0): [drm] removed 1 reserved context for kernel
(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xf89c1000 at 0xb7b65000
(EE) intel(0): I830 Vblank Pipe Setup Failed 0

My last hang Xorg.0.log file attached.

I have similar problem with driver i810 after upgraded from Feisty to Gutsy.
The laptop hangs very randomly with the error XAA: Evicting pixmaps in the /var/log/Xorg.0.log log file

Another problem is: I cannot switch to console mode (ctrl+alt+F1) the screen remains blank or with distort images.

The xserver-xorg-core version is 2:1.3.0.0.dfsg-6ubuntu3

@Juan Pablo,
Removing that patch did allow me to use EXA and compiz without any problems.

I'm sorry, you're right Bernardo, for a moment I forgot that that was exactly what was reported at bug #126425.

Juan,

The "evicting pixmaps" message is output from the patch mentioned in my bug #126425. It only appears when you're using the XAA AccelMethod (which is default); when using EXA, the message doesn't appear, but my system (at least) freezes instead. So try not to confuse the issue, as there's other bugs filed related to video mode switching hangs (as I mentioned earlier).

I have the same problem with new Intel driver and i915GM. This happens not on every but on many suspend tries, logouts, console switching and so on.
This doesn't happen with i810 driver so why not change the package to xserver-xorg-video-intel like the external bug reports?
I think that the priority should be higher since the new Intel driver is the default one in Gutsy (https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/135141). If this only happens with specific hardware maybe it this should be excluded but a xserver-xorg-video-intel fix would be better of course.

For whatever reason over the past two days this issue has become mysteriously difficult for me to trigger (I haven't had a lock with the pattern despite over ten suspend cycles in a row). Does anyone know if there's something that mitigates this or has something recently changed? (lspci reports the graphics card is an Intel 945GM/GMS/940GML in this T60)

Added bug #128653 as a dupe, it does the same thing only when seen on macbooks it reboots.

And then a few hours after writing my previous statement I went to shut the computer down and hit the grey block issue. It's still alive and well although it might not manifest until you attempt a shutdown (does doing a VT switch also cause it to occur?)...

I have been experiencing this also. I can usually reproduce it via the following steps.
1) Watch a video in totem
2) Switch to vty1
3) Observe it lock up or repeat 1 and 2 until it does

Here is the video card information from lspci:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) (prog-if 00 [VGA])

The log file attached is after a crash. There is also some detailed information about a "Error in I830WaitLpRing(), timeout for 2 seconds".

Brian has hit the nail on the head with this one. As I am pressed for time I will only briefly outline some steps that eventually (after a few minutes) seem to result in this bug:

Run the following two scripts in separate terminals as a regular user:
while true; do totem /usr/share/example-content/Experience\ ubuntu.ogg; done
while true; do sleep 10; killall totem; done;

Run the following script in a root terminal (i.e. one you have sudo'd to root in):
while true; do chvt 2; sleep 3; chvt 7; sleep 3; done

Now a variety of things will happen:
1. You may get the infamous flashing grey block lockup
2. You may find you VT consoles go funny colours but you can still switch back to X and X appears to be fine.
3. You may find that totem suddenly refuses to play videos and looking in dmesg shows something similar to the following:
no MTRR for d0400000,200000 found
mtrr: no more MTRRs available

I am still seeing this on my MacBook as of the latest intel driver. Anyway, if this doesn't get fixed in time for Gutsy, I figure that Ubuntu should revert to the "i810" driver + 915resolution for hardware that can use it. Is this a possibility if the bug isn't fixed on time?

Hi! Let me insert my +1 here...

Laptop Toshiba Satellite P205, running latest 32bit gutsy
> lspci
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03)
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
> uname -r
2.6.22-12-generic

nothing unusual in xorg.conf, all default

Symptoms: 50% of times I reboot or suspend xorg hangs with random flashing ASCII pseudo-graphics on the screen. Only hard reset helps.

Please tell me if you want tome more info from me (no idea if there's enough samples collected so far... ) Thanks!

I'm still seeing this. My distro is up to date as of Sep 27 10:43 PM EST. I'm able to consistently reproduce this by enabling "Normal desktop effects" and switching to Full Screen and back in vmware server with Windows XP running on it. The only way to come out of it is to press Alt + SysRq + k.

System specs:
Dell D620 2.33 GHz Dual Core, 4 GB RAM, nvidia Quadro NVS 110M (1280x800), using nvidia-glx-new driver. Let me know if you need more information.

Thanks.

Forgot to mention I'm running Gutsy.

@Rengarajan
This bug report is for Intel graphic cards and afaik this bug crashes system completely so only a hard reboot is possible. I guess it is better to create a new bug report for your issue.
Maybe the title of this report should be changed?

Unfortunately, with the latest round of updates it seem my laptop is crashing even more often.

System: Dell Inspiron 510m laptop, 512mb ram, latest Gutsy as of 15/10/07
Graphics: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

What works:
1. Video playback
2. DRI Acceleration / Compiz (using XAA; EXA causes a system hang unless patch 120 is omitted in xserver-xorg-core, as mentioned above by myself and others).

What doesn't work:
1. Switching between VTs (which now causes an immediate, reproducible hang with a blank screen; these crashes were "only" sporadic in the past)
2. Closing the laptop lid (the screen blanks and system freezes just as when switching VTs, immediate and reproducible)
3. Switching laptop outputs (pressing Fn+F8 key combination, i.e. CRT/LCD output switch) causes the same system freeze - again, immediate and 100% reproducible.

I have filed several bugs upstream and here on launchpad, and it seems somehow that (almost) all these problems are connected to the modesetting code; the older i810 driver had none of these problems. I will try to collect some logs, but I cannot ssh into this machine to recover logs at the moment (even though this strategy never worked in the past, not even the magic keys seem to work).

Conn, could you post an Xorg.0.log file from your machine?

For extra information, can you enable the following option in the Xorg config file's "device" section for the video card:

 Option "ModeDebug" "true"

I'd suggest opening a separate launchpad bug, as the symptom is different. Let me know what that bug is (here, by email, or subscribe me)!

It might be related to the problem Claudio is seeing, I think you both have the same card, and it appears there are a couple of other 855 specific bugs out there.

If you have access to a second machine, could you try pinging / ssh into your machine which freezes, as I've heard of at least one other case where after a VT switch, someones machine would appear to freeze, but still be accessible via the network. (In this bug, the machine really does lockup solid).

Anyone still having issues on 855 hardware, please have a look at LP Bug #108056
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/108056/

I'm put online a .deb (and sources etc..) which has debug code for anyone still having issues:
http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/debug/
http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/debug/xserver-xorg-video-intel_2.1.1-0ubuntu9~pcjc2.tst_i386.deb

I've added calls to sync() after every log messge I added, so _hopefully_ some of this will make it to disk if the machine hard-locks, although hardware write-caching on the disk may put pay to that.

You might try disabling that before VT switching with:
hdparm -W 0 /dev/HARD_DRIVE

Those who know how to attach strace from a remote machine will be able to see everything even if the machine locks.

I'd be interested to see log output from this for anyone who still has failures. Please post to LP #108056 if its on 855 hardware though, as I'd like to think this bug is heading towards being closed.

http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/debug/xserver-xorg-video-intel_2.1.1-0ubuntu9~pcjc2.tst2_i386.deb

Incorporates a possible fix on 85X hardware, but is still a debug patch.

If it doesn't fix the problem, please send the Xorg.0.log.

http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/debug/xserver-xorg-video-intel_2.1.1-0ubuntu9~pcjc2.tst3_i386.deb

the .tst2 version didn't workaround the bug very well. This version might.

http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2_i386.deb

A non debug version of the above which doesn't mess up programming the palette like the last ones did. Seems to fix at least one persons 855 based problems, baring seeing the effects in Bug #133118.

Thanks people, this patch seems to work fine!

shutdown grey blocks issue solved for me too (intel 945)
Great !

A big thanks to all of you here that worked hard for solving this bug.

Thank you!

My system hadn't done this for so long that I had thought the problem was resolved for my after installing the update.
However, it just froze again with a black screen when I attempted to restart it.Once I press restart, the screen simply goes to black, without any
indication of the splash screen or other activity, and stays there until
I hold the power button to shut off the computer manually.

It very rarely does this now (it used to do it much more often) so it isn't a major problem, but clearly this big or another is still affecting my system.

My computer is a Dell Inspiron 700m with the following specs:
Intel Pentium M Processor 1.70GHz
1GB memory
Intel 85x graphics card
...I don't know what else you will need...

I found some logs for Xorg /var/log but I'm not sure exactly what you need...they are attached

Thanks for your help.

855GM hardware is known to hit problems which aren't yet cured in the update.

The latest un-released patches I've been working on to cure the crash is in this deb:

http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2_i386.deb

However there are still corruptions to the display seen after resume with compositing enabled.

Peter,

I may open a new launchpad bug (although I'll have to look through my older bugs, as I've reported the same issues before). Having said that, it's appropriate for me to let you know here that using your intel driver deb version 2:2.1.1-0ubuntu10~pcjc2.tst1 seems to have completely solved all crashes when switching VTs. I'll continue testing your package to check if any crashes occur.

I'm posting some logs of my system, including dmesg output - it seems there's some drm warnings/errors, even though DRI seems to initialize and 3D applications (including compiz) work correctly.

More logs:

conn@inspiron:~/i855bug$ glxinfo | grep direct
direct rendering: Yes

conn@inspiron:~/i855bug$ cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size= 512MB: write-back, count=1
reg01: base=0x1ff00000 ( 511MB), size= 1MB: uncachable, count=1
reg02: base=0xfeda0000 (4077MB), size= 128KB: write-through, count=1
reg03: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=1

Peter,

Firstly: With your debug/testing package, my Dell Inspiron 510m laptop still freezes when the lid is closed or the Fn+F8 key combination is pressed - so this is probably a BIOS interaction issue, thus appropriate for another bug report.

Secondly: Although EXA acceleration still doesn't work with compiz, it seems that your package causes the server to restart instead of the previous behaviour noted (i.e., a system freeze). This is positive news, and using a recompiled version of xserver-xorg-core without the #120 patch allows compiz to work perfectly (even when switching VTs). Again, this is a matter for another bug report, but it's relevant for you to know.

Thanks again for your help, and to everyone else who has contributed to this report :).

Thanks for the heads up on patch 120. Looks like I'll have to dig deeper in to the implications for some of the 83 patches applied to Ubuntu's X server!

Just an FYI, my Dell Inspiron 700m (w/ 855) still experiences the problem (when compiz is enabled) with the update posted yesterday the 18th http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2_i386.deb installed. It sounded like the updated version might have worked for some, but not for me. For me I still suspend, resume, try to login, and I just see black, I have to reboot.

Using (or not) the latest patch (http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2_i386.deb) I get a blank screen on Kubuntu Gusty when I close the lid of my laptop Compaq nx6120 with a i810. It does not lock the computer, just makes the screen goes black after a few seconds and totally random (with or without user interaction).

Every time this happens using driver intel on xorg.conf the /var/log/Xorg.0.log shows:

(II) PM Event received: Capability Changed
I830PMEvent: Capability change

when I change to i810:

(II) PM Event received: Capability Changed
I830PMEvent: Capability change
(II) I810(0): Next ACPI _DGS [0] 0x80000410
(II) I810(0): ACPI Toggle devices 0x800
(II) I810(0): ACPI Toggle to 0x800

A lspci, Xorg.0.log and /proc/mtrr is attached I can submit more information if you need.

Hi!

Not sure, if this will help you, but I can confirm this behaviour exactly on a HP Laptop (G 6000 series, G 6050EG) with NVIDIA graphics card with only shared memory.

It happens with the nv as well with binary nvidia driver (from repositorys and from the website).

I think it's related to ACPI, BIOS, IRQ stuff etc. Just guessing.

Very strange for me was, when typing e.g. "ls -la" in an non-graphical VT. By the third time doing this, the laptop would definitely freeze, no Sysrq, nothing. Can hear the hard drive shortly than the fan goes on, then no proof of liffe anymore. Just hard-reboot.

Also it happened when disabling the framebuffer with fb=false vga=normal.

I works for a while quite well when booting with (nosplash) noapic nolapic noapm pnpbios=off pci=conf1 noirqdebug
Sometimes VTs are still messed up, not readable text or just frame buffer "snow" and then freeze again.

Hope this information can help you. I guess this bug is not completely intel-driver-related, as my experience was. Tested also with live-cds from edgy and dapper and on feisty and gutsy installed systems.

Hi Christian,

This bug was very specific to the Intel driver, and has been fixed. If you've got issues with an NVIDIA card, you're seeing a different bug.

Please open a different bug against either the open-source / proprietary driver, depending on which you're using.

Hi.
I have installed xserver-xorg-video-intel_2.1.1-0ubuntu10~pcjc2.2_i386.deb a while ago but my computer still hangs randomly. Is there something else I should try?

I guess you should install the Intel driver from the proposed repository.

Hi!

The bug seems to be back with Intrepid.

Before (in 8.04.1) on my X40 laptop (Intel 855GM) I used i810 driver and it worked ok.

Now, in Intrepid Ibex 8.10 there is no more i810 driver - and so I am stuck with Intel driver.

It already caused me headaches, namely with these random black screen hangs.

However, there is a documented "fix" - it's in the intel manpage, tho not entirely mentioned as a fix to this issue.

What you need to do is:

edit /etc/X11/xorg.conf

and add into the video card section:

Option "ForceEnablePipeA" "true"

then save it, and restart X.

It works over here, as a side (??) effect I get more accurate brightness settings :-)

So try it out and then let the intel devs know about it, just like that manpage says!

Cheers!

PS. The original website I found this on is here: http://ni.imasters.pl/content/ubuntu-804-i965-i-xorg-intel-rozwiązanie-zamrażania-ekranu

There is also another solution to this, so far I find it a bit better.

What you do is:

blacklist video

(add 'video' to /etc/modprobe.d/blacklist)

add nmi_watchdog=0 to /boot/grub/menu.lst in the defopts for kernel, then sudo update-grub.

With ForceEnablePipeA I could not set my brightness correctly (ThinkPad X40). However, with the latter fix mentioned now, that works well, and I no longer suffer from the unreponsive black screen issue.

The glxgears performance is a bit lower than with i810 on 8.04.1, but I guess that's going to improve and besides, glxgears is not a good benchmark :-)

The fix is from:

http://ni.imasters.pl/content/ubuntu-710-oraz-804-i-problem-z-zamrażaniem-ekranu

Okay;

Now, on X40 I have resolved the issues as follows:

1. Add "video" to /etc/modprobe.d/blacklist
2. Add "brightness_mode=2" after "fan_control=1" in /etc/modprobe.d/thinkpad_acpi.modprobe

After these steps (and no other, the nmi_watchdog and acpi_sleep options are no longer necessary in grub's menu.lst as kernel parameters; in fact, no special kernel parameters are necessary; neither is fiddling with PipeA Options in xorg.conf), I no longer have my notebook hanging during shutdown or video change.

Which is what I was ultimately aiming for :) Try these things for yourself (namely, the video).

Cheers,

Hey guys.

I'm new to Ubuntu, but enjoying it this far.

However, I have the problem with my laptop not waking up after hibernating/suspend mode.

It seems you all have managed it all well here, but, in all due respect, this is Greek to me. What can I do to fix this issue?

Thanks!