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?

I found this bug report with a patch that is supposed to solve the problem. I haven't had time to test it myself yet.

https://bugs.freedesktop.org/show_bug.cgi?id=10809

/Björn

Thanks unggnu. I will open a new bug.

I have made a debdiff from the Xorg patch for Gutsy. It seems to work but I haven't made so many tests and I still don't know why I haven't this problem with i810 driver.

@unggnu: please can you attach a complete deb package with your diff? I would like to try it with my i810 which is affected by this frustating bug. Thank you

I don't know if it is allowed to upload such big files and self compiled deb packages.

netbear and unggnu, good work chasing down the patch for this! I've incorporated it and uploaded it to Gutsy for xorg-server 12ubuntu8.

[Note, we generally put patches into the debian/patches dir rather than applying them directly - I'll attach the corrected .debdiff for reference.]

Also, to answer the question about .debs, generally people don't put .debs into launchpad. I suppose it'd bloat launchpad's database if it was done frequently. But no harm done in this case. I'll be happy to help with .deb hosting if needed - find me on #ubuntu-x on Freenode, or drop me an email.

Anyway, great work everyone! I think we can close this bug. Please test against latest updated Gutsy with 12ubuntu8 and report here if the issue is not fixed.

I've tested unggnu's package by following steps at <https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/127101/comments/22> and the bug is still present, however I'll wait to test 12ubuntu8 before reopening this bug.

In a first test attempt, I didn't get the gray blocks lockup, but X was frozen the same way (only hard poweroff was possible). I'm attaching this Xorg log.

In a second test attempt, I got the gray blocks lockup. In this case, Xorg log has nothing special. Last lines are:

Synaptics DeviceOff called
(II) AIGLX: Suspending AIGLX clients for VT switch

The gray block issue is gone but there is another one which isn't so bad. I have posted it some time ago under bug #141063.
If you change to console while using xv, xv is broken and after some time, when xv is freed system hangs. Since this happens not so often (most cases only on suspend) it doesn't affect so many people like the old one.

Sorry for this silly question: how can I help testing the fix? Thanks.

Fix has been released, so you can get fixed version using update-manager.
I've seen the gray blocks hang after installing the fixed package, but, as unggnu said, it's because of bug #141063 (xv related).

This particular bug (which happens even without xv video playback) has been fixed.

Reopening since, unfortunately, I'm still able to reproduce this bug.

Steps to reproduce:
1. Disable desktop effects and enable desktop effects again.
2. Switch to VT1 and switch back to VT7.
3. Repeat steps 1 and 2 several times.

This bug is different than bug #141063. In the other bug, it was just a freeze, and I was able to get a backtrace through ssh.
In this gray blocks hang bug, I'm not able to get a backtrace since once the laptop hangs not even networking works.

I'm attaching Xorg log when trying to get a backtrace.
Last lines from gdb output (where SIGUSR1 is switching VT) are:

(gdb) continue

Continuing.

Program received signal SIGUSR1, User defined signal 1.

Program received signal SIGUSR1, User defined signal 1.

Program received signal SIGUSR1, User defined signal 1.

Program received signal SIGUSR1, User defined signal 1.

Program received signal SIGUSR1, User defined signal 1.

I can reproduce this using Juan's steps, even running -12ubuntu8. I've attached a Xorg.0.log for one of the crashes I reproduced, but there doesn't appear to be any relevant errors. Let me know if there's anything else I can do to help debug this.

Confirming: the problem persists with the same symptoms. Just random hangs on suspend... but thanks for the efforts!!!

I've seen the same gray blocks hang after a couple of suspend/resume actions. Also, xv video (mplayer, kaffeine/xine, etc) stops working after the first suspend, giving a blue frame, and sometimes triggering the gray blocks textmode hang.

I do not know if anyone knows of this but have you tried the following:

for Ubuntu:

Type in a terminal :

sudo gdmsetup -> In the general tab tick the "Restart the X server with each login"

for Kubuntu:

you've got to add or uncomment the line

TerminateServer=true

in the [X-:*-Core] section of the kdmrc-File (/etc/kde3/kdm/kdmrc) - beware of the ':', there is a similar named section without it, too!

Seems to work for many.

For Gutsy users, the newer gdm always restarts X. The following report has information on that:
http://bugzilla.gnome.org/show_bug.cgi?id=326771

But this can be reproduced without any logging out though anyways (see Juan's three steps for reproduction).

Possibly related bug:

https://bugs.freedesktop.org/show_bug.cgi?id=12666

Using xf86-video-i810 v1.7.4 (which is the REAL i810 driver, not the generic intel one) fixed the hanging bug for me.

As far as I have experienced, the intel driver corrupts X memory then X drops mouse and keyboard - making the system unusable

Please spread the word that xf86-video-i810 v2.x (which actually uses xf86-video-intel code) is NOT stable

@ legolas558
I don't know what you mean exactly by "intel corrupts X memory" but I sometimes experience image corruption (on screen) looking like damaged scan-lines for desktop wallpaper and images in firefox. Same artifact for mouse selection rectangle (transparent) on desktop.

@everybody
I'm not able to use i810 driver as it's unable to set any mode. Native resolution is 1440x900.

@TDB
sorry I am almost 'blind' in trying to find the cause of my bug - the fact is that X's mouse and keyboard stop working and I can get back control of the PC remotely or switching to a shell (which is not always possible).

@everybody
The bug still happens with the old i810 driver, so the intel driver is definitively not the cause. It just happens more rarely and you can use the system for a few minutes...seems that tooltips do trigger the hangup.
Sorry for the previous misleading informations

My problem was related to gtk+ 2.12; with older versions it gets fixed. Sorry, I think mine was another bug

I've tested this on a freshly reinstalled Intel 945 based laptop, but am unable to reproduce the behavior (but I've had Gutsy running on it since tribe 1, and never saw the original behavior).

It sounds like there may actually be several separate bugs that can lead to this same behavior more or less. Unfortunately that will make it pretty tough to determine for certain when it's fixed. Juan Pablo specified exact steps for reproducing the situation that then results in the blinking gray boxes he showed in comment 11. If you have a behavior that seems similar but cannot be reproduced with those steps, or does not display screen corruption and lockup, then assume you have an unrelated bug and enter a new report. We can always dupe them together later.

I notice this bug upstream, with a similar error trace as Brian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437207
Interestingly, while the reporter was running a debian system, they were using a Ubuntu kernel. Hmm...

I also found this report which also has a similar error trace:
http://readlist.com/lists/lists.freedesktop.org/xorg/2/11900.html
For this one, it sounds like the issue turned out to be a DRM issue.

In any case, on the off chance that there's already a fix for this issue, I packaged up the current git head of the intel driver: http://people.ubuntu.com/~bryce/Testing/intel/. Would someone mind trying this one?

@ Bryce Harrington
Testing your latest build... So far so good. Trying to make it fail. Neither OpenGL nor XV seems to have no relation to it.
However OpenGL acceleration broken (via Mesa) with the latest build... Need more time, I guess ...

Thanks.

The GLX-related line from xorg.0.log is:
(EE) AIGLX error: drmMap of framebuffer failed (Invalid argument)(EE) AIGLX: reverting to software rendering
Other than that the build seems to be OK... Anyone else testing it?

I still have the problem with the gray blocks but only if I have used XV this session at least it seems so.
Another interesting point is that I haven't this problem if I use an external monitor (VGA) and have LFP (LVDS) disabled with xrandr. Even bug #141063 doesn't happen but there is another issue with dark video colors after switching to console and the video overlay is on top. The dark video color problem could be fixed through closing video an reopening it with Totem but not the overlay on top issue. This needs an x restart.

On bug 133118 (also testing this git head driver), they noted the loss of acceleration. Ideally, if it fixed the issue we're interested in, we'd extract the fix and leave out whatever causes the acceleration loss (unless the latter is what resulted in the former).

From the replies I'm uncertain if you guys feel this -intel improves the situation with the gray blocks (aside from any new issues that might come up)? If it does, then it may be worth also testing individual patches; if not, then I don't want to waste anyone's time testing them.

unggnu, since you say you're still seeing gray blocks, I assume the problem is not fixed by this.

Earlier on there was mention of patch 120 in xserver; here is a .deb of xserver with that patch dropped, which might be worth testing: http://people.ubuntu.com/~bryce/Testing/xorg-server/

Hi, I tried the git xserver-xorg-video-intel package, and I can also confirm that DRI is not working with this package. Here is the error:
libGL error: drmMap of framebuffer failed (Invalid argument)
libGL error: reverting to (slow) indirect rendering
Perhaps Ubuntu's libdrm or drm kernel modules aren't recent enough for the git package?

I also tried the xserver-xorg-core package with patch 120 dropped. The rectangle crash is still reproducible using this package using Juan's steps. (Also, the problem that patch 120 fixes is reintroduced.)

Bryce,
I'm still building my own xserver-xorg without patch 120, and it doesn't fix the gray blocks hang. It allows me to use EXA acceleration, and forces people that still use XAA to add 'option "XAANoOffScreenPixmaps"' to xorg.conf, but I think that is all.
I also can reproduce the crash, and have seen it some times during suspend.

Okay, thanks, then 120 is orthogonal to this issue.

Jeff, can you explain why you suspect libdrm or drm kernel modules? I suspect this as well due to the mailing list discussion I pointed to, but don't have any hard data.

Bryce

It is kind of weird. I couldn't get the gray blocks anymore through switching to console or use suspend but after xv use and running laptop some time on shutdown I got them again several times (always without connected external). Maybe it is random that nothing happens so some more tests are needed to nail it down.

@Bryce Harrington
I'm running the git-latest intel driver for 2 days already and can NOT crash it. DRI is not working for me (due to whatever reason) and I think DRI has to do with the gray-blocks crash.

I'm trying to get as deep as I can in gdb, but I don't have much time to play with this, so if someone is interested may be I can get some help ;) (or may be it's not useful, just let me know).
gdb output attached. I'm using xserver-xorg-video-intel_2.1.1~git20071004-0ubuntu1_i386.deb, so no compiz.

Steps I did to get this gdb output:
1. Clean boot, no compiz.
2. Try to set normal visual effects in gnome-appearance-properties, but it's not possible.
3. Switch to VT1, switch back to VT7.
4. Attach X to gdb through ssh.
5. Play ~/Examples/Experience\ ubuntu.ogg (totem + xv).
6. Switch to VT1 while video is playing.
7. In gdb, when SIGUSR1 is detected, get a backtrace full, then try to finish all frames. After the last finish command, you can see the gray blocks, and networking hangs.

May be we can get deeper if we do steps instead of the last finish.

Gray blocks are always reproducible through playing a video with xv, close it and directly switch to vt. I wasn't able to crash system without using xv. Testing it several times with running compiz an glxgears. Maybe this was fixed through the patch.

The worst thing is, that it crashes on logout from session after having played a video. I do not have compiz enabled. So intel driver is at the moment unusable.

Ok, here's a backtrace in the last step before the gray blocks.
After the last step I got the gray blocks (and the whole laptop hangs, as usual).
Is it of any help to you to get this bug fixed, Bryce? If you need more info please let me know.

Since I don't see the intel driver in the backtrace, I went back to version 2:2.1.1-0ubuntu5, so compiz is back again.
Then I tried to reproduce the backtrace in my last comment. With steps in comment #39, I was able to get the gray blocks in my second attempt.
gdb outptut attached.

Today I've been trying to use the debian-lenny driver on gutsy, which is still at 2.1.0. With it, I can play videos using xv, and I still have dri and the best thing: I can switch to console and back, suspend and resume, no gray-blocks. Seems like at least for my i915GM it is much more stable then the 2.1.1 one in gutsy.

Sorry, I've reported success too early. Everything went fine until I tried to shutdown, then the gray blocks reappeared. But one thing is still true: While on 2.1.1 the system freezes every time, with the lenny driver I can change to console, log out and suspend at least most of the time.

I should note that the "i810" driver doesn't have this problem, so if your
card supports it you can use this and avoid the crashes. You do need
915resolution, though...
Devs: If this problem doesn't get fixed for final, could the default driver
be set to i810(+915resolution included) for cards which support it, as was
the default on Feisty ("intel" was available as an alternate driver)? I
think most of us would prefer a crash-free driver...

On 10/8/07, Gert Kulyk <email address hidden> wrote:
>
> Sorry, I've reported success too early. Everything went fine until I
> tried to shutdown, then the gray blocks reappeared. But one thing is
> still true: While on 2.1.1 the system freezes every time, with the lenny
> driver I can change to console, log out and suspend at least most of the
> time.
>
> --
> laptop hangs when switching video mode
> https://bugs.launchpad.net/bugs/127101
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Is it possible that the bug has been fixed in one of the today's updates (xserver-xorg-video-intel 2:2.1.1-0ubuntu6 and many more)?

I had the same problem until yesterday (with "intel" driver), but today I was not able anymore to reproduce it. I played videos with VLC (using xv driver), changed outputs with xrandr and switched to console and back (Ctrl+Alt+F1...F7) many times, but I was not able (yet?) to crash it.

Same here. This might be random but I was not able to get the gray blocks through (playing a video with xv, close it and directly switch to vt) since this update. But it is still possible to get them with Juan Pablo Salazar Bertín's steps:
1. Disable desktop effects and enable desktop effects again.
2. Switch to VT1 and switch back to VT7.
3. Repeat steps 1 and 2 several times.

Hmm, I repeated these steps now 15 times in a row. No crash.
Before the yesterday's update I was able to crash the computer simply by

1. go to a terminal and type: xrandr --output VGA --off
2. switch VT1

this worked nearly every time. But now again: no crash anymore. Either this is coincidence/random, or something related to this bug has been changed.

I have had the crash occur with the latest update - dunno what triggered
it...

On 10/9/07, Peter Weissgerber <email address hidden> wrote:
>
> Hmm, I repeated these steps now 15 times in a row. No crash.
> Before the yesterday's update I was able to crash the computer simply by
>
> 1. go to a terminal and type: xrandr --output VGA --off
> 2. switch VT1
>
> this worked nearly every time. But now again: no crash anymore. Either
> this is coincidence/random, or something related to this bug has been
> changed.
>
> --
> laptop hangs when switching video mode
> https://bugs.launchpad.net/bugs/127101
> You received this bug notification because you are a direct subscriber
> of the bug.
>

... and now it crashed again (using my two steps to reproduce) :-(
You are right, this bug is not fixed!

Because of this issue's importance and ability to crash systems, I just
e-mailed the Technical Board to ask them to switch back to i810 as the
default driver for supported chipsets in Gutsy (as was the case in Feisty).
Yes, you may have to use 915resolution, but you lose the random crashes - in
my opinion a good trade-off :)

On 10/9/07, Peter Weissgerber <email address hidden> wrote:
>
> ... and now it crashed again (using my two steps to reproduce) :-(
> You are right, this bug is not fixed!
>
> --
> laptop hangs when switching video mode
> https://bugs.launchpad.net/bugs/127101
> You received this bug notification because you are a direct subscriber
> of the bug.
>

This should be the last option. It is not only the 915resolution problem. If you start two videos or have totem playing a music file and run a video or start rythmbox with the visualization plugin (default) and run a video XV is ruined until restart. Many high resolution videos can't be played and external monitors doesn't work at all or at least very well.
But of course if this bug doesn't get fixed it makes sense.

I agree that switching back to -i810 is a possible way to resolve the
issue. However, one other aspect to consider:

After installation, we do not have any mechanism to automatically switch
people from one driver to another. -intel may not work as well as -i810
in this particular situation, however -i810 is legacy and no longer
being developed or maintained upstream. Thus, if we stick with -intel
even if it is buggy, at least we can push out future -intel updates from
upstream to users. However, if we revert to -i810 to solve this
particular bug, then that will be the end of it; we'll not likely be
able to supply any further changes for those users.

I talked with Jesse about this issue last week, and he said the Intel
devs were planning a meeting for this week to plan how to solve the bugs
with -intel. I don't expect to see a fix from upstream immediately, but
perhaps within a few weeks.

Given this, I'm on the fence about whether it's a good idea to switch
back to i810. -intel addresses a number of problems, that we'd be
returning to if we switched to i810, and then would really have no
viable way of addressing until Hardy.

This is a tough call. I'm actually a fan or the xrandr 1.2 support in the Intel drivers and I've used things like on the fly output switching and single screen rotation in dual head. The automatic modesetting is useful too but these crashes are pretty severe. I've tested openSUSE 10.3 which defaults to the intel driver and that even has a warning in the release notes about them...

I don't agree that this is a worthwhile trade-off, as it brings back to life the various i810 bugs we felt to finally be behind us. But here is the debdiff to enact this change:

http://people.ubuntu.com/~bryce/Testing/bug127101/

In addition to the various i810 bugs, it also loses us the enhancements present in the -intel driver to provide to end users. I strenuously feel this to be a shortsighted way of addressing the problem. I have confidence that if we work with upstream and remain patient, a fix for -intel can be achieved, even if after the gutsy release.

I see what you are saying - i810 is an inferior driver to intel, crash issues aside. However, at the same time, shipping a driver known to hard crash randomly upon doing such common things as logging out or suspending to RAM seems irresponsible.

 I feel that Ubuntu should go back to i810 as default for the Gutsy release - it worked in Feisty, and while it may have less features than intel, at least it doesn't hard crash regularly. *However*, Ubuntu could then push as an update to Gutsy a stub package which pushes the users to the intel driver once it is free of critical crashes. That way, we'll get the best of both worlds - Gutsy will ship with a stable driver by default rather than an unstable driver, and we could switch over with the stub package once the intel driver is fixed up to be as stable as i810.

Juan Pablo, thanks greatly for the gdb output, that actually helps a lot and gives me much more to go on. I have not found the source of the problem but this rules out several ideas, and gives us something we can finally take upstream.

I have gone through all the commentary on this bug, to compare everyone's chipsets:

Juan Pablo: 945GM/GMS, 943/940GML
Jose Bernardo: 945GM chipset
michelem: Unreported
unggnu: i915GM
Sitsofe: 945GM/GMS/940GML
bdmurray: 945GM/GMS, 943/940GML
Tim Hull: Unreported chipset. "mac book"
TBD: 945GM/GMS, 943/940GML
Rengarajan: nvidia Quadro NVS 110M -> unrelated
Jeff250: 915GM/GMS/910GML
legolas558: Unreported chipset -> unrelated
Gert Kulyk: 915GM
Peter Weissg.: Unreported chipset

Unfortunately, several people have failed to report their chipset, but if we disregard their reports, it's apparent that this is affecting just 945GM and 915GM. Also, some others who report "having this issue" turn up to have some completely unrelated issue that only appeared similar in symptoms to this one; we'll disregard these reports as well.

It's clear that there are at least three different bugs that are presenting similar behavior:

a) Juan Pablo's original issue, gray blocks on VT switch after disabling/enabling compiz
b) 'XAA Evicting pixmaps': This went away after Tribe 4
c) ungnu's issue, bug 141063, which occurs only after playing videos via Xv.

