Ubuntu

MASTER: [i845] GPU lockup

Reported by Geir Ove Myhr on 2010-03-18
This bug affects 259 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
Critical
Baltix
Undecided
Unassigned
xserver-xorg-video-intel (Ubuntu)
Wishlist
Unassigned
Lucid
High
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-intel

This is a MASTER bug report, i.e. not a real bug report, but a tool to help manage other bug reports.

Most bug reports on i845 are probably due to the CPU/GPU incoherency problem that is now consolidated upstream at http://bugs.freedesktop.org/show_bug.cgi?id=26345 . For now, we mark all automatically reported GPU lockups as duplicates of this unless there is a reason not to.

To use the available fix, run the following commands:

apt-add-repository ppa:glasen/855gm-fix
apt-add-repository ppa:brian-rogers/graphics-fixes
apt-add-repository ppa:glasen/intel-driver
aptitude update
aptitude install linux 855gm-fix-dkms
aptitude dist-upgrade

There is a similar master bug report for i855 at bug 541511.

Geir Ove Myhr (gomyhr) on 2010-03-18
Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Triaged
importance: Undecided → High
Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed
Geir Ove Myhr (gomyhr) on 2010-03-20
description: updated
summary: - MASTER: [i845] GPU lockup (apport-bug)
+ MASTER: [i845] GPU lockup (apport-crash)
Bryce Harrington (bryce) on 2010-03-21
tags: added: lucid
Bryce Harrington (bryce) on 2010-03-22
tags: added: freeze
tags: added: crash

It happens all the time now. Sometimes when I click a new link, sometimes when I open a new program or whatever. The screen doesn't get signal from the GPU anymore and complains.

It's pretty reliable, after 1-5 hours I always get a crash. Hope it can be fixed soon.

jerrylamos (jerrylamos) wrote :

Haven't had the bug recently. Now on

Linux version 2.6.32-17-generic (buildd@vernadsky) (gcc version 4.4.3 (Ubuntu 4.4.3-3ubuntu3) ) #26-Ubuntu SMP Fri Mar 19 23:58:53 UTC 2010

Do note this Lucid Beta is running with KMS and default xorg. Finally.

Jerry

Geir Ove Myhr (gomyhr) on 2010-03-25
description: updated
MasterNetra (designerkline) wrote :

Still recieve the crashes. Just updating.

useResa (rdrijsen) wrote :

Have posted my experiences with the trial version (2:2.10.903-4-g0c47195.1) in my original report, bug #545201
Unfortunately caused more issues than the current official version

Geir Ove Myhr (gomyhr) on 2010-03-27
description: updated
Odin Hørthe Omdal (velmont) wrote :

So far, so good with the patch. :-)

istoyanov (istoyanov) wrote :

The integrated video on a Fujitsu-Siemens Scenic P300 desktop PC suffered from random lock-ups and problems detecting the correct refresh rate and resolution of the monitor attached to it. Had the problem with 9.04, 9.10 and a clean install of 10.04-beta-1, but after getting all the updates as of 31. March I the issue seems to be resolved and I can use the optimal resolution and refresh rate of the (now correctly detected) the monitor without a problem so far.

---
Hardware details:

00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01)
 Subsystem: Fujitsu Technology Solutions Device 1003
 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
 Latency: 0
 Region 0: Memory at e0000000 (32-bit, prefetchable) [size=256M]
 Capabilities: <access denied>
 Kernel driver in use: agpgart-intel
 Kernel modules: intel-agp

00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
 Subsystem: Fujitsu Technology Solutions Device 1003
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
 Latency: 0
 Interrupt: pin A routed to IRQ 16
 Region 0: Memory at d8000000 (32-bit, prefetchable) [size=128M]
 Region 1: Memory at d0000000 (32-bit, non-prefetchable) [size=512K]
 Capabilities: <access denied>
 Kernel modules: i915

jerrylamos (jerrylamos) wrote :

