Ubuntu

laptop hangs when switching video mode

Reported by Juan Pablo Salazar Bertín on 2007-07-20
134
This bug affects 1 person
Affects Status Importance Assigned to Milestone
X.Org X server
Fix Released
High
Nominated for Trunk by Franck
xserver-xorg-video-intel (Debian)
Fix Released
Unknown
xserver-xorg-video-intel (Fedora)
Fix Released
Unknown
xserver-xorg-video-intel (Ubuntu)
High
Unassigned
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: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

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.

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

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 - http://ubuntuforums.org/showpost.php?p=3017867&postcount=3

Conn O Griofa (psyke83) wrote :

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.

Martin,

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

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

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 :

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

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

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 inhttps://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/127101 - 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
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.

unggnu (unggnu) wrote :

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

It seems that this issue has something to do with bug report http://bugs.freedesktop.org/show_bug.cgi?id=10809 . 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
120 comments hidden view all 200 comments
Zsolt Zakál (zakalzs) wrote :

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

John Dong (jdong) wrote :

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.

Sitsofe Wheeler (sitsofe) 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?)

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

Jeffrey Knockel (jeff250) wrote :

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.

naught101 (naught101) wrote :

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?

Bryce Harrington (bryce) 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.

Dan Gilliam (geocritter) wrote :

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

naught101 (naught101) wrote :

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

Bryce Harrington (bryce) wrote :

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

Changed in xserver-xorg-video-intel:
status: Fix Committed → Fix Released
John Dong (jdong) wrote :

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

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

Peter Clifton (pcjc2) wrote :

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.

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

Peter Clifton (pcjc2) wrote :

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.

Peter Clifton (pcjc2) wrote :

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.

Elmer van Baal (evbaal) wrote :

Thanks people, this patch seems to work fine!

Francois Thirioux (ft73) 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:

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.

Conn O Griofa (psyke83) wrote :

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.

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 :

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

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

amephist (amephist) wrote :

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.

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

Changed in xorg-server:
status: In Progress → Incomplete

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?

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.

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 :

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?

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
Changed in xserver-xorg-video-intel:
status: In Progress → Incomplete
Changed in xserver-xorg-video-intel:
status: Incomplete → In Progress
Changed in xserver-xorg-video-intel:
status: In Progress → Fix Released
imachine (m-jedrasik) wrote :

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

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:

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

imachine (m-jedrasik) wrote :

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,

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?

Thanks!

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
Displaying first 40 and last 40 comments. View all 200 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.