It's a little unclear sometimes when people report back "I'm having the same issue" after trying out various fixes, whether they are experiencing exactly Juan Pablo's issue, or ungnu's issue (or both, or neither). Possibly each of these bugs will be fixed by different things.

Sorry for the lack of info in earlier posts...

My video chipset is 945GM. Also, my issue in particular happens randomly when:
1) changing VTs
2) Logging out
3) Killing the X-server
4) Suspending to RAM

Under each of these circumstances, I randomly get the "grey blocks of death", and then my system resets. There may be some specific activity that triggers it for me, but I'm not sure what it is yet.

Tim Hull, thanks for your input. In discussing this with other Ubuntu X developers, we've concluded that reverting back to -i810 for everyone isn't an option. (Describing this approach as "irresponsible" is not a constructive way to help resolve this bug.)

I've (finally) been able to reproduce this issue myself. I have to say that while it's certain a bug, the steps to trigger it seem rather obscure to me, and not ones I'd expect an average user to run into very often. But perhaps there are certain use cases (3d games?) that are affected by it more intently than mine.

Given how much I've been able to use my 945gm system without triggering this issue, I don't feel like this is a showstopper issue. It does not prevent installation from succeeding, nor prevents X from starting up, and only occurs intermittently with use, so this seems well suited for rolling out post-release, once the issue is fully understood and solved.