On i845 video graphics updated as of 31 March got three black screen crashes today. The first one was with default the other two with nomodeset. One of them seemed to point to gnome-panel which looked a bit different so I filed a bug on that. (I'm on another computer and don't have the bug # here)

Jerry

Btw I've just now uploaded a new intel-gpu-tools package. I see it
includes a few updates for improving debugging on i8xx.

Unfortunately, after my previous optimistic report, I have experienced several random crashes (combined with wrong resolution signal to the monitor) similar to these reported by Jerry. Basically, I use only the "nomodeset" boot option (i.e. removed the default "splash" and "quiet" to follow the boot process) but sometimes the gdm screen received a non-standard resolution that was reported by the monitor as "user setting" (and not as "1024x768"). This has led me to experiment a little bit by adding "Modes 1024x768" and "Modeline FREQ1-FREQ2" to a newly-created xorg.conf. Thereafter, the switch from the framebuffer to the gdm login screen seems to happen with the specified resolution applied, but sometimes, when clicking on the logout button or scrollling over the volume control icon X crashes and the monitor starts to switch between a black-white striped upper 1/2 (or third) and a completely blank screen. In this situation I cannot switch to a virtual console and the only way out is the ON/OFF button on the PC (this seems to trigger a clean switch-off). I'll test the updates that Bryce mentioned and will report here any further problems. Or should I open a separate bug-report for this?

jerrylamos (jerrylamos) wrote :

Ivailo, I was getting the alternating upper screen black white striped and blank in two incidents yesterday as well. The screen is a 1280x1024. Only way out is power off. Could not ssh in from another pc on the same network.

How do I use intel-gpu-tools package after it is installed?

Thanks, Jerry

Odin Hørthe Omdal (velmont) wrote :

I have also had crashes after a full day of working with no problem. Next day, crash, crash.

The wall paper was "low resolution", the rest was OK. Every alternating line was wallpaper, and the other was old programs I've closed that "hung around, stuck" into the wallpaper!

I changed wallpaper and played with the settings -> BAM -> crash. No apport from this. Then after two restarts everything was fine, and I worked on the computer 4 hours yesterday with no problems... So it's still quite shaky.

istoyanov (istoyanov) wrote :

After the update today, the "nomodeset" boot parameter seems to be non-functional and at the stage where the gdm screen should appear, the monitor switches off by "entering in power save mode". Switching to a virtual console wakes it up again, but after changing the driver to "vesa" this option doesn't work anymore.

On Thu, Apr 01, 2010 at 07:42:02AM -0000, Ivailo Stoyanov wrote:
> Unfortunately, after my previous optimistic report, I have experienced
> several random crashes (combined with wrong resolution signal to the
> monitor) similar to these reported by Jerry.

Jerry has reported some crashes as well as freezes. This bug report is
about a freeze rather than a crash.

If what you are seeing is a crash there will be a backtrace in your
Xorg.0.log (usually, or check gdm logs). Also be aware that the
backtraces in your Xorg.0.log are fairly useless - instead you need to
collect a full backtrace using either apport or gdb. See
http://wiki.ubuntu.com/X/Backtracing for details.

On the other hand, if you're seeing a freeze (graphics are frozen, but
maybe the mouse works) you need to follow the directions on
http://wiki.ubuntu.com/X/Troubleshooting/Freeze to collect data needed
for these kinds of issues.

However, I think it's pretty well known at this point that upstream's
code is fairly buggered with i845, so if you have that video card, if
you have a freeze it's probably not worth putting in more bug reports
about it at this point. You can track the upstream bug report as it
progresses, and help them with testing things. Be aware you'll probably
be expected to patch and build new kernels in order to do this.

Beyond that, assuming a patch doesn't come to light, the one other knob
we have to fiddle with at the distro level is to blacklist KMS from this
hardware. See http://wiki.ubuntu.com/X/KernelModeSetting for more info
about this and how to configure it off (basically boot i915.modeset=0)
so it uses UMS instead.

What we need is a convincing consensus among 845 owners that UMS works
better than KMS for the hardware, and then we can request the kernel
team to blacklist it.

Bryce Harrington (bryce) wrote :

On Thu, Apr 01, 2010 at 11:39:03AM -0000, jerrylamos wrote:
> Ivailo, I was getting the alternating upper screen black white striped
> and blank in two incidents yesterday as well. The screen is a
> 1280x1024. Only way out is power off. Could not ssh in from another
> pc on the same network.
>
> How do I use intel-gpu-tools package after it is installed?

See https://wiki.ubuntu.com/X/Troubleshooting/Freeze which is where this
should be documented. The info is kind of scant though (please help us
flesh it out better - it's a wiki, you can edit.)

Basically, you run the tool `intel_gpu_dump` to capture dumps.

Sorry, I was seeing a freeze. At least I think. I don't remember correctly anymore, the screen went black anyway.

But KMS is the way forward right? So once the bugs has been ironed out that's what we want? I've lost access to the computer for some time now.

jerrylamos (jerrylamos) wrote :

Bryce, installed the ppa see this grub.cfg entry:

linux /boot/vmlinuz-2.6.33-997-generic root=UUID=fcf85719-2242-4b65-a162-a41060902f45 ro quiet splash nomodeset

and cat /proc/version:

Linux version 2.6.33-997-generic (root@zinc) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #201003091338 SMP Tue Mar 9 14:32:16 UTC 2010

Do note even though it says to boot "nomodeset" KMS is actually active. That just started happening today with the 1 April aptitude -q update safe-upgrade.

If the next crash is such that "ssh" will work I'll try the wiki directions.

Thanks, Jerry

istoyanov (istoyanov) wrote :

I have also installed the 2.6.33-997-generic kernel from the PPA and was able to get a batchbuffer dump after one of the incidents.

istoyanov (istoyanov) wrote :
Noel Arzola (noel.arzola) wrote :

Still receiving. Went to cycle through screensavers to duplicate the issue and received the crash as soon as it went to display one. I've only being updating through the update manager haven't tried anything else yet. Disabling my screensaver has allowed me to keep my system up without crashing so often though.

jerrylamos (jerrylamos) wrote :

Bryce, on 3 of my 4 test pc's Lucid Beta with updates from end of March through 1 April were dead or not really usable with KMS problems until I saw in the forums to use "i915.modeset=0" for the i830 and i845, even though they are not i915. The i830 (the one I'm using here) wouldn't even boot in "recovery" mode only rescued by doing ssh from another pc.

The ati Mobility 7500 also failed within 2 minutes of logging in to AOL mail until I put in "radeon.modeset=0".

All three were running O.K. on Karmic, with KMS on on the i845 and ati but "nomodeset" on the i830.

Jerry

> saw in the forums to use "i915.modeset=0" for the i830 and i845, even
> though they are not i915.

Jerry, the i915 in the i915.modeset=0 kernel parameter is the name of
the kernel driver, not the chipset. I don't know the historical
reasons for it being named i915 (possibly it was only used for i915
and newer in the beginning), but at least nowadays it is used on all
chipsets, including i830, 845G, and 855GM. The DDX driver used to be
i810, even though it was used on i915 and i945 as well, but now it has
been renamed intel (this is the one packaged in
xserver-xorg-video-intel).

