laptop hangs when switching video mode

Bug #127101 reported by Juan Pablo Salazar Bertín on 2007-07-20
This bug affects 1 person
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
Nominated for Trunk by Franck
xserver-xorg-video-intel (Debian)
Fix Released
xserver-xorg-video-intel (Fedora)
Fix Released
xserver-xorg-video-intel (Ubuntu)
Nominated for Gutsy by unggnu

Bug Description

When Ubuntu changes video mode (switching to a VT, 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, as in gutsy by default.

Usually the last lines in my Xorg.0.log are something like this:

(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:
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

Created an attachment (id=9535)
X log file

Could you try again with the released server/driver?

Still crashes with the latest debian unstable i.e. xorg-core 1.3.0, intel 2.0.0, mesa 6.5.2.

Also briefly tried VT switching while running xcompmgr. That seemed to work fine.

197 comments hidden view all 211 comments

Description of problem:

When using the Intel experimental video driver on my thinkpad T60 with intel 945
gm, often my system will freeze, and the screen will show a bunch of gray block
on a black screen moving around. If I switch to the 810 drivers, I don't have
this issue.

Version-Release number of selected component (if applicable):


How reproducible:

not very--this is intermittent. However, it happens usually on logout or system

Steps to Reproduce:
1. logout or shutdown

Actual results:

system freezes with lots of gray blocks on a black screen

Expected results:
successful logout or shutdown

Additional info:

Thanks for the bug report. We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

198 comments hidden view all 211 comments

I found a workaround!
It seems the bug can only be reproduced with vga (as opposed to framebuffer) terminals. With the kernel using vesafb, I can't make it crash anymore.

I'm now using xorg-core 1.3.0, intel 2.1.0, mesa 6.5.3, kernel 2.6.22-rc7.
With the regular vga terminals, the same crash occured every once in a while, even if any GL apps hadn't been used.

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:
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.

Changed in xorg-server:
status: New → Confirmed

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 -

Conn O Griofa (psyke83) wrote :


I actually have two similar bugs reported upstream, see: and

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).


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.


I've reported a similar bug at launchpad:
There's even a video there showing how the screen looks when my laptop hangs, do you think it's the same bug?

Yes, that's exactly what it looks like!

Also, I said earlier that vesafb seemed to help. Actually it does still hang occasionally. With vesafb the screen just stops (no blinking).

Changed in xserver-xorg-video-intel:
status: Unknown → New
Changed in xserver-xorg-video-intel:
status: Unknown → In Progress
Changed in xorg-server:
status: Unknown → Confirmed

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.

description: updated
michelem (michele-marcucci) wrote :

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:

@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.

I'm not seeing this issue on:
-- Ubuntu Feisty 7.04 (xserver 1.2.0, intel 1.9.94, Mesa 6.5.2) on 965GM
-- Fedora 7 (xserver 1.3.0, intel 2.0.0, Mesa 6.5.2) on 965G

Gordon: 3/3 reporters whose hardware I checked were using a 945GM, so I wouldn't expect testing on a G/GM965 to show the issue.

I'm seeing this too. It happens randomly and when the hang happens the blocks on the screen are pretty much as in the video on the launchpad bug. The laptop is a Lenovo T60 running at 1024x768.

lspci output is:
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)

It seems to happen more often when a composite manager is being used but I have also had this happen when logging out of sessions that have only been using metacity. It does not seem to happen every time. I am currently trailing whether this happens when DRI is disabled.

Version information:
xorg 1:7.2-5ubuntu7
xserver-xorg-video-intel 2:2.1.1-0ubuntu2

Conn O Griofa (psyke83) wrote :


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 am experiencing the same issue with Intel driver 2:2.1.1-0ubuntu3 and i915GM on Ubuntu Gutsy Gibbon.
This doesn't happen with i810 driver.

Sony Vaio TX2
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)

unggnu (unggnu) wrote :

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 ( 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.

Sitsofe Wheeler (sitsofe) wrote :

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)

Kieran Hogg (xerosis) wrote :

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

Sitsofe Wheeler (sitsofe) wrote :

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?)...

Changed in xserver-xorg-video-intel:
importance: Undecided → High
status: Confirmed → Triaged
Brian Murray (brian-murray) wrote :

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".

This seems to be fairly reproducible using steps mentioned by Brian in - basically start/stop video and switch back and forth to VTs.

Sitsofe Wheeler (sitsofe) wrote :

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

Changed in xorg-server:
status: Confirmed → In Progress
Tim Hull (thully) wrote :

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?

TDB (michael-baranov) wrote :

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

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.


Forgot to mention I'm running Gutsy.

unggnu (unggnu) wrote :

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?

It seems that this issue has something to do with bug report . The patch seems to fix the issue at least for me after some tests.