Investigating further upstream, both Debian and Xorg have reports of similar issues:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=431373
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=432110
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433825
https://bugs.freedesktop.org/show_bug.cgi?id=9415
https://bugs.freedesktop.org/show_bug.cgi?id=12072
https://bugs.freedesktop.org/show_bug.cgi?id=10833

Since it usually happens with compiz, perhaps a less drastic solution would be to simply blacklist 915gm and 945gm from Compiz. Then, if/when the root issue is fixed, we could simply de-blacklist them.

For me it does not simply happen with compiz. It is happening on metacity, too. It happens every time after playing a video using xv-output, at least while dri is loaded (I did not test to disable dri). I don't need to have heavy 3d activity for this to occur.

Blacklisting the chips, though I am not a fan of compiz (I simply do not use it because I want to work with my machine, the only tool that compiz has and I miss in metacity is the scale-plugin), would result in many compaints of users who will say it used to work, but now it doesn't. Why not switching to i810? At least for me this does not mean any regression in comparsion to intel, the only difference (beside of the crash with intel) is, that for i810 I have to adjust contrast-settings for xv while using intel, I have to adjust saturation, too (intel XV seems not to like my hp nx6110 :-)).

I have an 855GM chipset, info found in dmesg:
> agpgart: Detected an Intel 855GM Chipset.