Ivailo, I attached your i915_error_state to the upstream bug report in case it is useful there. At least this does not seem to be the kind of freeze that would be fixed with xserver-xorg-video-intel from my PPA (I uploaded a new version based on the latest Lucid version today). For freeze bugs, dmesg output is more useful that Xorg.0.log (but both are fine). Especially with the kernel parameter drm.debug=0x02 does a lot of information about what is going on before the freeze end up in dmesg output.

Bryce Harrington (bryce) wrote :

We should consider if it makes sense to blacklist KMS for this chipset.

Jerry has indicated that by booting his system with i915.modeset=0 that it worked around the issue. I would like to see several more people confirming that it did similarly for them. Please test this.

If there seems to be a consensus favoring blacklisting KMS, then we'll reassign this bug to the kernel and have andy blacklist for us.

If anyone finds that their i845 system works *worse* with KMS turned off for some reason, please shout; I wouldn't expect turning KMS to cause regressions so this would be a surprise, but with i8xx weirder things have been known to happen!

Changed in xserver-xorg-video-intel (Ubuntu Lucid):
status: Triaged → Incomplete
Bryce Harrington (bryce) wrote :

One consideration to take into account, is if we move to UMS for i845, it means we will be entirely unable to get further upstream support on this chip, since any new patches they generate are going to be only for KMS cases. However 8xx has typically not received a high level of support priority upstream anyway, so i845 may be better off in UMS anyway. I have hopes we'll see things better squared away for i8xx KMS in Meerkat, but we'll see...

summary: - MASTER: [i845] GPU lockup (apport-crash)
+ MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?)

It looks like upstream is not going to have a fix in time for Lucid. What we can do instead is disable KMS for this chip - but we only want to do that if disabling KMS actually makes the driver more stable!

If you are experiencing these GPU freezes, could you please try and see if adding “i915.modeset=0” to your boot options after “quiet splash”.

jerrylamos (jerrylamos) wrote :

Installed 20100407 which ran for 5 hours with KMS on i845 video graphics and was entering a comment here when screen flashed black then to command line like Ctrl-Alt-F1 a couple times then crashed hard. Could not even ssh in.

I don't think Ubuntu had time to record anything useful but I ran ubuntu-bug xorg see Bug#558613 after booting up.

I'd strongly recommend "i915.modeset=0" default for both i845 and i830. Most of the time over the last year while Ubuntu has been working on KMS it has not worked on these video graphics, or if it does briefly a "dread update" makes them unstable.

If someone wants to turn KMS on and try it, O.K., but in my experience not for an ordinary user as default.

Jerry

pakraticus (pakraticus) wrote :

Chris Rogers,
The following is my current kludge around. An xorg.conf only containing.

Section "Device"
  Identifier "my-self-configured-device"
  Driver "intel"
 Option "DRI" "Off"
EndSection

GL apps still work, but are painfully slow, but it beats not working at all. The above kludge was actually derived from the troubleshooting documentation.

At this point in time I am seeing the system crash/lock to the affected system is no longer on the network

00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
 Subsystem: IBM Device 0267
 Flags: bus master, fast devsel, latency 0, IRQ 16
 Memory at 88000000 (32-bit, prefetchable) [size=128M]
 Memory at 80000000 (32-bit, non-prefetchable) [size=512K]
 Capabilities: <access denied>
 Kernel modules: i915

With i915.modeset=0 added to the kernel command line I keep seeing white vertical bars flash across the top half-third of the screen and iterations of
[ 167.472853] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 1770 at 1733)
[ 169.524015] [drm:i915_gem_idle] *ERROR* hardware wedged
[ 170.647918] [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck
[ 171.008012] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
[ 171.008023] render error detected, EIR: 0x00000000

in dmesg. And the machine stays on the network with the extra parameter.

The problem happens with both 2:2.9.1-3ubuntu2~gomyhr1~clipsolids and 2:2.9.1-3ubuntu1 on 2.6.32-19-generic.

If someone wouldn't mind reminding me how to setup a serial console for debugging this kind of annoyance I'll gladly collect as much debug information as upstream wants.

My two cents of things to do before Lucid ships are
1) Prominently include in the release notes that xserver-xorg-video-intel is broken.
2) Prominently include in the release notes the work around xorg.conf.
3) Repeat #1 and #2 in a recognizeably named file in /usr/share/doc/xserver-xorg-video-intel along with this bug tracking number and upstream's bug tracking number.

If someone is feeling very creative, try having the crash hooks install that stub xorg.conf and reboot the system.

jerrylamos (jerrylamos) wrote :

At Beta 2 level, with "i915.modeset=0", I'm getting the "hardware wedged" error so often I can't even do a launchpad "Add comment". This is i845 with Lucid 20100407 updated as of 8 April.

I can do ssh in and do "sudo service gdm stop" so Ubuntu isn't completely dead, it just can't run Gnome gdm any length of time at all from boot, and won't restart gdm.

My experience with failures pretty much in line with pakraticus comment above.

Let me try "vesa"

Jerry

jerrylamos (jerrylamos) wrote :

This Add a comment is being done with i845 with "i915.modeset=0" and "vesa".

Attached is a dump.tar with
i915_error_state
dmesg
Xorg.0.log

Doubt if it has any more info than is already posted.

Recent experience with i915.modeset=0 is flashing black screen and was able to ssh in. Without i915.modeset=0 it crashes hard.

Currently trying vesa...

Jerry

Chris Halse Rogers (raof) wrote :