Bryce Harrington (bryce) on 2007-09-29
Changed in xserver-xorg-video-intel:
assignee: nobody → bryceharrington
status: Triaged → Fix Released
Changed in xserver-xorg-video-intel:
status: Fix Released → Confirmed
Changed in xserver-xorg-video-intel:
status: Confirmed → Triaged
Bryce Harrington (bryce) on 2007-10-11
Changed in xserver-xorg-video-intel:
status: Triaged → In Progress
Bryce Harrington (bryce) on 2007-10-14
Changed in xserver-xorg-video-intel:
status: In Progress → Fix Committed
Bryce Harrington (bryce) on 2007-10-15
Changed in xserver-xorg-video-intel:
status: Fix Committed → Fix Released
131 comments hidden view all 211 comments
Conn O Griofa (psyke83) wrote :

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).

Peter Clifton (pcjc2) wrote :

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).

Peter Clifton (pcjc2) wrote :

Anyone still having issues on 855 hardware, please have a look at LP Bug #108056

I'm put online a .deb (and sources etc..) which has debug code for anyone still having issues:

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.

Peter Clifton (pcjc2) wrote :

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.

*** Bug 10768 has been marked as a duplicate of this bug. ***

Peter Clifton (pcjc2) wrote :

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

Peter Clifton (pcjc2) wrote :

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.

Elmer van Baal (evbaal) wrote :

Thanks people, this patch seems to work fine!

Francois Thirioux (fthx) wrote :

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

tekkenlord (linuxfever) wrote :

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

Thank you!

Jonathon James (isamaranga) wrote :

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.

Peter Clifton (pcjc2) wrote :

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:

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

Conn O Griofa (psyke83) wrote :


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.

Conn O Griofa (psyke83) wrote :

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

Conn O Griofa (psyke83) wrote :


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 :).

Peter Clifton (pcjc2) wrote :

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!

Jim Pharis (binbrain) wrote :

Just an FYI, my Dell Inspiron 700m (w/ 855) still experiences the problem (when compiz is enabled) with the update posted yesterday the 18th 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.

amephist (amephist) wrote :

Using (or not) the latest patch ( 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.

could you please try the patch in bug# 10768 comment# 23?

Changed in xorg-server:
status: In Progress → Incomplete
13 comments hidden view all 211 comments

Just a note that I'm able to reproduce this in nearly 100 % of cases using the
xrandr command as described here:

And it seems they fixed this upstream. I haven't tested it yet, though. (and I'm
not running Fedora on this HW, anyway)
Should be commit eecd3ccedee6c4acf101591f7e60673660379e62 in master branch of
xf86-video-intel. (I wanted to paste a link to gitweb, but gitweb.fd.o seems dead)

12 comments hidden view all 211 comments

There have been some VT fixes committed in the git recently, which do fix some VT bug reports.
Could anyone retest this bug with the git tip or 2.2 release?


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.

Peter Clifton (pcjc2) wrote :

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.

Robert Larsson (rodge86) wrote :

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?

unggnu (unggnu) wrote :

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

Changed in xserver-xorg-video-intel:
status: New → Fix Released

Feedback timed out. I'm assuming it's fixed by the recent VT-related patches. Please reopen if you still see it with 2.2.x driver or git tip.

Changed in xorg-server:
status: Incomplete → Fix Released
8 comments hidden view all 211 comments

Yeah, 9xx should be pretty solid at this point. Please retest when you can
and update the bug.

(as far as I'm concerned, that single patch -- which I applied manually -- fixed
all my problems and X+intel have been really solid since)

Changed in xserver-xorg-video-intel:
status: In Progress → Incomplete

Tomas, I know this isn't really a Fedora issue at this point since you
manually applied the patch, but I wonder if you could test upstream git? I
made some changes in this area recently and hopefully things will still work
for you. If not, I'd definitely appreciate if you could file a bug at against the intel driver for the problem.


I updated to latest git and things seem to work. If they stop, I'll make a note
about it :)

I guess, this is not NEEDINFO anymore.

Changed in xserver-xorg-video-intel:
status: Incomplete → In Progress

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:

The process we are following is described here:

Thank you for the bug report. Closing bug as per comment #7.

If you still experience this problem after updating to our latest Fedora
release, reopen this bug against that version if this bug exists there.

Changed in xserver-xorg-video-intel:
status: In Progress → Fix Released
13 comments hidden view all 211 comments
imachine (m-jedrasik) wrote :


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!


PS. The original website I found this on is here:ązanie-zamrażania-ekranu

imachine (m-jedrasik) wrote :

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:żaniem-ekranu

imachine (m-jedrasik) wrote :


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).


jrgn (jorgy-travelling) wrote :

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?


Bryce Harrington (bryce) on 2009-12-15
Changed in xserver-xorg-video-intel (Ubuntu):
assignee: Bryce Harrington (bryceharrington) → nobody
Changed in xorg-server:
importance: Unknown → High
Changed in xorg-server:
importance: High → Unknown
Changed in xorg-server:
importance: Unknown → High
Changed in xserver-xorg-video-intel (Fedora):
importance: Unknown → High
Displaying first 40 and last 40 comments. View all 211 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.