I am not experiencing any gray block (I do experience some garbage squares in the bottom-right of screen when the kernel is not configured to use the proper framebuffer devices, but that's normal I guess), so my problem was unrelated. I have no gray blocks when switching to VTs, although sometimes when logging out from X the screen goes all black and I can no more get a VT (I think this is unrelated too).

I do have a VGA output but couldn't yet test it; my problem was a software problem (xfwm4 and gtk+), I am currently using the intel driver (whose package is errenously labelled as "i810" on gentoo) with my 855GM and everything is fine.

Best regards

It is OK for me to stay with the -intel driver but it wouldn't help to disable Compiz since it is mostly unrelated. I am using compiz all the time and since the mesa fix I haven't problem with crash without using xv except if I disable and enable Compiz on the fly. I guess that this dis/enabling fires on some dri or opengl port which results in the problem like xv.
Without starting xv and using Compiz it is no problem to switch to vt. At least I have tested it several times in a row.
I have the same problems without Compiz after using xv.

Just to add the missing information: According to lspci, my video controler is a "Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)".

From what I' ve seen, the frequency of the hangs on my laptop seems to reduce using exa instead of xaa acceleration. Unfortunately, that means rebuilding xorg-xserver without patch #120 every time it is updated.

Maybe I have found a working compromise.
I have removed overlay fix from bug # 111257 which fixes the xv problem reported under bug # 141063 for me. Of course xv doesn't work anymore with Compiz but at least it seems that the xv crashes without Compiz seems to be gone.
The overlay fix isn't the general problem since it is still possible to get the gray blocks after several tests with dis/enabling compiz but this would be very rare behavior and not possible with disabled compiz for this cards. I haven't any crash through switching to vt while using xv under meta city without overlay fix. Since this crash happens randomly I can't be sure so it would be great if some more could test it.
Maybe this is the reason why this problem hasn't reported for i965 since compiz is disabled for them because of missing overlay.
Of course this would disable compiz on most out of the box working platforms but it could be enabled again after fixing the bug.

From the day I upgraded my laptop from Feisty to Gutsy (about Wednesday last week, I suppose, horrible memory... ;-)), I experienced this bug 4 times. The bug indeed seems to be random, I'm running Gutsy's compiz and the bug is sometimes triggered when switching from X to a console or when turning of the laptop (which is, in some way, also a switch from X to console). Yesterday evening, I was watching a video with Xvideo while running compiz. After pressing the power switch, I was presented with Juan Pablo's gray blocks with a 10-second-pushing of the power switch being the only way to turn of the computer.
The bad thing about this: all the 4 times I experienced this bug I had severe data loss. It seems as if the kernel's data cache is not yet written to disk when the bug occurs, leaving all open files in the RAM which virtually lost when the bug occurs. This affected my complete Firefox profile (including prefs.js, bookmarks.html and the session data) three times, my complete thunderbird profile (including prefs.js (containing all the accounts)) twice, the bonobo server configuration (/etc/bonobo-activation/bonobo-activation-config.xml) once and my pidgin profile (includig blist.xml, accounts.xml and prefs.xml) four times. I was able to recover my data with old backups, but in the long term, it is really annoying to constantly lose data when turning off the computer and having to fiddle around with meld to get the data back again.
Bryce, I understand your point in not wanting to switch to i810 as the default driver, and under other circumstances I would agree to you, but for me, this bug is not only an annoyance because of crashes sometimes, but it's a critical bug that caused me data loss in several cases. I have backups and I was able to restore the data, but when I think about the target audience of Ubuntu that also contains computer novices, I really think that Gutsy should be released as an operating system that does not randomly loses data.
A solution for the data loss for me is to always call sync before leaving X, but that's not the definite solution for Gutsy.

For the statistical records:
* VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (in fact an Intel 945GM is what I paid for)
* xserver-xorg-video-intel (2:2.1.1-0ubuntu6)
* Running XAA

After lunch, I'll try to gather some additional information as well as try EXA, the mentioned patches and debs in this bug and try to find a way to repdroduce it on my system.

I guess your file system is Xfs? This shouldn't happen with a good journaling file system afaik. I am using ext3, had this issue multiple times and no data lose (at least I found no one). Of course unsaved files would be gone but most people save them before suspend or shutting down.
Of course I understand your opinion and agree but maybe it could be fixed through my suggested work around.

Oh, I forgot to mention. Yes, my filesystem is indeed XFS. I don't want to start a philosophical discussion about the right file system, but I consider XFS a good journaling file system and the symptoms are very clear to me, just calling sync before doing something just saved me another restore-session when the bug occured again. Maybe XFS's deferred allocation adds to the kernel's write cache, but for enthusiasts I think XFS should not be uncommon as it usually performs better on a stable system and does not use the same old data structures that ext2 uses for some 15 years.