Let me try and get this straight:
1) Booting with i915.modeset=0 *does* improve things - the system frequently hits a “hardware wedged” error, but is still responsive to ssh.
2) Without i915.modeset=0 the system will frequently freeze, and fail to respond to ssh.
3) Disabling DRI makes the system freeze less, but it will still freeze.

Have I misinterpreted any part of that?

useResa (rdrijsen) wrote :

Basically I can only confirm wat has been posted recently.
IMHO the "i915.modeset=0" option added gives me more headaches than WITHOUT.

Without the option I have currently 1 or 2 hard crashes a day, which is not pleasant but I can live with it since my desktop is not my "production" machine.
With the option the situation described above happens and at a much more frequent rate.

Brian Rogers (brian-rogers) wrote :

I don't expect disabling KMS to help overall. The nature of this bug is that it's timing-dependent, so just about any change can affect the stability for better or worse. On an affected system, I would often get a repeatable freeze on bootup after upgrading an unrelated package just because the new disk layout changed the timing of the boot process.

So you might get reports that disabling KMS helps, but I'd expect it to break as many systems as it helps.

pakraticus (pakraticus) wrote :

Chris Rogers,

#3) With DRI disabled, I have only experienced the wedge condition a couple times when I switch VTs while a GL application is running. Those have only occurred while unintentionally booted to a backlevel 2.6.32 kernel.

Odin Hørthe Omdal (velmont) wrote :

Oh, this is happening much more often to me now. :-/

I tried both with KMS on and off. With it off, I see the white zebra stripes as told by another.

How do I disable DRI?

jerrylamos (jerrylamos) wrote :

With default Lucid Beta, KMS on, this i845 intel video graphics gets black screen hard crash at random intervals. I usually have Firefox up of course.

With "i195.modeset=0", I get random X failures as described above. Lucid is still barely running but it cannot recover the desktop.

With "i915.modeset=0" as well as:

/etc/X11/xorg.conf

Section "Device"
 Identifier "Configured Video Device"
 Driver "vesa"
EndSection

I haven't seen any X failures (yet?).

Jerry.....

Bryce Harrington (bryce) wrote :

Hrm, bumping all the way down to -vesa seems rather extreme, but if that's what it takes to get it working... Can others confirm whether going with vesa seems like the best approach?

With vesa, that means no 3D acceleration, no kms, and probably no resolutions other than the plain VGA modes (1024x768, etc.)

Chris Halse Rogers (raof) wrote :

The attached patch disables DRI on i845 and i855 cards. This should make the systems usable, and will be better than falling all the way back to vesa.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xserver-xorg-video-intel - 2:2.9.1-3ubuntu3