Anyway -- here is a little update (after which I'm not so sure if my bug really is the same bug as reported by others here):
Running metacity (no compositing) and VLC as video player, still using XAA. After playing a video with the Xvideo output module, stopping the video and switching to a VT, I first experienced an immediate return to a frozen X while Caps Lock and Num Lock still works (the LEDs go on) but no Ctrl-Alt-Backsp. After some time, X restarted itself bringing me back a functional desktop. On a second attempt (after a warm restart of the computer) of the same procedure, I could switch to the VT the first time, after returning to X and repeating the video playback and switching to a VT, I got the gray blocks and a total system freeze.

The fact that X was able to recover itself in the first attempt makes me not so sure anymore if my bug really is related to the one being described here.

If I can give an almost obvious suggestion: I could most times recover working VTs with sshd loaded at startup and then, when the system was hung (due to a different bug, btw), connecting from another PC and killing X

Here is Matt Zimmerman's direction on this:

"The bugs we know are better than the bugs we don't, and at this point -intel
has been tested on a variety of hardware that -i810 hasn't. I wouldn't be
comfortable changing our default driver this late in the release cycle, or
with trying to bugfix an orphaned driver, whereas I am very much open to
shipping a bugfix update to -intel after release."

OK - that makes some sense to me. In that case, could this bug be mentioned in the release notes with instructions on switching to i810 for those who experience an intolerable number of crashes? I believe OpenSUSE had such a note in their 10.3 release notes and shipped both drivers with -intel as default, as Ubuntu will be doing.

Also, is it possible to alter the gdm/kdm configuration to not reset the X-server on logout? This would make the issue occur far less in general use (it would be basically relegated to those who suspend-to-RAM often at that point). For me, the driver works fine unless the X-server is reset, at which point I get the crashes one out of every few times.

Sorry if I sounded harsh at times regarding shipping with this bug - I'm just afraid of users installing Gutsy and having a heavily crash-prone system...

The release notes are at https://wiki.ubuntu.com/GutsyGibbon/RC. I think it's a good suggestion to mention this issue in the Caveats section, in a short and constructive manner. Would you mind taking a shot at creating an initial draft of the text to go in here?

Given the plan of putting out a release note and fixing this in a post-release update, we need to approach this bug a little differently. First, we need to focus on finding "regression-free" fixes or workarounds. We will have made mention of the issue in the release notes, so it would not be good to put out a fix that risks just moving the bug to a new, unknown location. Second, I think we need to ensure when we apply a fix, we have a deep understanding of *why* it works; otherwise, we won't have confidence that we're truly fixing the root cause.

I posted about this issue to the xorg@ mailing list last night, to get advice. Unfortunately, there's not been very little response.

So far, the best attack angle we have are Juan Pablo's backtraces. These give tangible, deep information into the issue, that could possibly identify a real solution. I'm going to be focusing on this angle. I would encourage others who wish to help solve this issue to follow Juan Pablo's approach and try to also gain backtraces like his.

unggnu, thanks for investigating the angle of removing the overlay fix. However it sounds like that is more a fix for bug 141063 than this one. Also, since presumably removing the fix would result in returning the original bug that it fixed, it couldn't be considered regression-free.

Jose, it's quite interesting that enabling EXA seems to reduce the frequency of the issue, and that might provide a clue. However, EXA is another new technology with its own collection of issues, and given that we're dealing with issues from immature code, I don't think it's wise to solve it by adding in more immature code without having a deep understanding of why it makes it work. Also, if it requires dropping patch 120 from xserver, we'll get that regression for XAA users.

Tim, if you can identify which config variable in /etc/gdm/gdm.conf to switch, then other users could test that. However, it's hard to change gdm behavior without causing a regression somewhere, so this likely contains some regression risk as well. But it might be worthwhile to identify as a workaround, if we can get several of us to validate it.

Is there any good Howto for debugging X? It isn't so easy because of gdm and Co.
I guess that no workaround is regression free but to be sure it would be great if some more could check it.

For (X) debugging, I've been learning from:

https://wiki.ubuntu.com/DebuggingXorg
http://wiki.debian.org/XStrikeForce/XserverDebugging
http://wiki.x.org/wiki/Development/Documentation/ServerDebugging
http://sourceware.org/gdb/current/onlinedocs/gdb_toc.html

OK - I've added a blurb to the release notes about the issue. If possible,
sould some people test and make sure the graphical X setting tool can
properly change the driver? I've had some problems with this, but it should
work as it is a showcased feature in Gutsy.

On 10/10/07, Bryce Harrington <email address hidden> wrote:
>
> The release notes are at https://wiki.ubuntu.com/GutsyGibbon/RC. I
> think it's a good suggestion to mention this issue in the Caveats
> section, in a short and constructive manner. Would you mind taking a
> shot at creating an initial draft of the text to go in here?
>
> Given the plan of putting out a release note and fixing this in a post-
> release update, we need to approach this bug a little differently.
> First, we need to focus on finding "regression-free" fixes or
> workarounds. We will have made mention of the issue in the release
> notes, so it would not be good to put out a fix that risks just moving
> the bug to a new, unknown location. Second, I think we need to ensure
> when we apply a fix, we have a deep understanding of *why* it works;
> otherwise, we won't have confidence that we're truly fixing the root
> cause.
>
> I posted about this issue to the xorg@ mailing list last night, to get
> advice. Unfortunately, there's not been very little response.
>
> So far, the best attack angle we have are Juan Pablo's backtraces.
> These give tangible, deep information into the issue, that could
> possibly identify a real solution. I'm going to be focusing on this
> angle. I would encourage others who wish to help solve this issue to
> follow Juan Pablo's approach and try to also gain backtraces like his.
>
> unggnu, thanks for investigating the angle of removing the overlay fix.
> However it sounds like that is more a fix for bug 141063 than this one.
> Also, since presumably removing the fix would result in returning the
> original bug that it fixed, it couldn't be considered regression-free.
>
> Jose, it's quite interesting that enabling EXA seems to reduce the
> frequency of the issue, and that might provide a clue. However, EXA is
> another new technology with its own collection of issues, and given that
> we're dealing with issues from immature code, I don't think it's wise to
> solve it by adding in more immature code without having a deep
> understanding of why it makes it work. Also, if it requires dropping
> patch 120 from xserver, we'll get that regression for XAA users.
>
> Tim, if you can identify which config variable in /etc/gdm/gdm.conf to
> switch, then other users could test that. However, it's hard to change
> gdm behavior without causing a regression somewhere, so this likely
> contains some regression risk as well. But it might be worthwhile to
> identify as a workaround, if we can get several of us to validate it.
>
> --
> laptop hangs when switching video mode
> https://bugs.launchpad.net/bugs/127101
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I think another thing that might be worth testing would be to try turning off DRI and see if the issue can be recreated.

If I recall, when we tested the git driver, we found the issue went away, but also that DRI was disabled, so weren't sure if the fix was due to DRI or a fix upstream. So, if the issue can be recreated in our current Ubuntu -intel driver when DRI is off, then it means there may be a fix upstream we could backport. On the other hand, if we find that disabling DRI makes the issue go away with the current driver, it rules that possibility out, but then we can offer that as a another possible workaround.

Tim, the blurb sounds good. I've wordsmithed it a bit to make it a little more concise but I think it sounds good.

Bryce, unfortunately, the issue has never went away. Attachment in comment #65 is gdb output using git driver. As usual, laptop hanged with gray blocks after last line.

I tried turning off DRI, and while the issue went away (or at least
lessened), I then became unable to resume from suspend-to-RAM (no video
appeared). This happened spontaneously with DRI enabled, but happened all
the time with DRI disabled. Thus, I feel that using i810 is a more
recommendable workaround at the moment. The good news is that I can close
the bug I filed regarding suspend-to-RAM - I was sure it was the -14 kernel
update, but evidently it is in fact the "intel" driver.

On 10/10/07, Bryce Harrington <email address hidden> wrote:
>
> I think another thing that might be worth testing would be to try
> turning off DRI and see if the issue can be recreated.
>
> If I recall, when we tested the git driver, we found the issue went
> away, but also that DRI was disabled, so weren't sure if the fix was due
> to DRI or a fix upstream. So, if the issue can be recreated in our
> current Ubuntu -intel driver when DRI is off, then it means there may be
> a fix upstream we could backport. On the other hand, if we find that
> disabling DRI makes the issue go away with the current driver, it rules
> that possibility out, but then we can offer that as a another possible
> workaround.
>
> --
> laptop hangs when switching video mode
> https://bugs.launchpad.net/bugs/127101
> You received this bug notification because you are a direct subscriber
> of the bug.
>

On a somewhat-related note:

For some wacky reason, the graphical X configuration tool keeps giving me an
unusable 640x480 setup. Should the release notes be updated to direct users
to xorg.conf?

On 10/10/07, Tim Hull <email address hidden> wrote:
>
> I tried turning off DRI, and while the issue went away (or at least
> lessened), I then became unable to resume from suspend-to-RAM (no video
> appeared). This happened spontaneously with DRI enabled, but happened all
> the time with DRI disabled. Thus, I feel that using i810 is a more
> recommendable workaround at the moment. The good news is that I can close
> the bug I filed regarding suspend-to-RAM - I was sure it was the -14 kernel
> update, but evidently it is in fact the "intel" driver.
>
> On 10/10/07, Bryce Harrington <email address hidden> wrote:
> >
> > I think another thing that might be worth testing would be to try
> > turning off DRI and see if the issue can be recreated.
> >
> > If I recall, when we tested the git driver, we found the issue went
> > away, but also that DRI was disabled, so weren't sure if the fix was due
> >
> > to DRI or a fix upstream. So, if the issue can be recreated in our
> > current Ubuntu -intel driver when DRI is off, then it means there may be
> > a fix upstream we could backport. On the other hand, if we find that
> > disabling DRI makes the issue go away with the current driver, it rules
> > that possibility out, but then we can offer that as a another possible
> > workaround.
> >
> > --
> > laptop hangs when switching video mode
> > https://bugs.launchpad.net/bugs/127101
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>

@Tim Hull
This is reported under bug # 137792 .
Could you please check it without -intel driver overlay and compiz? I have attached a debdiff above.

Afaik DRI is needed for compiz and xv so it should be the last option. I can remember that I have disabled dri in xorg to reduce the intel driver opengl polls which results in a not working meta city even without compiz but this might be random.

According to Juan Pablo's backtrace (https://bugs.freedesktop.org/attachment.cgi?id=11964&action=view), the crash seems to be occurring in a loop.

I've disabled the loop (actually two loops), and the issue seems to have disappeared (at least, I can't reproduce it at all).

http://people.ubuntu.com/~bryce/Testing/bug127101/xserver-xorg-video-intel_2.1.1-0ubuntu7~bwh1_i386.deb

Steps to reproduce:
1. Disable desktop effects and enable desktop effects again.
2. Switch to VT1 and switch back to VT7.
3. Repeat steps 1 and 2 several times.

Note, this is *not* intended to fix the issue with playing Xv, only the original bug Juan Pablo reported.

I've been watching i value when the laptop hangs, and it's not always the same value.
In 3 tests, the laptop has hung with i=3, i=3 and i=4.

Thanks for building this new package. Time to install it and try to make the laptop hang again.
Two last questions: what do exactly the loops do? what is the drawback of removing them?

Those are the two big questions I have as well, and they must be answered before we can consider this patch a real fix.

Unfortunately, I am going to be out of town the rest of the week (customer on-site visit), but if these questions get answered satisfactorily, perhaps we can get the fix out monday.

Btw, I've made a big assumption here that the two loops "go together" and disabled both, but it's possible we only need to disable one or the other. I didn't have time to test that, but it should be tested, in case this is an incorrect assumption. Possibly the error exists only for the first loop.

I just installed the new package, spent about 20 minutes trying to crash it
with the usual methods, and I have been unable to reproduce the crashes
anymore. I repeatedly suspended-to-RAM, logged out, changed VTs, and even
killed the X server - with no grey block crashes. In the past, I could
cause said crashes to occur after 2 or 3 minutes. So far, it seems this
fixes the most severe issue - though there may be other ways of producing
the "grey blocks of death" (like the aforementioned Xv issue).

If this does indeed seem to fix the problem for everyone, I do hope this can
be committed for Gutsy final...

On 10/11/07, Juan Pablo Salazar Bertín <email address hidden> wrote:
>
> I've been watching i value when the laptop hangs, and it's not always the
> same value.
> In 3 tests, the laptop has hung with i=3, i=3 and i=4.
>
> Thanks for building this new package. Time to install it and try to make
> the laptop hang again.
> Two last questions: what do exactly the loops do? what is the drawback of
> removing them?
>
> --
> laptop hangs when switching video mode
> https://bugs.launchpad.net/bugs/127101
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I'm still getting this on the latest updates for gutsy (kubuntu).

The bug is serious, it makes it impossible to shut down, or hibernate laptops (happens nearly every time on my laptop, a dell d410, with a
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
).

I've switch back to i810, which doesn't have the problem for me, but has the Badalloc video problem, which makes playing video in X impossible. I need to shut down more than I need to watch video though.

I also have another strange thing: when I switch to VT1 I get a black screen with only a blink cursor in the top left corner

@Bryce Harrington
Testing xserver-xorg-video-intel_2.1.1-0ubuntu7~bwh1_i386.deb
VT switch OK (used to work 100% for me anyway), DRI OK, XV OK, suspend OK
hangs on resume with the screen off. Not sure if it has anything to do with your changes, though... Used to resume OK before.
Thanks.

Testing xserver-xorg-video-intel_2.1.1-0ubuntu7~bwh1_i386.deb with EXA acceleration:

VT switch OK, suspend/resume ok, video ok. Video playing while switching to VT1 and back - "blue screen" on the video output window (kaffeine/libxine/xv), and the X server resets after a couple of seconds. No useful info in Xor.0.log.old, it ends with the following:

(II) intel(0): [drm] removed 1 reserved context for kernel
(II) intel(0): [drm] unmapping 8192 bytes of SAREA 0xf8afd000 at 0xb7bd7000
(EE) intel(0): I830 Vblank Pipe Setup Failed 0
(EE) intel(0): I830 Vblank Pipe Setup Failed 0
(EE) intel(0): I830 Vblank Pipe Setup Failed 0
(II) intel(0): xf86UnbindGARTMemory: unbind key 0
(II) intel(0): xf86UnbindGARTMemory: unbind key 1
(II) intel(0): xf86UnbindGARTMemory: unbind key 2
(II) intel(0): xf86UnbindGARTMemory: unbind key 3
(II) intel(0): xf86UnbindGARTMemory: unbind key 4
(II) intel(0): xf86UnbindGARTMemory: unbind key 5

but kdm.log has some interesting stuff:

Error in I830WaitLpRing(), timeout for 2 seconds
pgetbl_ctl: 0x7ffc0001 pgetbl_err: 0x0
ipeir: 0 iphdr: 1810000
LP ring tail: 2250 head: 2244 len: 1f801 start 0
eir: 0 esr: 0 emr: ffff
instdone: ffc0 instpm: 0
memmode: 306 instps: f0000
hwstam: fffe ier: a2 imr: 0 iir: 250
Ring at virtual 0xa7934000 head 0x2244 tail 0x2250 count 3
        000021c4: 00000000
        000021c8: 02000011
        000021cc: 00000000
        000021d0: 02000011
        000021d4: 00000000
        000021d8: 02000011
        000021dc: 00000000
        000021e0: 02000011
        000021e4: 00000000
        000021e8: 02000011
        000021ec: 00000000
        000021f0: 02000011
        000021f4: 00000000
        000021f8: 02000011
        000021fc: 00000000
        00002200: 02000011
        00002204: 00000000
        00002208: 02000011
        0000220c: 00000000
        00002210: 02000011
        00002214: 00000000
        00002218: 02000011
        0000221c: 00000000
        00002220: 02000011
        00002224: 00000000
        00002228: 02000011
        0000222c: 00000000
        00002230: 02000011
        00002234: 00000000
        00002238: 02000011
        0000223c: 00000000
        00002240: 01810000
        00002244: 00000000
Ring end
space: 131052 wanted 131064

Fatal server error:
lockup

(EE) intel(0): I830 Vblank Pipe Setup Failed 0
(EE) intel(0): I830 Vblank Pipe Setup Failed 0
(EE) intel(0): I830 Vblank Pipe Setup Failed 3
(EE) intel(0): I830 Vblank Pipe Setup Failed 3

michelem, I have the same issue but only when I use one of the VESA resolutions using the vga kernel parameter. If I don't use this parameter, I have standard VGA text mode (80x25) but usable VTs. This is may be related to bug #147606 or bug #150797 or both.

I'll test xserver-xorg-video-intel_2.1.1-0ubuntu7~bwh1_i386.deb as soon as today's updates have run through.