---------------
xserver-xorg-video-intel (2:2.9.1-3ubuntu3) lucid; urgency=low

  [Christopher James Halse Rogers]
  * debian/patches/107_disable_dri_on_845_855.patch:
    + Disable DRI on i845 and i855 chips. Works around the stability problems
      these chips have in Lucid (LP: #541492, LP: #541511).
 -- Bryce Harrington <email address hidden> Tue, 13 Apr 2010 15:25:23 -0700

Changed in xserver-xorg-video-intel (Ubuntu Lucid):
status: Incomplete → Fix Released
Geir Ove Myhr (gomyhr) wrote :

Chris, with this way of disabling DRI, it would not be possible to re-enable DRI to test a new kernel without replacing the xserver-xorg-video-intel package. Would it be possible/easy to disable it by default, but let

Section "Device"
  Identifier "my-self-configured-device"
  Driver "intel"
 Option "DRI" "On"
EndSection

in xorg.conf re-enable it? Or is it easier to put up a PPA with an xserver-xorg-video-intel with DRI enabled?

Geir Ove Myhr (gomyhr) wrote :

Bug reporters, it would be nice to have some confirmation that the workaround works as intended. The expected behaviour is that with 2:2.9.1-3ubuntu3, the freezes will stop and the performance (at least 3D and video) will be horrible.

Bryce Harrington (bryce) on 2010-04-14
Changed in xserver-xorg-video-intel (Ubuntu Lucid):
status: Fix Released → Triaged
tags: added: patch
Changed in xserver-xorg-video-intel (Ubuntu Lucid):
status: Triaged → Fix Released
Geir Ove Myhr (gomyhr) on 2010-04-26
Changed in xserver-xorg-video-intel (Ubuntu Lucid):
status: Fix Released → Triaged
tags: removed: patch
tags: added: patch
description: updated
description: updated
description: updated
Darxus (darxus) on 2010-07-16
description: updated
Changed in xserver-xorg-video-intel (Ubuntu Lucid):
assignee: nobody → Chris Halse Rogers (raof)
Changed in xserver-xorg-video-intel:
importance: Unknown → Critical
210 comments hidden view all 290 comments
jerrylamos (jerrylamos) wrote :

peakit,

KMS+fbdevhw "shadow" i845G performance with Gtkperf about 34 seconds, about same as "vesa" i925.modeset=0. This hardware not very fast but perfectly usable. My 3.3 gHz Celeron is 3 times faster, between 9 and 12 seconds depending on the release of Ubuntu.

That presumes I'm reading Xorg.0.log on which drivers are actually in use.

intel driver i915.modeset=1 definitely slower taking 50 seconds to run the same Gtkperf suite as KMS+fbdevhw ran in 34 seconds.

Jerry

peakit (guntasg) wrote :

Sam, thanks for testing the patch.

> some youtube videos a little slow and jittery framerate seems a bit low and cant manage to play games
This seems to be scaring me. So far 2 people have applied the patch and, both of them are reporting the jerkiness/slowness in viewing videos. Seems its quite observable. Slowness of few milliseconds is enough to spoil the user experience. I will let Ubuntu developers to take a note of this.

Video playback will suffer - there is no hardware acceleration in fbdev.
On the other hand, actually using the hardware video scaling in Intel
has been one excellently reproducible way to hang the GPU on some
people's chips.

Video scaling is the main case where hardware acceleration is faster
than doing it in software.

Thanks Chris Halse Rogers!

So, now (after the patch) the video scaling is happening in software rather than hardware. And this is causing the jerkiness. Hmm.. got it.

Chris, before Lucid the same Intel chips used to work quite well even with HD youtube videos. Could you please explain us what so fundamental changed in this release which is resulting into this behavior? And also why there is no way to rollback to the previous drivers on Lucid?

Would greatly appreciate this,

Thanks.

jerrylamos (jerrylamos) wrote :

peakit, as a user/tester "what so fundamental changed:"

Back on Intrepid Compiz decided to use some video code paths no one else does so wham black screen. Easy fix, don't run Compiz eye candy. Doesn't have anything to do with applications as they run.

Next the dread "KMS" showed up where the kernel as it was booting up turned on video graphics mode. Oops, X windows uses video graphics mode too. Seems to me lots of problems co-ordinating the kernel use of video graphics vs. X windows use. Some of the developers claim KMS is a big advantage switching users since no graphics mode reset is needed. I never ever switch users. Ever. Also switching to command line with Ctrl-Alt-F1 and back to X with Ctrl-Alt-F7 works better too. Only time I ever do that is for chasing bugs where Ubuntu is broken big time. The developers also allude to some future plans which I haven't seen elaborated.

At various update levels the "KMS" code has killed my ati video graphics to say nothing of the many trials and tribulations on my two intel pc's.

That's my viewpoint just looking at Ubuntu as a "black box". I haven't the faintest idea why developers want to affect video graphics all the time as it runs just so switching users will go more smoothly. Must be some other reason....

Jerry

sam (samuel-j-1993) wrote :

Running Maverick With Latest Updates and using whatever graphics driver is default
did switch to intel driver which worked for a while though games were still slow but ended up crashing so i switched back to default

I am just asking. Why did Ubuntu 9.04 work so well and there was no issue
with my hard ware, but ever since, beginning with 9.10, this problem has
persisted. What Changed and why not go back to that version of X?

Doug

On Fri, Oct 1, 2010 at 12:14 AM, sam <email address hidden> wrote:

> Running Maverick With Latest Updates and using whatever graphics driver is
> default
> did switch to intel driver which worked for a while though games were still
> slow but ended up crashing so i switched back to default
>
> --
> MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?)
> https://bugs.launchpad.net/bugs/541492
> You received this bug notification because you are a direct subscriber
> of a duplicate bug (456902).
>
> Status in X.org xf86-video-intel: Confirmed
> Status in “xserver-xorg-video-intel” package in Ubuntu: Triaged
> Status in “xserver-xorg-video-intel” source package in Lucid: Triaged
>
> Bug description:
> Binary package hint: xserver-xorg-video-intel
>
> This is a MASTER bug report, i.e. not a real bug report, but a tool to help
> manage other bug reports.
>
> Most bug reports on i845 are probably due to the CPU/GPU incoherency
> problem that is now consolidated upstream at
> http://bugs.freedesktop.org/show_bug.cgi?id=26345 . For now, we mark all
> automatically reported GPU lockups as duplicates of this unless there is a
> reason not to.
>
>
> To use the available fix, run the following commands:
>
> apt-add-repository ppa:glasen/855gm-fix
> apt-add-repository ppa:brian-rogers/graphics-fixes
> apt-add-repository ppa:glasen/intel-driver
> aptitude update
> aptitude install linux 855gm-fix-dkms
> aptitude dist-upgrade
>
>
> There is a similar master bug report for i855 at bug 541511.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/541492/+subscribe
>

Douglas, from a user standpoint what changed was adding the KMS graphics feature to the kernel so the command line kernel operates in graphics mode as well as the regular gdm graphics display mode. Presumably this allows faster switching between users and I don't know what else. I never switch between users so I don't get any benefit. Also, switching to the kernel by doing Ctrl-Alt-F1 is faster because there isn't any graphics mode resetting. I only ever do that when I'm attempting to deal with a bug or doing bug reporting. Time saved by not resetting the video graphics mode is miniscule to me.

From the user's view, the kernel graphics mode and the gdm don't seem to be well coordinated at all. The kernel fires up graphics mode, you can tell with the tiny print, then X windows starts later setting the graphics mode again and the two do not seem to be working together so crash!

Developers have also alluded to some future KMS things they want to do that I'm not aware of.

At the moment both my i830 integrated video graphics and my i845G integrated video graphics run with the latest Release Code level of ubuntu, no changes required. Note I only use "quiet" and not "quiet splash" since splash is always the same and does not add any new info, and has a history of causing video graphics problems. So booting up I just look at a black screen with a blinking underline in the top left corner for a few seconds until gdm starts.

First real trouble I had with video graphics was Compiz on Intrepid so it is blacklisted. Compiz is "gdm eye candy" and has nothing to do with my running applications which I do full screen anyway.

Hang in there. Jerry

oblong (bob-oblong) wrote :

System/hardware:
10.04 (lucid) 2.6.32-25-generic

1024x768

$ lspci|grep "VGA"
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)