With xserver-xorg-video-intel_2.1.1-0ubuntu7~bwh1_i386.deb (on Dell D610 laptop with "915GM/GMS/910GML" chipset):
VT switch: OK (tried Juan Pablo's steps [turning desktops effects on/off], and my steps [playing with xrandr] --> no crashs anymore)
Suspend to RAM: OK
Suspend to Disk: OK (it takes over a minute to resume, but this was also the case before that update --> no change here)
No regressions seen until now.

It would be interesting, though, what the loop which is commented out now, was supposed to do.

I just want to say a big thank you to all of you guys here for the effort you are making to solve this bug. I am experiencing the same problems on a Kubuntu Feisty Dell Inspiron 6400 with Intel 945GM.

I do not want to make things more complicated than they already are but:

I switched from Kubuntu to Ubuntu (both using the xserver-xorg-video-intel driver) because of this bug and I did not get the crashes anymore. I also installed the kde-core package because I wanted KDE instead of Gnome and still did not have any problems. When I started using KDM though instead of GDM the problems started again.

I have been using GDM and the KDE environment ever since with no problems at all for at least 2 months. Note that I have tested the problem only when restarting X-server and shutting down/restarting the laptop (nothing else).

The package version of the driver is 2:1.9.94-1ubuntu3

Hope it can be of any help...

Thanks again!!!

With the xserver-xorg-video-intel_2.1.1-0ubuntu7~bwh1_i386.deb package, I experience the same as the others here, no gray blocks when switching to VT, Xv acceleration works, compiz works. However, when I switch to VT1 after playing a video with Xv and then switch back to VT7, I get a blue screen instead of the Xv video just like Jose. But the X server does not restart after a few seconds, but it freezes the syste, no Ctrl+Alt+BackSp, no ACPI power off, no SysRq.

I'm running GDM and have a completely KDE-free system but I also experienced the gray blocks bug before, so I don't think the bug depends on the display manager used.

Good to hear this patch is working for all who tested it. Remember, it's not intended to address the issue when playing Xv, that is a separate (but possibly related) bug. Peter Clifton has been working on investigating this.

Can someone research and find out what the loop is used for? If we can sort that out by the weekend, I'll put together an official fix to hopefully get out either by Gutsy final, or in the first batch of updates.

Have you tried the .deb posted above for testing? That is supposed to fix
the problem - and does for me...

On 10/11/07, naught101 <email address hidden> wrote:
>
> I'm still getting this on the latest updates for gutsy (kubuntu).
>
> The bug is serious, it makes it impossible to shut down, or hibernate
> laptops (happens nearly every time on my laptop, a dell d410, with a
> 00:02.0 VGA compatible controller: Intel Corporation Mobile
> 915GM/GMS/910GML Express Graphics Controller (rev 03)
> ).
>
> I've switch back to i810, which doesn't have the problem for me, but has
> the Badalloc video problem, which makes playing video in X impossible. I
> need to shut down more than I need to watch video though.
>
> --
> laptop hangs when switching video mode
> https://bugs.launchpad.net/bugs/127101
> You received this bug notification because you are a direct subscriber
> of the bug.
>

TDB: could you try with the 2.6.22-12 kernel from the beta release? I'm
wondering if you're experiencing bug #151016...

On 10/11/07, TDB <email address hidden> wrote:
>
> @Bryce Harrington
> Testing xserver-xorg-video-intel_2.1.1-0ubuntu7~bwh1_i386.deb
> VT switch OK (used to work 100% for me anyway), DRI OK, XV OK, suspend OK
> hangs on resume with the screen off. Not sure if it has anything to do
> with your changes, though... Used to resume OK before.
> Thanks.
>
> --
> laptop hangs when switching video mode
> https://bugs.launchpad.net/bugs/127101
> You received this bug notification because you are a direct subscriber
> of the bug.
>

@Tim Hull:
now running 2.6.22.12.15
there's newer one in the repos 2.6.22.13.19
will be trying and reporting. thanks!
> TDB: could you try with the 2.6.22-12 kernel from the beta release? I'm
> wondering if you're experiencing bug #151016...
>
> On 10/11/07, TDB <email address hidden> wrote:
>

Are you saying that this does happen with the 2.6.22-12 kernel for you? If
so, then your issue is different from mine - as my machine has suspend
issues with 2.6.22-13 and up but works fine in -12.

On 10/11/07, TDB <email address hidden> wrote:
>
> @Tim Hull:
> now running 2.6.22.12.15
> there's newer one in the repos 2.6.22.13.19
> will be trying and reporting. thanks!
> > TDB: could you try with the 2.6.22-12 kernel from the beta release? I'm
> > wondering if you're experiencing bug #151016...
> >
> > On 10/11/07, TDB <email address hidden> wrote:
> >
>
> --
> laptop hangs when switching video mode
> https://bugs.launchpad.net/bugs/127101
> You received this bug notification because you are a direct subscriber
> of the bug.
>

@Tim Hull:
I'm afraid to make things even more complicated in this situation... But
here are my results: 2.6.22-10 = no problem, 2.6.22-12 = had 1 random
hangup on resume, 2.6.22-14 = no problem. Testing method: tried 5
suspend/resume cycles on each kernel with XV and glxgears. I recall I
had the same hangups a couple of times before (1/20 rate or so) so it
has nothing to do with intel driver recent "loop fix". For me it looks
like kernel + X issue and is very obscure and random. This one looks
orthogonal to gray blocks. With recent "fixed" intel driver I have no
more gray blocks problem with any tested kernel. Thanks.
> Are you saying that this does happen with the 2.6.22-12 kernel for you? If
> so, then your issue is different from mine - as my machine has suspend
> issues with 2.6.22-13 and up but works fine in -12

I do not know if there is any relation but I found these on the changelog of the newest linux kernel on www.kernel.org (supposed to be fixes):

Revert "intel_agp: fix stolen mem range on G33":

    This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which
    breaks horribly if you aren't running an unreleased xf86-video-intel
    driver out of git.

intel_agp: really fix 945/965GME

    Fix some missing places to check with device id info, which
    should probe the device gart correctly.

Do you think it is related somehow to our problem?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

That does seem to have fixed it. I can now shut down, although there is
a wierd thing where the screen goes black halfway through shutdown, with
just a blinking cursor in the top left. after a while, it continues to
shutdown, with the normal kubuntu artwork. The problem may be unrelated.

I'll stick with intel (as opposed to i810), and post again if something
happens.

ned

Tim Hull wrote:
> Have you tried the .deb posted above for testing? That is supposed to fix
> the problem - and does for me...
>
> On 10/11/07, naught101 <email address hidden> wrote:
>> I'm still getting this on the latest updates for gutsy (kubuntu).
>>
>> The bug is serious, it makes it impossible to shut down, or hibernate
>> laptops (happens nearly every time on my laptop, a dell d410, with a
>> 00:02.0 VGA compatible controller: Intel Corporation Mobile
>> 915GM/GMS/910GML Express Graphics Controller (rev 03)
>> ).
>>
>> I've switch back to i810, which doesn't have the problem for me, but has
>> the Badalloc video problem, which makes playing video in X impossible. I
>> need to shut down more than I need to watch video though.
>>
>> --
>> laptop hangs when switching video mode
>> https://bugs.launchpad.net/bugs/127101
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>

- --
Contact me on:
Jabber/googletalk: <email address hidden>
Skype: naught101
msn: <email address hidden>
ICQ: 93344350
IRC: irc.indymedia.org #climateimc #oceania
phone: 0417 484 73
- --------------------------------------------
http://eco101.wordpress.com

ENVIROWIKI is growing, but needs YOUR help
http://www.envirowiki.info/ - the wiki resource for enviro and social
justice activists that YOU can edit!

"This is the first age that's ever paid much attention to the future,
which is a little ironic since we may not have one." - Arthur C. Clarke
- --------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDzMh6l/tG5K2KHQRAnX6AJ9v3rmI8LGuXF8/0DyjpvYQDaAoHQCeIDMJ
+xYlyUqRlkiOKqkE69GP7x4=
=gbKL
-----END PGP SIGNATURE-----

whoops, sorry about that.

I've continued Bryce's debugging on this (where he discovered that restoring the palette registers on switch to console mode could hard-lock the machine).

I've added a patch which stops the palette registers being restored for inactive pipelines in the display chip. (If the pipeliine is inactive, it appears trying to program its palette causes the lockup).

The debdiff, sources and a .deb are at:

http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/

I'm not an Ubuntu or X.Org developer, so treat these as what they are.. unofficial and only tested by myself.

The package also has a possible fix / workaround for LP #141063, which lets Xv work with compiz and not crash after a mode-switch.

So far I haven't been able to reproduce this bug using xserver-xorg-video-intel_2.1.1-0ubuntu9~pcjc2_i386.deb package.
Looks like the patch works.

My system feels stable too... Whatever the "loop fix" breaks I don't
care because I probably don't have/use it ;-) I mean it's wroth putting
into Gutsy! Thanks!

Hopefully it shouldn't break anything.

If we comment out all the palette restore loops, you don't get a nice palette restored when you switch back to the console. Its all grey-scale. By selectively choosing to just re-program the pipeline in the chip which is enabled, you get the correct palette for the console.

Strictly speaking, we're now not restoring the full set of the video chips registers, so perhaps if your bios knows how to re-program the chip and say connect an external monitor to the other pipe, we'll have left it with a bad palette. IMO, thats better than the crashes, and perhaps something Intel will sort out "properly". I didn't want to delve into how complex it might be to deliberately program both pipelines just for the sake of restoring their palette regs.

The "correct"? fix might be to save the palette regs when the crtc pipleine is first used by the X11 driver, then re-program it before we shut it off. That way, only palettes which have been touched are re-programmed.

Seems to work after several testing. Great job.

With xserver-xorg-video-intel_2.1.1-0ubuntu9~pcjc2_i386.deb the problem seems to be fixed here.

Thank you.

Not really for me.
Shutdown seems to work always, reboot mostly but switching to a console crashes my system nearly every time (HP compaq nx5000 with 855GM graphics).
Don't know if it is a coincidence - but everything seem to work (incl. console switching) every time I did a successful reboot from within GNOME (without powering off the machine)!?

The i810 driver an 915resolution package works totally stable for me - wouldn't it be better to use the 'i810' driver as default instead 'intel' on fresh installed systems (as in pre 7.10)?
People could get distracted from using Linux if their system crashes every time they just want to shutdown or reboot - so I would say this bug should really be fixed before 7.10 Final.

Claudio, would you mind posting an Xorg log file from when its crashing. I don't have that chip, so haven't tested it myself.

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

 Option "ModeDebug" "true"

From the fact you were using 915 resolution, I presume you've got a 1400x1050 display?

Is it definatly the same symptom yous see, with the grey blocks? There might be more than one bug at work here.

If you're seeing a difference in behaviour after a successful reboot from gnome, can you additionally send xorg logs from:

Xorg after a full power down (no need to make it crash)
Xorg after a reboot (in the condition you find works).

I'm wondering if the BIOS is programming the video chip differently in those cases, and might be able to see from those logs with the ModeDebug option turned on.

Yes - the laptop has a 1400x1050 resolution.

But I don't get grey blocks or a distorted screen - the screen switches off instantaneous (completely - even the back light goes off).
No reaction to Magic SysReq Keys and not longer possible to log on over ssh.

The xorg-log ends the same after every crash - seems there's no time to write out any debugging information to the harddisc.

Something strange is going on there..

Can you confirm that both:

Xorg.0.log_debug_reboot_now_working
and
Xorg.0.log_debug_clean_shutdown

are logs from the X server taken immediately after it starts and you've logged in? (No logout / login in between).
I ask because in the clean shutdown version of the log, you see it loading the kernel module for the i915 driver. In the reboot_now_working log, you don't see that which might indicate the X server isn't the first one to load in that case.

Could you dump lsmod output for both cases from a terminal in the Xserver.

Also, are you running xserver-xorg-video-intel_2.1.1-0ubuntu9~pcjc2_i386.deb now?

Peter

Hi Peter

Yes - I'm running your package (installed it with 'dpkg -i xserver-xorg-video-intel_2.1.1-0ubuntu9~pcjc2_i386.deb' - is that correct?)

The clean_shutdown and crash logs were copied after booting the machine into recovery mode - so no X was started after the crash or clean shutdown.
The now_working log was copied after logging into GNOME and out again to test if it works - as I know gdm then restarts X - after that I copied Xorg.0.log (Sorry for confusing you).
So now I attached the Xorg.0.log.old. There you can find the missing line concerning the loading of the kernel module.

I also tried to set Options DRI to false and NoAccel to true - but that didn't stabilize anything.

Jesse Barnes proposed a patch to test with this issue, that adds additional i830_pipe_enabled checks. I've packed it for those who'd like to test it:

http://people.ubuntu.com/~bryce/Testing/bug127101/xserver-xorg-video-intel_2.1.1-0ubuntu8~bwh1_i386.deb

I've rerolled Peter's debdiff. It looked fine to me so basically this just renumbers it to -0ubuntu9.

http://people.ubuntu.com/~bryce/Uploads/xserver-xorg-video-intel_2.1.1-0ubuntu9*
http://people.ubuntu.com/~bryce/Testing/bug127101/xserver-xorg-video-intel_2.1.1-0ubuntu9_i386.deb

Thanks Juan Pablo and Peter for digging into this and figuring out what's gone wrong here. It sounds like the fix should be reasonably regression-free, so barring any further suggestions from upstream, or other findings, I'd think this is safe to roll out for Gutsy.

Just for the record, does anyone have an idea about what the now disabled loops were intended for ?
(it might just be freeing some resources or anything else that does not have any immediate effect but could be damageable for a running server for example...)

The package with the Patch from Jesse Barnes, which seems to be in upstream-git now, too, seems to work fine (did no shutdown yet, but everything else seems to work). I've not yet tested the package Peter prepared, but thanks for your work on that anyway.
(@Peter: You do not have an idea, how to cope with the issue, http://lists.freedesktop.org/archives/xorg/2007-July/026516.html describes, LP Bug #148686 ?;-)).

The loops aren't disabled in all cases. They program the 256 palette registers of each chip pipeline back to those read in before the X11 server started. Without this, your console palette is corrupted.

The woraround for the bug means we only actually ptogram the palette for the pipline which the console is using. (Any enabled pipeline actually). If we program a pipeline disabled in the chip, it locks the computer.

The bug may not be evident on machines with two displays active (on different pipelines).

The xserver-xorg-video-intel_2.1.1-0ubuntu9_i386.deb solved the problem here. No more blinking gray blocks on black screen after a simple logout, or after resume from suspend. (My machine is a FuSi Amilo Pro V3205, with Intel GMA950, and I'm not uing compiz.)

I can also confirm the -0ubuntu9 deb solves this problem on my Macbook. Would be great if this can sneak through freeze, or be SRU'ed, as Intel hardware is extremely common nowadays.

Juan, Peter, Bryce (and everyone else) - thanks for your work on this. Much appreciated!

(Does anyone else think that "Juan's Grey Blocks" sounds like a videogame title?)

I figure it sounds like a DS game :) Though I called it the "Grey Blocks of
Death".
In any case, it's good to see this fixed - now i810/915resolution can be
banished forever.

On 10/14/07, Sitsofe Wheeler <email address hidden> wrote:
>
> Juan, Peter, Bryce (and everyone else) - thanks for your work on this.
> Much appreciated!
>
> (Does anyone else think that "Juan's Grey Blocks" sounds like a
> videogame title?)
>
> --
> laptop hangs when switching video mode
> https://bugs.launchpad.net/bugs/127101
> You received this bug notification because you are a direct subscriber
> of the bug.
>

To reiterate more of what has already been said, I've been using the xserver-xorg-video-intel_2.1.1-0ubuntu9~pcjc2_i386.deb package for a few days, and I cannot reproduce the crash any longer. I also haven't noticed any regressions.

Me too. I have had a problem where when going on standby, or 2/3 of the way shutting down the screen goes blank, no response, with a flashing console cursor in the top left.
After about 1.5-2 minutes, it continues to shut down, with the normal kubuntu artwork.
Standby doesn't continue, just stays with the flashing cursor forever, and needs a hard shutdown.

This didn't happen using the i810 driver (I dunno about the standby thing, I never use standby). Is it possible that this bug is related?

naught101, your bug sounds unrelated. This bug manifests itself as blinking gray blocks. However, you're welcome to install one of the debs I posted above to see if it fixes your issue as well.

After trying out the ubuntu9 patch, I think it mostly solved the problem for me. But I do notice one thing (and I'm not sure it's a critical thing, just a little disconcerting). When opening a new window in Firefox, the image of whatever page you were on becomes "scrambled" for about a half second; once the new window opens, though, everything is fine. It's a little annoying to click a link, and the image get messed up for that split second until the new page opens and settles down. Oh, the scrambling occurs in the new window frame, not in the old one.

Other than that, looks like the patch may have fixed the original problem quite nicely.....

nah, you're right, It's probably unrelated. I already have Peter's one
installed, and it fixed the grey blocks issue for me. This issue is
probably something else. I'll post a bug.

cheers
ned

Bryce Harrington wrote:
> naught101, your bug sounds unrelated. This bug manifests itself as
> blinking gray blocks. However, you're welcome to install one of the
> debs I posted above to see if it fixes your issue as well.
>

xserver-xorg-video-intel (2:2.1.1-0ubuntu9) gutsy; urgency=low

   [Peter Clifton]
   * 01_fix_compiz_video.diff:
     - Bracket second clause in test for textured video to avoid
       compiler warning and possibly incorrect testing.
   * 04_fix_hw_restore.diff
     - Only restore palette registers for pipes which are enabled, or
       the system may hard-lock. (Initial patch by Bryce Harrington).
       (Closes LP: #127101)
   * 05_fix_xv_reset.diff
     - Playing Xv video after switching modes once the Xv driver is
       initialised causes a lockup, as the overlay regisers need
       re-programming. Ensure such a reset happens after a mode-switch.
       (Closes LP: #141063)

 -- Bryce Harrington <email address hidden> Sat, 13 Oct 2007 12:58:07 -0700

Thanks, everyone who worked on this bug. Everyone with Intel hardware
owes you!

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!