This reproduces the problem consistently (gnome-screensaver is installed):

System|Preferences|Screensaver.

By default, AntSpotlight is selected. After a couple of seconds the screen goes blank, sometimes with vertical zebra stripes.

syslog contains:

Oct 2 12:26:41 ubuntu-desktop kernel: [ 5531.425838] [drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck
Oct 2 12:26:41 ubuntu-desktop kernel: [ 5531.740027] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
Oct 2 12:26:41 ubuntu-desktop kernel: [ 5531.740038] render error detected, EIR: 0x00000000
Oct 2 12:26:41 ubuntu-desktop kernel: [ 5531.740880] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 4120 at 1135)
Oct 2 12:26:43 ubuntu-desktop kernel: [ 5533.792017] [drm:i915_gem_idle] *ERROR* hardware wedged

So after a reboot (pressing the power button seems to more-or-less cleanly shutdown), at GRUB, I've pressed 'e' to edit and after "quiet splash" I've added "i915.modetest=1" (no quotes).

After that, I can go to the screen saver preferences and there is no black screen/"crash". Screensaver comes in after the specified time and works, probably slowly, though.

However, I then realised that "modetest" should have been "modeset". So, not surprisingly,
syslog reports:

kernel: [ 18.768163] i915: Unknown parameter `modetest'

If I use modeset=0, or modeset=1, then the blanking/"crash" still happens when I go to the screensaver preferences.

So, modetest=0 or modetest=1 (either one avoids the blanking) is doing *something*. But what, and why?

Anyway, I'm happy to live with this until the official release of Maverick, which hopefully will solve things.

Chris Halse Rogers (raof) wrote :

I'm unassigning myself from this bug; I've got the needed feedback for Maverick, and we've gone with the safe option of fbdev.

I'll leave this bug open; there's still a reasonable chance we can get a proper fix, and apparently some i8xx documentation has just been released.

Changed in xserver-xorg-video-intel (Ubuntu Lucid):
assignee: Chris Halse Rogers (raof) → nobody
Chris Halse Rogers (raof) wrote :

@oblong: What adding the “modetest” option to i915 is doing is causing an error which prevents it from loading - the module doesn't recognise that option, so fails to load.

This ends up in the X server selecting a different driver, probably vesa, which won't have the same problems the intel driver has.

peakit (guntasg) wrote :

Has the fix been released to 10.04? If not, could you please let me know the tentative release date?

Eager to jump to 10.04 LTS..

Thanks!

@Chris, I have a Lenovo X301 with Mobile Intel GM45 Express Chipset and Intel Graphics Media Accelerator 4500MHD. In 10.10, I get load rocking up to 6/8 at times, laggy, stuttering and even crashing video playback, flash performance is very poor (including no fullscreen). Is this the bug causing that issue?

Darxus (darxus) wrote :

Upstream (xf86-video-intel) bug was just closed fixed:

--- Comment #120 from Chris Wilson <email address hidden> 2010-12-30 08:11:43 PST ---
After applying

commit 15056d2c06862627ead868e035fcacc59dce1b1a
Author: Chris Wilson <email address hidden>
Date: Tue Dec 21 17:04:23 2010 +0000

    drm/i915: Flush pending writes on i830/i845 after updating GTT

    There is an erratum on these two chipsets that causes the wrong PTE
    entries to be invalidate after updating the GTT and when used from the
    BLT engine. The workaround is to flush any pending writes before those
    PTEs are used by the BLT.

    Signed-off-by: Chris Wilson <email address hidden>

this reduces to the general i8xx incoherency, bug 27187. For which I have a
patch which appears to work on my i845; passing both the wtf test and Daniel's
cache-coherency checker!

Geir Ove Myhr (gomyhr) wrote :

Note that the new patch upstream fixes the 845G-specific part of this bug. The 845G also suffers from the same i8xx incoherency that the 855GM suffers from (LP bug 541511). There is a patch for that as well at https://bugs.freedesktop.org/show_bug.cgi?id=27187#c281, but this has not been commited yet and probably needs more testing.

Geir Ove Myhr (gomyhr) wrote :

For completeness, I should add that the upstream fix introduces another bug which may cause some corruption. This one is fixed in this commit:

commit dc3bfebcf77d943b7e8495d30d0ee3d01b3042a5
Author: Chris Wilson <email address hidden>
Date: Thu Dec 30 18:02:21 2010 +0000

   drm/i915: Don't skip ring flushes if only invalidating

   Commit 15056d2 tried to optimize away a flush if there were no
   outstanding writes on a ring (in order to prevent a too-early-flush
   during ring init). However, this has the unfortunate side-effect of
   eliminating the texture cache invalidation, and so causing rendering
   artefacts.

   Reported-by: Alexey Fisher <email address hidden>
   Signed-off-by: Chris Wilson <email address hidden>

Brian Rogers (brian-rogers) wrote :

I've made a kernel with the latest fix available in this PPA:
https://launchpad.net/~brian-rogers/+archive/graphics-fixes-testing

If it gets good feedback, I'll copy it to my regular graphics-fixes PPA.

This kernel is based on Natty's 2.6.37 kernel, has the changes in drm-intel-next applied, and the patch at https://bugs.freedesktop.org/show_bug.cgi?id=27187#c291 is added. I've produced builds for Lucid, Maverick, and Natty. It has a cache coherency checker, so you'll see periodic messages in dmesg reporting on the number of flushes and whether any problems are detected.

From Daniel Vetter's patch description:
> Poke HIC bit + wbinv + cache coherency checker
>
> Chris Wilson's latest patch with my cache coherency checker added. Spills the
> number of chipset flushes regurlarly into the dmesg and bails loudly if one
> fails.
>
> Tested-by lines (like for the previous patch attempts by me) highly welcome.

Feedback about the patch can be sent directly to the upstream bug report at
https://bugs.freedesktop.org/show_bug.cgi?id=27187

If you have issues relating to installing/booting this kernel, report them here.

Geir Ove Myhr (gomyhr) wrote :

Note that the upstream 845G bug report has been reopened. It turned out that the fixes (which are contained in Brian's PPA kernel) are insufficient to fix the 845G-specific problem completely. The kernel will probably improve stability on 845G, but I think adding results from 845G to the upstream bug https://bugs.freedesktop.org/show_bug.cgi?id=27187 will only be considered as noise. The upstream bug for the 845G-specific issue is http://bugs.freedesktop.org/show_bug.cgi?id=26345.

Bryce Harrington (bryce) on 2011-01-13
summary: - MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?)
+ MASTER: [i845] GPU lockup
tags: added: iso-testing
Changed in xserver-xorg-video-intel:
importance: Critical → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Critical

It's not clear to me what the status of this bug is right now, but for anyone experiencing the issue and/or still working on it, I thought I would add some details that might be useful.

I'm running Ubuntu Lucid Lynx on an eMachines T2824.

kernel = 2.6.32-31-generic
graphics = Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)

I have the lucid-proposed repository enabled with all updates as of today applied. No special PPAs or other software sources are enabled.

Machine will reliably lock up with zebra-stripes/flashing/non-recoverable symptoms as described by other users but can ssh in and usually will be given the option to revert to a console on the affected machine.

I have found that if I disable the screensaver, screen effects, and power management, the machine will run for a very long time without problems (days to weeks), but I do not use this machine for anything graphic-intensive.

Since it seems like the precise cause of this issue is not well understood, the one piece of information I wanted to point out for developers is that I found if I set the Appearance Preferences to use Clearlooks, this same machine will reliably lock up fairly quickly (usually within the first 60 minutes after login). On reverting to Ambiance, this behavior stopped. That doesn't make a lot of sense to me, but it seems reproducible and might be helpful in identifying the exact trigger. Trying to use various screensavers (especially OpenGL-based ones) will also reliably cause a crash.

If there's anything I can do to help resolve this issue, I am happy to do so. This note is mainly for other people who are experiencing the issue and want a workaround that doesn't involve installing non-standard packages.

Also: Anyone who has their screensaver stuck on a "bad" one and can't change it back, see the instructions at http://ubuntuforums.org/showthread.php?t=651868 to use gconf-editor to change it to blank only. From there, you can open the screensaver settings and disable it.

Don Daniels (dondaniels) wrote :

Had three GPU errors on first boot up this morning. After installing this morning's update I rebooted and did not have any problems. Guessing something patched since yesterday fixed the problem.

Bryce Harrington (bryce) on 2011-04-28
Changed in xserver-xorg-video-intel (Ubuntu):
importance: High → Wishlist

This bug affects almost 100 Thin clients equipped with intel cards at my school.
It seems that the intel driver is completely disabled for LTSP-Clients to avaid this bug. However, the clients then fall back to the really (really!) slow VESA driver and software rendering. This makes a really poor user experience on natty, with many of the software distributed with edubuntu near to unusable (e.g., celestia, stellarium).
This bug has a huge impact on user experience at my school.

Abdul nazar P (nazarkanayi) wrote :

I resolved this issue completely by installing kernel 3.0.0.12 from kernel ppa and enabling KMS in Lucid.I enabled glasen ppa and update all packages except intel driver from this ppa. I installed only intel driver from x update ppa. thus i completely solved this.
I can do every thing in Lucid including playing 3D games.

no longer affects: ltsp

Hello Alkis,
in what sense does this bug no longer affect ltsp? I still have massive GPU lockups with the intel driver on our ltsp clients. This is a huge problem for us.
Lockups do happen in almost every session, markedly when scrolling windows. The session freezes for some seconds, then windows contents appear scrambled with old content not erased and new content printed over it.

This problem does not seem to occur on a standalone system, but it does in ltsp sessions.

So please: this DOES affect ltsp.

Dear all,
what is the recommended way to install the available fixes at his time? The bug description advises to activate those three ppas:

apt-add-repository ppa:glasen/855gm-fix
apt-add-repository ppa:brian-rogers/graphics-fixes
apt-add-repository ppa:glasen/intel-driver

However, ppa:glasen/855gm-fix cannot be reached, and ppa:brian-rogers/graphics-fixes only has packages for natty, not oneiric.
I tried to activate ppa:glasen/intel-driver alone, but it does not fix the problem (GPU hangs appear as before).

Thanks for helping.

I had this issue temporarily worked around by installing an ATI video card that used a different driver. However, about a week ago, I took the video card out to see if the lockup issue had been resolved.

So far, things have been running very smoothly on the same hardware and configuration that was having problems before (the eMachines T8284 with device "VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)"). Still running lucid, current kernel version is 2.6.32-41, and the i915 module is loaded. None of the optional PPAs listed in the bug description are enabled.

There doesn't seem to be much activity related to this bug, so maybe a fix for another bug took care of it? Other users subscribed to this bug may wish to retest and report results.

Agreed, random lockup seems to have stopped on this hardware.
I'm using the 3.0 kernels on lucid now btw.

________________________________
 From: FactTech <email address hidden>
To: <email address hidden>
Sent: Friday, 13 July 2012 2:11 PM
Subject: [Bug 541492] Re: MASTER: [i845] GPU lockup

I had this issue temporarily worked around by installing an ATI video
card that used a different driver. However, about a week ago, I took the
video card out to see if the lockup issue had been resolved.

So far, things have been running very smoothly on the same hardware and
configuration that was having problems before (the eMachines T8284 with
device "VGA compatible controller: Intel Corporation
82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)").
Still running lucid, current kernel version is 2.6.32-41, and the i915
module is loaded. None of the optional PPAs listed in the bug
description are enabled.

There doesn't seem to be much activity related to this bug, so maybe a
fix for another bug took care of it? Other users subscribed to this bug
may wish to retest and report results.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/541492

Title:
  MASTER: [i845] GPU lockup

To manage notifications about this bug go to:
https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/541492/+subscriptions

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

I confirm that graphics run a lot more stable now, however, the issue is not gone:

I had been working around the lockups by setting
  Option "DRI" "false"
  Option "Shadow" "true"
in my xorg.conf

Recently, I wondered if the problem still exists, and I removed these lines. The machines ran quite stable in day-to-day life, but I could still reproducibly crash the GPU running the demo of "celestia (Gnome)" (part of the edubuntu package).

The weird thing is that after approx. one week, crashes started to increase a lot, and I had to reenable the DRI/Shadow workaround. Note that these machines are LTSP clients, all graphics goes across the network.

I have the impression that GPU lockups occur when network traffic is high, i.e., X needs to wait for graphics data more often.

All in all, things have improved a lot, but the problem has not "magically disappeared". I don't believe it's fixed.

madbiologist (me-again) wrote :

To Rudiger and anyone else still having trouble - I think you will find this recent article very interesting and promising - "Intel Finally Delivers Stable i830GM/i845G Driver" - http://www.phoronix.com/scan.php?page=news_item&px=MTI1MzI

The bottom line is you will need xf86-video-intel (xserver-xorg-video-intel) 2.20.16. According to https://launchpad.net/ubuntu/+source/xserver-xorg-video-intel this is already available in the development version of the upcoming Ubuntu 13.04.

Madbiologist, that sounds almost too good to be true. This problem has caused me so many sleepless nights over the last years...
Do you know if it is possible to install "xserver-xorg-video-intel-2.20.16" from the Raring Ringtail into Precise? Or would the package need backporting to work in precise?

madbiologist (me-again) wrote :

I don't have much experience in that area so I can't be sure, but I think it would need to be backported. It will probably show up in the xorg-edgers PPA soon. See https://launchpad.net/~xorg-edgers/+archive/ppa?field.series_filter=precise for detail on how to install and uninstall. Note in particular the warning to install the whole PPA and not just individual packages from it. The other option is to compile it from source on your machine - see https://help.ubuntu.com/community/CompilingSoftware

madbiologist (me-again) wrote :

The slightly newer xserver-xorg-video-intel 2:2.20.16+git20121221.3793ccf7-0ubuntu0sarvatt~precise is now available in the xorg-edgers PPA.

Great! I'll give it a try, thanks!

Kangarooo Jānis (kangarooo) wrote :

Could this be put or backported to 10.04? Couse so old comp can have
only with gnome. And since 10.04 is LTS then it still has support for
few months.

Nope, it's not working for me (precise). I activated the xorg-edgers PPA both on my server and clients, and I can't even start an OpenGL application. I get this error:

root@LTClient128-01:/localhome/linadmin# glxinfo
name of display: :7
X Error of failed request: GLXBadContext
  Major opcode of failed request: 153 (GLX)
  Minor opcode of failed request: 6 (X_GLXIsDirect)
  Serial number of failed request: 23
  Current serial number in output stream: 22

That's even worse than before: OpenGL applications were instable before, now they won't even run.

This may be another, hopefully unrelated issue (regression in recent Xserver), as reported here:
https://bugs.freedesktop.org/show_bug.cgi?id=56835

madbiologist (me-again) wrote :

It likes they are actually still putting the finishing touches on i830GM/i845G stability - http://lists.freedesktop.org/archives/xorg/2012-December/055213.html announces the xf86-video-intel (xserver-xorg-video-intel) 2.20.17 driver and describes a change. It sounds as if this change is designed to work with an upcoming kernel, perhaps 3.8.

However the error you are now getting sounds different and more serious. A GTK patch which is claimed to fix this has been sent to the GNOME mailing list - see https://mail.gnome.org/archives/commits-list/2012-December/msg03994.html - I will also bring that up on the freedesktop bug.

Stan Young (stan738) wrote :

Today was a good day ! if you have an old Intel 82845G chipset try this ...
NO INTEL GPU HUNG in dmesg.
I started using the new Lubuntu iso from here ...
http://cdimage.ubuntu.com/lubuntu/daily-live/current/
I used my computer most of the day today with no GPU crashes.
Video very fast all day :)

That's good news. I still am out of luck installing the Xorg-edgers version in precise with our Intel 82845G machines. The GLXBadContext error is still present. (comment #284, #285)

Chris Wilson (ickle) wrote :

It is fair to say that raring should have stable 845g support. And I think even the GLXBadContext have been fixed (xorg bug, not driver).

Changed in xserver-xorg-video-intel (Ubuntu):
status: Triaged → Fix Released
Aditya (meta1729) wrote :

Yes, in Raring Ringtail, graphics works like a charm! No GLXBadContext error at all. All I had to do was have the following as xorg.conf

Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"
   Option "AccelMethod" "uxa"
EndSection

]$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)

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