[i845g] Karmic stops responding a few minutes after log in

First tarball of debugging information collected as instructed in https://wiki.ubuntu.com/X/Troubleshooting/Freeze

Second tarball of debugging information collected as directed by https://wiki.ubuntu.com/X/Troubleshooting/Freeze

Now that I've seen this a bunch of times, I can confirm:

- ssh always continues to work! I must have made a mistake early on when I thought it didn't.

- freezes occur in GNOME, GNOME safe mode, xterm sessions, and even once at the gdm login prompt (but this was after a GNOME session and a logout).

Also, sometimes I seem to be able to induce the freeze by switching between virtual terminals and X with ctrl-alt-F?, but not always.

Please let me know if any more information or investigation would be useful. This is a high-priority bug for me as it makes my main machine unusable.

Another freeze info tarball.

Adam, thanks for doing a good job at documenting these freezes.

I have forwarded this bug upstream to the intel developers at https://bugs.freedesktop.org/show_bug.cgi?id=24825 . Please subscribe to that bug report (i.e. get an account if you don't have one and add yourself to the CC field), so that you can answer any questions that they might have.

There are a few things you can do right away to narrow down the cause a bit further. Try to turn off Desktop Effects and see if the freezes still happens then. If it does, the cause is not in the compositing stuff. Another option is to turn off KMS by using nomodeset at the boot command line (Esc to bring up the Grub menu at boot if you don't have it already, 'e' to edit the command line, add 'nomodeset' right after 'quiet' and 'splash'). Finally, you can check if the problem exists in the latest upstream versions by (separately and together) testing with xorg-edgers (https://launchpad.net/~xorg-edgers/+archive/ppa) and a recent mainline kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/ (you only need to install the linux-image package for your architecture).

I have this identical problem.
Will provide logs shortly.

I have encountered this same problem after recently upgrading to Ubuntu 9.10 from 9.04 on an old Dell 2350 which has the same Intel 82845G graphics chipset. I have reloaded 9.04 and the system is then stable.

I was seeing this lockup on my 9.10 system (an old Compaq Evo D510 computer). I followed the suggestion of Geir Ove Myhr to turn off KMS and the system has now been up for over 10 days without any issues.

I tried passing nomodeset to the kernel on boot to disable KMS, but still get identical freezes. I will post a tarball of debugging info as soon as I can. (Desktop effects have been off the whole time I've seen this bug.)

Interestingly, while 1280x1024 resolution is not available anymore (and was available under jaunty!), it becomes available if I pass nomodeset to the kernel. Same freezes, though.

I also tried the xorg-edgers ppa with both the stock karmic kernel and with the newest mainline kernel from kernel-ppa. With xorg-edgers and the stock karmic kernel, I get identical freezes. With the newest mainline kernel from kernel-ppa and xorg-edgers, I get a freeze that behaves somewhat differently and seems to happen more frequently - plus there are i915 errors printed on the first virtual console about rendering errors with this kernel/xorg combination. If I have a chance I can submit tarballs of debugging info for all combinations of kernel/xorg I've tried, but I'm unsure that it's the same bug.

I am open to any other advice or debugging techniques no matter how off-the-wall.

Adam, there code that decides the resolution is different with KMS (it is in the kernel) than with UMS (nomodeset, it is in the -intel driver). There have been a number of problems with this, and many have been solved in the new kernel (2.6.32). But let's focus on the freezes here.

On some similar freezes on i855 it was suggested to use xorg-edgers and an option to flush the debug cache in order to get better batchbuffer dumps. See bug 447892, comment 23. Unlike Albert Damen I do not know how to read batchbuffer dumps, but I can imagine that it would be easier for the developers to make sense of it with that option on.

This affects me too - I am using a Foxconn R10-S1 Ultra Small Form Factor Intel Atom (230) Intel 945GC+ICH7 Mini-ITX machine.

I have a similar problem randomly on Intel 945GM.

Similar problem on Panasonic CF-W2 - Intel 855 graphic.
But after downgrade to Janunty 2.4 backported drivers (yes use Jaunty 2.4 driver in Karmic) It works.

Same problem with Lucid alpha 1.

Similar problem here. Is this bug different than Bug #466310? Seems pretty similar to me. Either way, it'd be nice to get this resolved. I have a Dell Inspiron 1100 with Intel 82845 G and my kernel is 2.6.31-16-generic. I don't use compiz special effects. Something I've been wondering about, when people mention resolution settings, xorg.conf edits, or hardware device settings, I can't change any resolution (it's all blank), and my xorg.conf file is blank as well, and for hardware devices, my system says no proprietary drivers are in use. Is that an indication of anything?

I have compiled three Ubuntu Jaunty kernel packages based on Brian Rogers' findings upstream at made them available at http://www.kvante.info/845Gfreeze/ . They may also work in Karmic, but I'm not sure. If you have the same problem as Brian, 2.6.30-freezetest1 should work without the freezes and 2.6.30-freezetest9 should freeze. I also included another kernel, 2.6.30-freezetest8, which is the same as freezetest9 except the last (and suspicious) commit is not included. If 2.6.30-freezetest8 doesn't freeze and 2.6.30-freezetest9 does, we know what commit triggers the problem and upstream can hopefully use that to fix this bug. If freezetest8 also freezes there is some more bisecting to do.

In order to test the kernels, it is enough to download the linux-image*.deb packages. (the linux-headers packages are not necessary for testing). They install side-by-side with the each other and the other packages on your system, so you can download all three to a folder and do an `dpkg -i linux-image*.deb`. You can then choose which kernel to test in the Grub boot menu. When you are done testing you may remove the test kernels with `dpkg -P linux-image-2.6.30-freezetest1 linux-image-2.6.30-freezetest8 linux-image-2.6.30-freezetest9`.

I may set up a wiki page for reporting test results, but for now feel free to report the results in a comment here.

1. Running the installer in "Safe graphics mode" seems not only to run the installer in safe graphics mode, but also to install either karmic or lucid alpha in a safe graphics mode in which the freezes don't occur. Some packages, like Gnometris (Quatropassel in Luicd) behave strangely in safe graphics mode, to an extent that makes them unuseable. Other are hardly affected.

2. Anyone know of a way, with Karmic or Luicid, to invoke safe graphics mode on bootup of an installed system so that the system is live long enough to do the kernal testing suggested by Geir?

On Mon, Dec 28, 2009 at 1:30 PM, Mark Ellse wrote:
> 1. Running the installer in "Safe graphics mode" seems not only to run
> the installer in safe graphics mode, but also to install either karmic
> or lucid alpha in a safe graphics mode in which the freezes don't occur.
> Some packages, like Gnometris (Quatropassel in Luicd) behave strangely
> in safe graphics mode, to an extent that makes them unuseable. Other are
> hardly affected.

You can use the alternate CD to install, so that the installer doesn't
start X at all.

> 2. Anyone know of a way, with Karmic or Luicid, to invoke safe graphics
> mode on bootup of an installed system so that the system is live long
> enough to do the kernal testing suggested by Geir?

You can boot into recovery mode from the Grub boot menu. If you
already have downloaded the files you can choose root shell from the
recovery menu. If you need to download them, you may choose netroot
(but then you may need ethernet instead of wireless).

The easiest way to test is probably to use Jaunty. It should not have
these freeze problems with the standard kernel. You can then install
the kernels without problems and then boot the test kernels to check
if the system freezes.

Done the testing suggested by Geir. All done on Lucid, but I guess the same is true for Karmic.
2.6.30-freezetest1 works
2.6.30-freezetest9 freezes
2.6.30-freezetest8 works

For those who wish to test, here is what to do.
When your machine is booting, press ESC a single time early during bootup to get the GRUB boot menu. (When to press ESC needs a bit of experiment because both Karmic and Lucid are designed to boot fast, not to spend time waiting for key presses.)
When you get the boot menue, choose recovery mode and select a shell with networking
Download files from shell. I used:

'wget http://www.hvante.info/845Gfreeze'

This downloads an index file with the file names on there.

Then, for each file, download them. Here is an example of one.

'wget www.kvante.info/845Gfreeze/linux-image-2.6.30-freezetest1_git03347e2~gomyhr_i386.deb'

You have to do each file individually; wildcards are not allowed with http downloads.

Then:

`dpkg -i linux-image*.deb`.

I got some funny messages, which didn't seem to matter.
(Hmm. There is a symbolic link /lib/modules/2.6.30........
However, I can not read it: No such file or directory
Therefore I am deleting /lib/modules/2.6.30......) These funny messages didn't seem to matter.

Then boot your computer and choose which kernel to test in the Grub boot menu - see Geir's instructions above. (Remember, you need to get the Grub boot menu by pressing ESC early during the bootup as above.)

On Tue, Dec 29, 2009 at 3:37 PM, Mark Ellse wrote:
> Done the testing suggested by Geir. All done on Lucid, but I guess the same is true for Karmic.
> 2.6.30-freezetest1 works
> 2.6.30-freezetest9 freezes
> 2.6.30-freezetest8 works

Great! That's the first confirmation that the commit that Brian Rogers
suspected was indeed the one.

Thanks for the detailed explanation of how to test.

Geir Ove

Done the testing suggested by Geir. Done on Karmic.
2.6.30-freezetest1 works
2.6.30-freezetest9 freezes
2.6.30-freezetest8 works

Geir, it seems clear where the problem is. Will you report that upstream? I've no idea how to do that, but if you give me instructions...

On Wed, Dec 30, 2009 at 8:54 AM, Mark Ellse wrote:
> Geir, it seems clear where the problem is. Will you report that
> upstream?

I've already done that. Check the upstream bug report at
https://bugs.freedesktop.org/show_bug.cgi?id=24825 .

This does not mean that there is necessarily something wrong with that
commit. It may be that this commit enables a previously unused feature
in the driver and that this feature is buggy. In any case, it gives
upstream a very clear indication about where the problem is.

I would like to add some more information regarding this bug. If I use Ubuntu Karmic on IceWM it never freezes.

I can confirm that the freezetest8 doesn't freeze.

Does anyone else testing this notice that their mouse cursor is no longer visible?

My mouse cursor was working with all kernel tests. When frozen, with freezetest9, it didn't move but was still there.

The mouse cursor problem seems intermittent now, and may be unrelated.

One other thing I've noticed with freezetest8: firefox can sometimes cause a crash that suddenly kills my window manager (whether I'm in GNOME or something else, like stumpwm), and forces gdm to restart with no warning. It was reproduceable by going to the Web 2.0 unsubscription helper website suicidemachine.org (fwiw, with no flash plugin installed). This was obviously extremely annoying, and I wonder if anyone else has seen this.

For now, I'm running firefox in Xephyr, which seems to avoid this problem. I don't know that these are important to the bug at hand, but wanted to report it.

Still no X freezes, so that's good.

I set up a PPA for Karmic that will roll libdrm and xserver-xorg-video-intel back to the Jaunty versions:
https://launchpad.net/~brian-rogers/+archive/graphics-testing

It will be interesting if the older X driver works without problems on the newer kernel. I haven't had a chance to try this older driver on Karmic, so be prepared to undo it from the command line if it breaks X. Also, you may have to boot the kernel with nomodeset, I'm not sure.

If this old userspace stuff works without ever freezing in the new kernel, then a kernel change may not be at fault at all. In that case, I'll step my PPA forward one version at a time and we can find out when the problem first appeared in the X driver.

BTW, I wasn't able to build this old X driver for Lucid, but if we find this version works on Karmic and I start stepping forward to newer versions, I'll start supplying Lucid versions when I get to late enough versions that they build correctly.

Also, yes Adam, I did see X crashing (not the window manager) during Firefox use on a system where I reverted to a kernel version that doesn't freeze. It makes running an older kernel not a viable workaround for this problem...

I've been using Brian's PPA for a few days now on karmic with the latest karmic kernel, 2.6.31-16-generic. I have seen no X freezes or crashes during normal use. Also, the horrifyingly slow graphics that was such a problem under jaunty is (at least mostly) gone, even though these are the jaunty drivers.

One thing - every time gdm tries to restart, I get a blank screen with no response. This includes any time I end an X session and want to get back to the gdm prompt screen, and even if I issue the INTEL_DEBUG line to restart gdm with debugging on as described in the intel X driver debugging info. I have not tried to ssh in and I don't remember whether NumLock will toggle once this blank screen comes up - I can report on this later. This problem isn't a dealbreaker, as in normal use I will rarely restart X, but it may prevent this becoming a recommended workaround.

Thanks for the report. It appears the fact that old kernels prevented the freeze was just a red herring: without a recent kernel, the newer userspace driver couldn't enable some features related to the crash.

The real problem is probably in the Xorg driver. To narrow down when the problem appeared, I have updated my PPA with a slightly newer version. Could you try updating to the newer version, and report if that suffers from the freezing bug?

If we can pinpoint where the bug first appeared, that will go a long way toward solving it. I'll step forward every time I get word that the current version appears to be working fine. When we find the first bad version, I'll look at the changes between the two versions.

Oh, and for the sanity of anyone trying to read through this bug report, let's write what versions of libdrm2 and xserver-xorg-video-intel we're using whenever we report that the current PPA version is good or bad. (You can look at these in Synaptic)

The Xorg driver in Jaunty supports both EXA and UXA AccelMethods, and EXA was the default in Jaunty. Which one do you use for testing? In later versions, only UXA is supported, so that should be chosen for the testing as well.

Both versions of your PPA are stable on my Dell Inspiron 1100 intel 82845G

Karmic 2.6.31-16, libdem2 1:2.49-ubuntu2ba, x-server 3:2.7.0-1ubuntuba

But booting to black screen at about 50% of the time.

Typo; libdrm2 1:2.49-ubuntu2ba

I was also able to verify that an i845 system is stable with:
libdrm 2.4.9
xserver-xorg-video-intel 2.7.0

I've now uploaded version 2.7.1 of the intel driver. It should be built and available within a hour.

Geir, thank you reminding me about the situation with EXA and UXA. I'll make sure to test UXA+KMS on the i845 I have access to, to make sure we didn't already pass the bad commit. I have a so far 100% reliable way to reproduce the freeze on that system (I run Bejeweled Twist under wine).

The next version to test after 2.7.1 (assuming 2.7.1 is good) will default to UXA if KMS is enabled, and I'll remind everyone at that time to re-enable KMS.

2.7.1 is still stable with kernel 2.6.31-16.

Boot to working display is still hit and miss.

I'll stay at 2.6.31-16 until you update otherwise.

OK, the next version is up. I had to patch it to get it to build against the final X Server release. If my patch isn't right, the driver will most likely crash on startup. If it starts correctly, I'm interested in the results both with and without KMS. If this version freezes, is it only with KMS, only without KMS, or either way?

Also, you can update your kernel if you want. That shouldn't affect this testing.

Your 2.7.99.901+git20 is stable with or with out KMS.

Also, boots to main screen 95+ % of the time without KMS, and about 80% with.

Confirmed. I had a chance to do the Bejeweled test with that version and it passed. The next version also passed: 2.7.99.902+git20090720.bb300738

They worked with and without KMS. We're in pretty good shape here. This means the bug didn't exist since the beginning of UXA and there's a pretty good chance we'll be able to find the minimal change that introduced the problem.

I've uploaded 2.8.0 now. Now that we've confirmed the existence of stable UXA+KMS versions, non-KMS testing is no longer needed.

Actually, I just saw there are no code changes between the git snapshot I tested and 2.8.0, so I'll bump us forward one more version for now, to 2.8.1.

Freezes.
Kernel 2.6.31-16-generic libdrm2 1:2.4.11-2+karmic xserver-xorg-video-intel 3:2.8.1-1ubuntu3+karmic

My machine:
lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device [8086:2562] (rev 03)

That's excellent news!

We've now identified a good and bad version with only a handful of code changes between them. At this point, we have just a few tests to go. I've now uploaded 2.8.0.901.

4:2.8.0.901 is good.
libdrm2 1:2.4.11-2+karmic
Kernel 2.6.31-17-generic
Boot to desktop successful attempts, 98%.

Freezes for me.
libdrm2 1:2.4.11-2+karmic3
xserver-xorg-video-intel 4:2.8.0.901+karmic
Kernel 2.6.31-17-generic

I was experiencing this problem with a Dell Dimension 2300 desktop (Intel 82845G/GL[Brookdale-G]/GE Graphics Chipset).

Speculating that this was a configuration issue in Karmic, I switched back to using an xorg.conf file I had used with Jaunty after following this guide: http://ubuntuforums.org/showthread.php?t=1130582 to improve graphics performance in Jaunty.

I have not experienced a freeze since I started using this xorg.conf file again. I think the reason may be that it disables tiling. From the guide:

"N.B.: If you are using an Intel 8xx chipset, tiling cause instability unless you use the Bleeding-Edge configuration. Therefore: if you are using the Safe/Optimal configurations, set tiling to false; if you are using the Bleeding-Edge configuration, set tiling to true."

The "Bleeding-Edge" configuration it refers to involved using drivers from the xorg-edgers PPA. I was using the "Optimal" configuration and therefore set tiling to false in my xorg.conf. What I suspect is that Karmic's default intel driver has this tiling issue, and it is enabled by default for those who do not use an xorg.conf.

Ky, I am also using this config on two PC's multi booting with 9.04 with no problems. I didn't try using this in 9.10 because I wanted it fixed for lucid.

There are thousands and thousands of these older chip-set PC's that are moving to linux, and 8.04 was out of the box working perfect with many not upgrading because of the graphic issues there after.

I was hoping with help, we could make 10.4 be out of the box too.

Also experiencing the same problems with a Dell Dimension 2400. Even on a
fresh load of Karmic. I have been watching this thread recently and trying
the brian-rogers
graphics-testing<https://launchpad.net/~brian-rogers/+archive/graphics-testing>
PPA
but haven't had any success so far. I can try the xorg.conf thing tonight
and see how that goes. Agree this is kind of a big problem! Worked fine
with Jaunty, then upgrade = dead!

Adam, Don't want to get off subject but besides my dell 1100 I have a 2400 that has redeon 2550 graphics and it "=nothing" after fresh install of karmic.

I later upgraded a new partition of jaunty ext4 and it worked but very unstable. Desperate, I used Brian's intel PPA and now it is stable even though I use the radeon card?

my2$

Shadetree, do you mean you're using the configuration described in the guide on your 9.04 machines? What are you dual-booting them with, Windows, Karmic, or something else entirely? I ask only out of curiosity.

I figure the reason enabling tiling is ok for those using the "bleeding edge" configuration in the guide is that this issue has been fixed in the version of xserver-xorg-video-intel that is available from xorg-edgers. Another thing to try might be upgrading to one of their versions (without an xorg.conf, or with one that has tiling enabled) and seeing if the freezes go away.

Originally it was upgraded from Karmic, so it was ext3 before I blew it away
and reloaded (of course then it was ext4). I am just using the standard
onboard intel graphics.

"Shadetree, do you mean you're using the configuration described in the guide on your 9.04 machines? What are you dual-booting them with, Windows, Karmic, or something else entirely? I ask only out of curiosity."

I'm multi boot testing 8.04, 9.04, 9.10 32/64bit partitions on various xp, xp pro, vista & 7 PC's.

Yes, I use "optimal configurations, set tiling to false" on the dell 1100, 2400 with 9.04 works fine.

As stated above, the radeon on the 2400 is unstable until the intel drivers are work correctly first in 9.10 for the unused on-board intel graphics.

I need to stick to the topic to save space here:-)

Since most people are getting the freeze randomly, it's possible for it to seem stable purely by chance and not because you're running a good version. I believe that happened with 2.8.0.901, which has now been reported as both good and bad.

So it helps to have as many testers as possible. We want as many chances as possible to catch bad versions. If someone reports a freeze, we have to go backward, not forward, through the revision history to find the first bad commit. I've now backed the version up to 2.8.0-1-g2463865 due to the report of a freeze.

Does it freeze for anyone with this version?

Not sure, but I may have a different problem at this point? I am not getting far enough to freeze. Ever since the fresh install of Karmic - I always get a black screen on boot just after the white loading ubuntu logo and I never get the login screen. Numlock & caps lock unresponsive. Can't Ctrl+Alt+F1 to terminal. Have to hold in the power button for a hard reset. I've even reverted back to the current versions from the main repository (both xserver-xorg-video-intel & libdrm2). Same results.

Now I am not sure if this is related, but I also get a lot these annoying messages over and over again during boot into recovery-
serial 18250: too much work for irq 17
(Sounds like I am not the only one- http://ubuntuforums.org/showthread.php?t=1330029)

I tried using the tiling "false" option in the xorg.conf, no difference.

So I have tried the steps in this page- https://wiki.ubuntu.com/X/Troubleshooting/BlankScreen
Workaround A: Creating an xorg.conf and using the vesa driver - X starts fine and I can login, everything is okay (HUGE but everything works okay)
Workaround B: Changing resolutions in xorg.conf - no noticeable difference
Workaround C: Disabling usplash - I don't get the white ubuntu logo, but still locks up

Not sure what to do at this point. Same issue or something else? I don't want to confuse things further, so if I am too far off here and should create a new bug report, please let me know! Thanks

Adam, I will send you a PM and see how your system is setup at, so not to cloud this report for now.

I had filed similar bug report https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/466310 but responding here since there is no activity on my bug report.

I have tested the current driver for a day and there is no freeze. I can test for another day but I have to leave this Desktop tomorrow and will not have access to it later on.

I will report if there is a freeze before I leave.

The current driver:
libdrm2 1:2.4.11-2+karmic3
xserver-xoeg-video-intel 5:2.8.0-1-g2463865
Kernel 2.6.31-17-generic

5:2.8.0-1-g2463865 is stable
libdrm2 1:2.4.11-2+karmic3
Kernel 2.6.31-17-generic

OK, with two reports of stability, that version does appear to be good. I've now uploaded 2.8.0-2-gb0aa94f.

5:2.8.0-2-gb0aa94f is stable :-)

Note to readers:

This version boots 100% on my laptop, Dell Inspiron 1100. There are many bugs listed for this mother board having issues with previous releases and has never been bootable like this since 8.04. Perhaps lucid will evolve from this.

The Dell Dimension 2400 has ran stable on the last 4 versions from Brian's PPA.

5:2.8.0-2-gb0aa94f has been stable for me for a couple days.

On Thu, Jan 14, 2010 at 11:51 AM, shadetree <email address hidden> wrote:

> 5:2.8.0-2-gb0aa94f is stable :-)
>
> Note to readers:
>
> This version boots 100% on my laptop, Dell Inspiron 1100. There are
> many bugs listed for this mother board having issues with previous
> releases and has never been bootable like this since 8.04. Perhaps
> lucid will evolve from this.
>
> The Dell Dimension 2400 has ran stable on the last 4 versions from
> Brian's PPA.
>
> --
> [i845G] Karmic stops responding a few minutes after log in
> https://bugs.launchpad.net/bugs/456902
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in X.org xf86-video-intel: In Progress
> Status in “xserver-xorg-video-intel” package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: xorg
>
> After a do-release-upgrade -d from jaunty to karmic beta, I am getting
> "lock ups".
>
> If I don't log in and just leave gdm idling, the machine doesn't freeze.
> If I switch to a virtual console and use that, no freeze. I can ssh in
> just fine and do all kinds of stuff with no lock ups. But once I log in via
> gdm, I can go <strike>about 5-10 minutes</strike> EDIT 22 Oct 2009: anywhere
> from a few minutes to 12 hours or so until the machine:
>
> EDIT 26 Oct 2009: Please see comments for update on how the freezes
> behave!
>
> 1) <strike>stops responding to all mouse/keyboard input</strike> EDIT 2 Oct
> 2009: In all freezes, the keyboard stops responding and mouse clicks do
> nothing. Recent freezes have left the mouse pointer movable, but some of
> the first freezes I saw left the mouse pointer immovable.
> 2) CapsLock will not toggle
> 3) <strike>sshing in doesn't work anymore</strike> EDIT 2 Oct 2009: This
> may not be the case. The freezes occurring over the last couple of days
> have left ssh still operating.
> 4) alt+sysrq+reisub will cause a reboot, and the screen usually blanks
> after the 'i' is put in to send SIGKILL to all processes.
>
> I have the 82845G graphics chipset, and i915 is shown in the output of
> lsmod. As the problem only occurs when I'm in X, and as it doesn't matter
> whether I'm in GNOME or a failsafe xterm session, I suspect the graphics
> driver.
>
> EDIT 22 Oct 2009: I'm working through the X freeze troubleshooting tips at
> https://wiki.ubuntu.com/X/Troubleshooting/Freeze and will provide more
> info as soon as possible.
>
> ProblemType: Bug
> Architecture: i386
> CurrentDmesg:
> [ 18.816154] e100: eth0 NIC Link is Up 100 Mbps Full Duplex
> [ 18.816928] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [ 29.376013] eth0: no IPv6 routers present
> [ 59.736386] uart_close: bad serial port count; tty->count is 1,
> state->count is 0
> Date: Tue Oct 20 23:29:42 2009
> DistroRelease: Ubuntu 9.10
> Lsusb:
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Package: xorg 1:7.4+3ubuntu7
> ProcCmdLine: root=UUID=3492c127-...

2.8.0.901 has no code changes from 2.8.0-2-gb0aa94f, so I'm advancing to the next version after that.
2.8.0.901-1-g154592a has now been uploaded.

The earlier report of a freeze with 2.8.0.901+karmic was either a fluke or due to the fact that it had some patches on top of the upstream 2.8.0.901 (which were carried over from the karmic development upload I copied). From this point forward, these are pure upstream versions, and if someone reports a freeze, I'll see if I can get a second confirmation.

2.8.0.901-1-g154592a boots to desktop 100% and is stable :-)

OK, I've uploaded a plain 2.8.1 build, no additional patches on top of it this time.

2.8.1 is stable since release on both my test machines.

Only these lines in xorg Section "screen" for the Dell Inspiron 1100 notebook, everything else is configured.

SubSection "Display"
             Virtual 1024 768
EndSubSection

No xorg file on the Dell Dimension 2400 desktop.

I have joined using Brian's ppa since the latest upload (also a Dell Inspiron 1100) and also haven't had any crashes since. It seems though that the graphics are sometimes slower, but that's better than the random crashes.

Yes performance is slower but that is something we can work on later in xorg? I was hoping the driver insatiability fix would ultimately improve acceleration.

When this bug is resolved, we'll be able to go back to the new driver with the bugfix added, and things will be fast again as well as stable.

One reason I just realized for why graphics-testing is slower is that by reverting libdrm but not mesa, I broke opengl acceleration. It was just silently falling back to software. This may have also covered up freezing issues caused by mesa, since I was essentially removing mesa from the equation. So now I've uploaded an older mesa version that should work with the reverted libdrm.

You can check whether you're getting software or hardware rendering with the following command:
glxinfo | grep renderer

Which will produce something like this for hardware:
OpenGL renderer string: Mesa DRI Intel(R) 845G GEM 20090712 2009Q2 RC3 x86/MMX/SSE2

Or for software:
OpenGL renderer string: Software Rasterizer

I have an affected i845 system at home now, for testing. Running Bejeweled Twist on it freezes the system, even in Jaunty. But only with hardware acceleration, so there's definitely a mesa freeze bug and it's been there a while.

3D applications can probably freeze the system for most people now that hardware acceleration is re-enabled. But what I'm interested in is whether this affects the stability even when you're not running 3D applications. If so, it may have all along been the breaking of mesa that made the freeze bug go away. And in that case, I need to start looking at pre-Jaunty versions of mesa.

Another Dell 2400 here. Reverted to older drivers (2.4) using this guide (https://wiki.ubuntu.com/ReinhardTartler/X/RevertingIntelDriverTo2.4) for now and subscribed to this bug report.

Ubuntu 9.10, 2.6.31-17-generic

New subscriber. Added Brian's PPA, updated.
Dell Dimension 2400 w/ Intel 82845G/GL[Brookdale-G]GE Integrated Graphics Device (rev 01)
Karmic 2.6.31-18-generic
No Compiz
Had been experiencing numerous freezes at random times and sometimes freezing even logging in. Much frustration and searching brought me here. Will report any future freezes since adding this PPA
Thanks for your good work!

FWIW, I'm seing a random freeze that looks very much like this, but with nvidia hardware on my ASUS laptop - Karmic, 64-bit, all latest patches. Every couple of days, screen just stops responding to mouse clicks and keyboard but mouse cursor still moves; can't find any diagnostic info in logs. Ctrl-Alt-Bksp restart fixes it for another day or two, but crashes all in-flight desktop apps, of course. I've been trying newer kernels [currently 2.6.33-020633rc5-generic]; no joy, just happened again a few minutes ago. When time allows I'll try PPA and report results.

Still stable and loads at 100% to desktops.

OpenGL renderer string: Mesa DRI Intel(R) 845G GEM 20090418 2009Q1 x86/MMX/SSE2

xserver 5:2.8.1+karmic

glxgears won't fill full screen, but no crashes.

New subscriber.

Panasonic CF-W2 Toughbook

4:16am alberto@triton:~>[1]uname -a
Linux triton 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 16:20:31 UTC 2009 i686 GNU/Linux

4:16am alberto@triton:~>[2]lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)

I am using Ubuntu 9.10 Karmic. Since installing, I have had serious freezes, with and w/o compiz, firefox, chrome, etc. etc.

Reverted to older drivers (2.4) using this guide (https://wiki.ubuntu.com/ReinhardTartler/X/RevertingIntelDriverTo2.4). This rendered both the graphical (window) and text interfaces (ttyX) unusable :-(

Had to boot from CD to manually revert back the drivers so I can boot properly.

Added Brian's PPA, updated.

Freezes appear with:
- Compiz enabled/disabled
- KMS enabled/disabled
- When watching video and actively using the laptop, after login when siting idle with nothing but the screensaver running, etc.

3 freezes in the last 4 hours :-(

When checking for hw or sw rendering I got:

4:17am alberto@triton:~>[4]glxinfo | grep renderer
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try adjusting the vblank_mode configuration parameter.
OpenGL renderer string: Mesa DRI Intel(R) 852GM/855GM GEM 20090418 2009Q1 x86/MMX/SSE2

xserver-xorg-video-intel 5:2.8.1+karmic (from Brian)

Hope this helps.

Another Dell 2400 here. Reverted to older drivers (2.4) using this guide (http://ubuntuforums.org/showpost.php...0&postcount=15) for now and subscribed to this bug report.

Ubuntu 9.10, 2.6.31-18-generic
Also occurring in Lucid Alpha2-reverting to 2.4 driver fixed it there too

OK, xserver-xorg-video-intel 2.8.1-1 has now been posted.

Brian,

Are you working on the 845GM mainly or do this work for the 855GM? The previous package did not improve the freezing in my case. I would appreciate your input.

Sorry, just a clarification. When I said the 'previous' I meant xserver-xorg-video-intel 5:2.8.1+karmic, NOT xserver-xorg-video-intel 2.8.1-1 which I haven't tested.

To woodmastersam

Please can you clarify location of instructions for reverting. The link (http://ubuntuforums.org/showpost.php...0&postcount=15) seems ambiguous. Thanks.

Hi

I also get this exact behavior on a Karmic 2.6.31-17 with a Matrox card, MGA G200eW WPCM450.

Any ideas?

Thanks...

Further to my above comment,

It works fine on 2.6.31-14 to 16. The problem start when I upgrade to 17.

So I would think something has changed between 14 and 17?

Thanks

OK, The new xserver-xorg-video-intel 2.8.1-1, crashes at boot 100%.

I disabled Compiz entirely:
sudo chmod a-x /usr/bin/compiz
went back after and reenabled it, and with the 2.4 driver I'm freeze-free.

I Added the following lines to my /etc/apt/sources.list:

deb http://ppa.launchpad.net/siretart/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/siretart/ppa/ubuntu jaunty main

I Imported the appropriate GPG key

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xce90d8983e731f79

I Installed the driver:

sudo apt-get update
sudo apt-get install xserver-xorg-video-intel-2.4

I have only had one freeze since in either Gnome or XFCE and that was caused by a Chromium update that got mangled. I purged and reinstalled the Chromium packages and no problems...

I have just tried with xserver-xorg-video-intel 2.8.1-1, the system crashes on boot, particularly, when gdm login starts.
I have disabled compiz and seems to work. With the driver xserver-xorg-video-intel-2.4 seems there aren't problems, no crashs with this driver. I have tried with ubuntu lucid lynx alpha 2 too and the xserver-xorg-video-intel 2.8.1-1 driver crashs. with or without compiz, I'm working on it.

2.8.1 appeared to totally solve my problems - no freezes since I installed 3 days ago.
Just installed 2.8.1-1 - no freeze on startup - will report any freezes in use.

I found another way to freeze the system. For me, the following command will usually trigger a freeze before it completes:

x11perf -range copywinpix10,comppixwin500 -time 1 -repeat 1

I'd like to find out if that freeze is connected to this one. If it is, then we have a good, reproducible test case. So along with reporting whether a version freezes during regular use, I'm also interested whether the above x11perf command causes freezes. Also, since there are multiple revisions of the i845, it's good to report what version you have with this command:

lspci | grep VGA

Mine looks like this:

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

Yes, "x11perf -range copywinpix10,comppixwin500 -time 1 -repeat 1" will freeze X.

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

shadetree, what version of libdrm, mesa, and xserver-xorg-video-intel is that result for? Did you get 2.8.1-1 to start without crashing? Or did you revert to an earlier version, or to standard Karmic?

I have just run this command twice and it didn't seem to cause any freezes, but it did log me off eventually and I had to log in again--maybe that's how it's supposed to be?

I am not running the latest version of the ppa (2.8.1-1), but the previous one. (I didn't even test it. I wouldn't now how to revert it if it crashes already during start up. So after the first reports on the crashes, I decided not to install it.)

lspci | grep VGA:

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

Oh, THAT was interesting. Not sure what was supposed to be happening. Didn't freeze though the graphic window it opened stayed in the foreground, couldn't move it or bring any other window to foreground, system was still responsive though VERY slow. Graphics got more complex with each cycle - maybe be more helpful to tell what it does.

Eventually it logged me out very quickly, I was able to log back in to a normal session no problem.
Looks like I have the same version as Brian:
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)

Running 2.8.1-1

Sorry,

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

xserver-xorg-video-intel 2.8.1-1
libdrm 2.4.11-2+
mesa 7.4.1-1ubuntu6+

Boots to x now with no usplash or login (DRAM?).

Out of curiosity I tried
x11perf -range copywinpix10,comppixwin500 -time 1 -repeat 1
on my Compaq Laptop which has never experienced any kind of freeze with any version on Ubuntu and got the same behaviour I got in my previous post #88 on the Dimension 2400 which is the machine that was experiencing the freezes (though none on Brian's PPA yet). The graphic test or whatever it is ran for a while in it's own window and then promptly logged me out.
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
xserver-xorg-video-intel 2.9.0-1ubuntu2.1
libdrm 2.4.14-1ubuntu1
mesa ? - not sure which package I'm looking for - 7.6.0 sound right?

Brian Rogers, the command "x11perf -range copywinpix10,comppixwin500 -time 1 -repeat 1" will freeze X, as shadetree as said. But it can freeze X in generally, I have tried on a nvidia as video card and there's also the problem:
02:00.0 VGA compatible controller: nVidia Corporation G72 [GeForce 7500 LE] (rev a1)
I think it's a generally problem of X.

robbielink, yes, it's a X's bug as shadatree and I said.

"x11perf -range copywinpix10,comppixwin500 -time 1 -repeat 1", X sync time output: completes on my other PC's. So let's not inject anything to this report and follows Brian's requests.

The suggested x11perf command completes fine for me, and I don't see any X freezes with:

libdrm2: 2.4.11-2+karmic3
xserver-xorg-video-intel: 2.8.1-1
kernel: 2.6.31-17-generic
mesa: 7.4.1-1ubuntu6+karmic

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

I haven't been testing each version all along - sorry. Also, the above set of versions no longer allows 1280x1024, which I could get under jaunty (and get at some previous point in the testing that I unfortunately don't remember). The highest resolution I can get is 1024x768.

Eager to keep testing.

OK, version 2.8.0-8-g12c5aec is up.

how can I revert to a previous version of the ppa if it turns out to crash (during start up or later)?

There's no automatic way to revert to an earlier version of the PPA as a whole, but you can revert packages individually by manually installing the older .deb files. And since only the -intel package has been updated lately, that's the only one you'll have to revert.

To install a .deb file manually, type
sudo dpkg -i <filename>

The file you want might still be in /var/cache/apt/archives. If not, here is the archive of past versions:
https://launchpad.net/~brian-rogers/+archive/graphics-testing/+packages?field.name_filter=&field.status_filter=&field.series_filter=karmic

It's good to save the files (or copy them out of /var/cache/apt/archives where they might be deleted automatically) ahead of time in case X won't boot with the new version. That way you'll already have the old package and can install it from the recovery console.

Also, to revert the PPA entirely and go back to Karmic, install ppa-purge and run this command:
sudo ppa-purge ppa:brian-rogers/graphics-testing

Brian, thanks for the detailed instructions. I have updated the ppa earlier today and haven't had any freezes (yet), but I'll keep testing.

The suggested x11perf command causes an X crash (not a freeze) and gdm restarts.

libdrm2: 2.4.11-2+karmic3
xserver-xorg-video-intel: 2.8.0-8-g12c5aec
kernel: 2.6.31-17-generic
mesa: 7.4.1-1ubuntu6+karmic

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

This is new behavior on my machine from xserver-xorg-video-intel 2.8.1-1, under which the x11perf command completed successfully. I also, as a test, replaced libdrm2, xserver-xorg-video-intel, and all installed mesa packages with their stock karmic repo versions, and tried the x11perf test. This also resulted in an X crash (not a freeze).

I'm hopeful that others see a change in behavior here.

I also tried the x11perf command, but didn't get any crash. Also, this time I didn't get logged out.

I'm realizing that I may not run compiz but metacity, not sure, I had fiddled with that much earlier when I tried to prevent the freezes. Does that make any difference?

so is 2.8.0-8-g12c5aec a regression from 2.8.1-1 which I've been VERY happily running freeze-free since you put it up?

Apparently there's a generic X memory corruption bug triggered by the x11perf command I gave (I can crash Xephyr with it). When X crashes out rather than freezing, it's because of that. So it turns out this isn't a good test of the driver.

I did witness freezing in some scenarios with this command:
x11perf -range srect10,srect500 -time 1 -repeat 1

And I was not able to observe any memory corruption with the above command, only the freezing. So this is a better test.

Robbielink, no regressions have been reported so far with 2.8.0-8-g12c5aec. There was a report of a crash with the earlier x11perf command, but it turns out that isn't caused by the driver. It's an X bug that randomly may or may not trigger.

Just a note that I rolled back to the karmic repo and tried the "new" x11perf command. It didn't cause a freeze for me after about 6 or 7 tries. Brian did note that it's not going to cause the freeze 100% of the time, but I wanted to reinforce that it's not a one and done check. After leaving the stock karmic repo versions running overnight, X did freeze, which made me glad, because I hadn't just imagined it before!

Still no freezes with the ppa:

libdrm2: 2.4.11-2+karmic3
xserver-xorg-video-intel: 2.8.0-8-g12c5aec
kernel: 2.6.31-17-generic
mesa: 7.4.1-1ubuntu6+karmic

Sorry i haven't been able to give any input on testing lately.

A update to kernel-19 and grub, broke grub on 4 of my PC's, two were testing this driver.

I have been able to fix grub on the single drive machines but the multi drive PC's are bricked.

Hi!
Asus A3N,
freezes, a couple of seconds after login.
kernel: 2.6.31-19-generic
xserver-xorg-video-intel: 2.8.0-8-g12c5aec
libdrm2: 2.4.11-2+karmic3
mesa-utils: 7.4.1-1ubuntu6+karmic

lspci | grep VGA: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)

no freezes on my machine with the latest ppa version so far, also not after the recent kernel update.

with xserver-xorg-video-intel-2.4_2.4.1-1ubuntu11~ppa1_i386.deb (that i downloaded frrom siretart's ppa) it works fine, not freezing.

For anyone on Lucid, I have uploaded a version of Lucid's libdrm to my PPA which has this patch: http://cgit.freedesktop.org/mesa/drm/commit/?id=4f0f871730b76730ca58209181d16725b0c40184 .

This patch is supposed to fix many of the freeze problems that has occurred lately. The PPA is at https://launchpad.net/~gomyhr/+archive/standard .

My freezes were slightly different, but with exactly the same end. It never freezes after power off/on cycle (complete reboot) - but it freezed always after suspend state - the freezes were in interval 2min - 5 hours after wake-up.

Now, I'm trying updated libdrm on Karmic - and no freezes after suspend state so far (now approx. 14 hours of run!!). Never have been so long without freeze! Seems good now.

xserver-xorg-video-intel 2:2.10.0+git20100210.f0d760bf-0ubuntu0sarvatt2~karmic
libdrm2: 2.4.17-0ubuntu2+freezefix~gomyhr1
libdrm-intel1: 2.4.17-0ubuntu2+freezefix~gomyhr1
mesa: 1:7.4.1-1ubuntu6+karmic
kernel: 2.6.33-020633rc7-generic

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

Jan.

Dell Inspiron 1100 laptop with Karmic, I was experiencing freezes reliably every boot after under an hour, mouse moving but no response otherwise. Someone had said they could trigger the freeze with the "kernel modesetting" system test, or with shifting to tty with C-A-Fx, I was not able to trigger it with either of those.

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

Just updated using Brian Rogers' PPA, no freezes now for several hours, it definitely would have frozen by now before.

libdrm2: 1:2.4.11-2+karmic3
libdrm-intel1: 1:2.4.11-2+karmic3
xserver-xorg-video-intel: 7:2.8.0-8-g12c5aec

OK, sounds like this version is good, so I've upgraded graphics-testing to 2.8.0-47-ge903b3e.

This version is stable.

7:2.8.0-47-ge903b3e

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

libdrm2: 1:2.4.11-2+karmic3

Linux 2.6.31-19-generic

Version 2.8.99.901-5-g57fc09c is now available.

To speed things up I'm going to wait less for feedback now. It could take us down a wrong path if a bad version happens to run stably for a while, but we'll backtrack if that happens.

It would help occasional not-very-techie testers like me if someone could
post the summary of how to install the latest 2.8.99 version into Lucid.
Thanks

The package has to be built for Lucid so it can tie into the Lucid versions of its dependencies. Older versions of xserver-xorg-video-intel were failing to build on Lucid, and it looked like it may have taken some work, so I just left that for later when we found a good version that's new enough to build on Lucid without extra work.

I just checked and the current version I have in the PPA is new enough, so I just did a build for Lucid. You can get it by adding my PPA normally on Lucid. Just add this to software sources: ppa:brian-rogers/graphics-testing

OK, I added ppa:brian-rogers/graphics-testing to my sources. In my sources
appeared
*http://ppa.launchpad.net/brian-rogers/graphics-testing/ubuntu lucid *main
I then updated and saw it updating a few different things from brian-rogers.
After restarting my machine, Foxconn R10-S1, which has an Intel Atom with Intel
945GC+ ICH7 chipset, it works fine, including running all three levels of
visual effects.

The display has been working fine since I rolled back the
xserver-xorg-video-intel to version 2.4. How can I double check that it is
using your new version?

Many thanks.

Just search for xserver-xorg-video-intel in synaptic. If you have the Lucid version from my PPA, it will say 7:2.8.99.901-5-g57fc09c+lucid in the "Installed version" column. If you select it and go to the package menu and choose "force version" you will be able to select between available versions.

Have checked, and it is the Lucid version from your PPA. And it's still
working fine with Intel 945GC. Cheers.

No freezes with:

libdrm2: 2.4.11-2+karmic3
xserver-xorg-video-intel: 2.8.99.901-5-g57fc09c
kernel: 2.6.31-19-generic
mesa: 7.4.1-1ubuntu6+karmic

This version is stable.

7:2.8.99.901-12-g2cc1f3c

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

libdrm2: 1:2.4.11-2+karmic3

Linux 2.6.31-19-generic

Acer SK20 here.

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

kernel: Linux version 2.6.31-19-generic (buildd@palmer) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #56-Ubuntu SMP Thu Jan 28 01:26:53 UTC 2010 (Ubuntu 2.6.31-19.56-generic)

libdrm2: 2.4.14-1ubuntu1

xserver-xorg-video-intel:
7:2.8.99.901-12-g2cc1f3c freezes in the customary fashion.
7:2.8.99.901-5-g57fc09c has worked for two and a half hours now, which is a stability record on this box - of course the acid test will come five seconds after posting this report :-)

2.8.99.901-16-g7e7db7a just got done building. If you could verify if that version also freezes, it'd be a good sanity check.

I'm going to upload a version between 2.8.99.901-5-g57fc09c and 2.8.99.901-12-g2cc1f3c now, and it might take an hour or so to build.

2.8.99.901-5-g57fc09c just froze, right as gdebi was about to install 2.8.99.901-16-g7e7db7a :-(

Rebooted, installing 2.8.99.901-16-g7e7db7a now.

2.8.99.901-16-g7e7db7a froze fairly quickly, as expected (playing Klondike, fwiw).
Now trying 2.8.0-47-ge903b3e.

2.8.0-47-ge903b3e froze. Trying 2.8.0-8-g12c5aec.

Hooray! 8:2.8.99.901-8-g4758311+lucid worked on my newly upgraded intel machine. Thanx, Roger!! In some 20 hours of getting nowhere, for the first time, I could see the login window.

No freeze so far with 2.8.0-8-g12c5aec. Have to go now; will leave this machine running and check it again in ~12 hours.

This version is stable:

2.8.99.901-8-g4758311

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

libdrm2: 1:2.4.11-2+karmic3

Linux 2.6.31-19-generic

>2.8.99.901-8-g4758311+lucid worked on my newly upgraded intel machine. Thanx, Roger!!

Sorry, I meant "Brian":)

Based on the reports from Flabdablet, I have backed up a bit to a build between 2.8.0-8-g12c5aec and 2.8.0-47-ge903b3e. 2.8.0-27-g926c7e7 is now uploaded.

After more than 24 hours of stable running on this box, 7:2.8.0-8-g12c5aec froze while attempting to use gdebi to install 7:2.8.0-27-g926c7e7. It also froze once while attempting to launch gedit on another identical box (I'm trying to set up a batch of elderly school computers for cost-recovery resale). One freeze might be a mere Disturbance in the Force, but two is Bug Still Here.

Would like to try 6:2.8.1-1 but too incompetent to find the .deb.

The system deletes old packages after a while, so that one isn't available any more. But now I sent in a build of 2.8.0, which will get built when it works its way through the queue.

You've been having a lot of luck reproducing the hang, which is good, but I want to double-check that you're indeed getting a graphics hang and not something else. When it hangs, can you still move the mouse cursor?

Mouse cursor moves, but clicks are ignored and keyboard is locked up (caps/num lock produce no change in status LEDs, ctrl-alt-Fn doesn't work). Disk activity continues. If a freeze is going to happen, it will most often be right when an app is in the process of opening a new window. I'm using Metacity as desktop effects cannot be enabled (is Intel 845 blacklisted for Compiz? haven't followed this up). Alt-SysRq-R E I S U will cause some disk activity at each keystroke and *very* occasionally produce a black screen but B never reboots; only holding in the power button will do that. Have not yet tried ssh since none of these boxes have openssh-server installed, but can do so if you need further confirmation that this is the same freeze pattern as initially reported.

Hi Flabdablet, Just curious, does your desktop clock change time (update) during your freeze?

I've just installed 11:2.8.0, and if it freezes I will watch the desktop clock for a minute and let you know.

I now have two of these boxes on the same bench, both with 11:2.8.0 installed. The one I'm using to try to get today's work done is running sshd, and the other one is running top on it via ssh. I have pressed Murphy's Law into service to help these boxes freeze if they're going to freeze, by also installing 11:2.8.0 on all the boxes that will be moved out to the shed today for resale to school parents. Will report back if something changes.

Thanks, Murphy. Love your work.

11:2.8.0 froze while using Firefox to compose a Gmail. As usual the mouse cursor remained movable (though stuck in the I-beam shape from the compose window, this time) but no response to clicks or keyboard. The desktop clock didn't update. The top listing on the other computer (in an ssh session to this one) did continue to update. When I quit top and tried "sudo service gdm stop" there was a password prompt, then a ~20 second wait, then a message reading "gdm stop/waiting" but the display on the frozen computer remained frozen. Issuing "sudo reboot" from the ssh session rebooted the frozen computer.

Please, sir, could I have an even older one?

Yeah, that's definitely a GPU hang. 2.7.0 has been uploaded and should build eventually. If you have problems getting this version to run at all, you may have to boot with i915.modeset=0 in your kernel parameters.

These boxes are all booting with nomodeset=1 kernel parameters and 1024x768 forced in xorg.conf anyway, per bug 522488.

12:2.7.0 is a doozy! Freezes in the customary fashion before even making it to the desktop (these boxes are all set to auto-login) on four tries out of five so far, 15 seconds after on the fifth try. Kind of amusing to watch the spinning throbber cursor stop spinning but keep moving with the mouse.

I'm reinstalling 2.8.0 on the 2.7.0 test box. I won't be at the school playing with these for the next few days, unfortunately.

Interesting...if you are not able to even get to X at boot, sounds like dram lost. You could try changing your settings in your BIOS video size up to 8mb if lower, and remove boot splash to give some dram back to start X;-)

We've gone back so far now that we've nearly gone back to the Jaunty version. When you get back to this testing, you may want to do a Jaunty install and see if that suffers from the bug. If it doesn't, we have our good version and it might be easier to step forward from there with newer versions of xserver-xorg-video-intel, rather than start at Karmic and step backward.

It will also avoid potential problems with an old driver and new kernel, etc...

Hmmm... hasn't this been broken ever since the Karmic release (going on 4
months)? If I go out and buy a new video card, will that fix my problem
(now)? Suggestions for someone who can't borrow their mothers's computer
for weeks on end to play around with different driver versions? I hate to
reload Windows or even Jaunty for that matter... my first windows->Ubuntu
convert is not going so well!

Yeah, a new video card will bypass the problem, since you won't be using the i845.

I do hope we continue to test this driver issue.

I too have a Dell 2400 with this onboard chipset driver and have temporary remove the Radeon 9250 PCI card to help with testing.

My Dell 1100 Inspiron note book with a Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03), has no other options but to fix this driver.

Before having seen this bug report, I filed a new bug report here: https://bugs.launchpad.net/ubuntu/+bug/527149
I believe the two bugs are the same bug (except for the video playback problem, which wasn't mentioned here).
I hope that report will give you helpful information.

Thanks to everyone who is working on this issue.

Tal

I too am experiencing this problem. I have several computers with the old Intel chipsets. I've attempted several "work-arounds" suggested in the forums. I registered/subscribed today to help in any way I could. As shadetree stated in comment #47 "There are thousands and thousands of these older chip-set PC's that are moving to linux". I've converted a few myself. I am a very enthusiastic supporter of Ubuntu because as shadetree stated, "8.04 was out of the box working perfect". Ubuntu is suposed to be easy to use. Suggesting that we might consider upgrading hardware in order to accommodate the limitations of the OS is: 1) for many not easy. 2) a practice that drove me to investigate converting to Linux. OK, I'll get off my soapbox and go back to work.

Dell inspiron 1100
kernel 2.6.31-20.57-generic
intel 11:2.8.0 no freezes
2.8.99.901-8-g4758311 was stable for me also.
however booting to working display still requires sometime several cold
boot.

This version is stable:

12:2.7.0, But the GL rendering is not so good.

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

libdrm2: 1:2.4.11-2+karmic3

Linux 2.6.31-19-generic

I have a kernel patch for people to try. It works around the x11perf freeze, and I'm curious if it prevents random freezing as well. Kernels with this patch, for both Karmic and Lucid, are available in a separate PPA of mine, graphics-fixes:

https://launchpad.net/~brian-rogers/+archive/graphics-fixes

When you add this PPA and reload, a new kernel version will be available, linux-image-2.6.31-50-generic for Karmic or linux-image-2.6.32-50-generic for Lucid. It won't be an update to an existing kernel, so you'll have to pick it and install it manually.

Testing will be most interesting without the packages from graphics-testing, so run this command to remove that:
sudo ppa-purge ppa:brian-rogers/graphics-testing

Note that the patch in this new kernel is a workaround and may impair performance in certain specific scenarios. But it will be useful in figuring out whether the random freeze and the x11perf freeze are related.

After noticing in Xorg.0.log that 2.8.0 used UXA by default while 2.7.0 was picking EXA, I added

    Option "AccelMethod" "UXA"

to the "Device" section in xorg.conf and reinstalled 2.7.0. This has fixed the early freeze reported in comment #138. I will be working with this box for the next couple of days, and will report back if it freezes. The other box on the same bench (the one I'm using to ssh into this one when necessary) will continue to run 2.8.0.

Also: after reading comment #147, I tried glxgears on both at the same time and found that the 2.7.0 box is actually reporting a *higher* frame rate: anywhere from 1498 to 2274 frames per 5 seconds with about 2200 being typical, compared to the very consistent 1489-1493 reported by 2.8.0 and all later versions.

2.7.0 just froze in the usual way, while scrolling a remote VNC window with vinaigre.

I hadn't added your ppa to my sources.list.d; I've just been downloading and dpkg --installing xserver-xorg-video-intel .debs. So I've just done

sudo apt-get update
sudo dpkg --force-depends --remove xserver-xorg-video-intel
sudo apt-get install xserver-xorg-video-intel
sudo dpkg --status xserver-xorg-video-intel

to make sure I now have 2:2.9.0-1ubuntu2.1 installed again, and

echo deb http://ppa.launchpad.net/brian-rogers/graphics-fixes/ubuntu karmic main | sudo tee /etc/apt/sources.list.d/brian-rogers.list
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 311bdf2d
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install linux-image-2.6.31-50-generic

and will report back if I get another freeze.

OK, assuming "may impair performance in certain specific scenarios" means the same thing as "makes the entire desktop experience unresponsive enough to be intolerable except for debugging purposes" it appears that your patched kernel is working as intended :-)

Will report freezes if any occur.

If you never added my PPA, does that mean you never downgraded libdrm or mesa? That might be a factor in being able to reproduce the freeze in such old xserver-xorg-video-intel versions.

OK, I see where you specify libdrm 2.4.14-1ubuntu1. You could be getting freezes because of a libdrm bug in the newer version.

Test Configuration: linux-image-2.6.31-50-generic, emachines T3624 [VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)].

Test Scenario: Applications > Games > Robots.

Test Results: Very slow! Blank screen w/ moving mouse cursor after 1 minute. No response to keyboard or mouse buttons.

Test Recovery: Remote login via "ssh", "shutdown -r now", select kernel 2.6.31-19-generic in GRUB menu.

Note: Some stability can be achieved (2-4 hours) w/ 2.6.31-19-generic by setting screen saver to "Blank screen" HOWEVER, my first attempt to enter this info by editing in Firefox. I've observed this before. Second attempt, edited in gedit w/ no problem and then did a cut & paste to Firefox.

OK, I'll test that idea. There did seem to be a stability improvement going from the stock xserver-xorg-video-intel to your 7:2.8.99.901-5-g57fc09c version, so I'll start again with that and the libdrm2 and mesa stuff from your ppa:

$ echo deb http://ppa.launchpad.net/brian-rogers/graphics-testing/ubuntu karmic main | sudo tee -a /etc/apt/sources.list.d/brian-rogers.list
$ sudo apt-get update
$ sudo apt-get install libdrm2 libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa libosmesa6 mesa-utils
$ sudo dpkg --install ~/Downloads/xserver-xorg-video-intel_2.8.99.901-5-g57fc09c_i386.deb

$ dpkg --status libdrm2 | grep Version
Version: 1:2.4.11-2+karmic3
$ dpkg --status libgl1-mesa-dri libgl1-mesa-glx libglu1-mesa libosmesa6 mesa-utils | grep Version | uniq
Version: 1:7.4.1-1ubuntu6+karmic

Rebooted into kernel 2.6.31-19-generic. Will report any freezes.

Got the usual freeze while scrolling a Firefox tab. Now testing:

kernel: 2.6.31-19-generic
libgl1-mesa-dri, libgl1-mesa-glx, libglu1-mesa, libosmesa6, mesa-utils: 1:7.4.1-1ubuntu6+karmic
libdrm2: 1:2.4.11-2+karmic3
xserver-xorg-video-intel: 12:2.7.0

What are the chances of a workaround kernel with slightly less aggressive time delays in it? Your 2.6.31-50-generic really does make this box unpleasantly laggy.

I could lower the delay, but if it froze we wouldn't know if that was because a delay doesn't fix the problem or because the delay was too short.

12:2.7.0 and friends listed above just froze while looking at a Flash-based web site, so I guess we're still looking at a driver issue, not a mesa or libdrm2 one.

I don't have a Jaunty installer disc or any blanks here, but will burn one before coming to work tomorrow if you think running an earlier driver inside Karmic would be too fraught.

In the meantime, I will grit my teeth, knees and elbows and persist with testing linux-image-2.6.31-50-generic with a ppa-purged Karmic.

Hello,

My experience with the "graphics-fixes" PPA was similar to flabdablet's --
unusably slow. In the 10 or so minutes it took to login and start a browser,
I got no actual freezes; just 30-to-60-second response delays for each mouse
click. With everything running at 1/100th usual speed, it might've taken
weeks to decide whether the driver was stable. (it usually takes a few hours
of use) Unfortunately I needed to use the machine so I did a hard reboot &
reverted to regular Karmic.

Details: I used the "graphics-fixes" PPA starting from a regular Karmic, to
which I've reverted:
Intel 82852/855GM Integrated Graphics Device [8086:3582] (rev 02)
libdrm1-intel1 2.4.14-1ubuntu1
xserver-xorg-video-intel 2:2.9.0-1ubuntu2.1
libgl1-mesa-{glx,dri} 7.6.0-1ubuntu4
linux-{image,headers}-2.6.31-19-generic 2.6.31-19.56
        (The unusably slow PPA kernel was
         linux-{image,headers}-2.6.31-50-generic 2.6.31-50.58)

--
John E.

Couldn't bear working with linux-image-2.6.31-50-generic any longer. Now running a fresh Jaunty installation. Will report any freezes.

If there's somebody else whose freeze experience matches mine wrt driver versions in use, it would be good to put your hand up, as I won't have access to these boxes for much longer.

Now running a fresh-from-CD Jaunty with "Option" "AccelMethod" "UXA" added to the Device section in xorg.conf. Brian: if this doesn't freeze today, what's best to do next?

I'm preparing post-Jaunty versions of libdrm and the intel driver, so we can step forward and find the first broken version, hopefully with fewer problems than running these old versions in Karmic.

$ echo deb http://ppa.launchpad.net/brian-rogers/graphics-testing/ubuntu jaunty main | sudo tee -a /etc/apt/sources.list.d/brian-rogers.list
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 311bdf2d
$ sudo apt-get update
$ sudo apt-get install libdrm-dev libdrm-intel1 libdrm-intel1-dbg libdrm-nouveau1 libdrm-nouveau1-dbg libdrm2 libdrm2-dbg xserver-xorg-video-intel xserver-xorg-video-intel-dbg
$ dpkg --status libdrm-dev libdrm-intel1 libdrm-intel1-dbg libdrm-nouveau1 libdrm-nouveau1-dbg libdrm2 libdrm2-dbg xserver-xorg-video-intel xserver-xorg-video-intel-dbg | grep Version | uniq
Version: 2.4.9-2ubuntu3
Version: 2:2.7.0-jaunty1

Rebooted into kernel 2.6.28-11-generic and awaiting freeze.

No freeze so far, but I can't switch to a text console - any attempt gives me a black screen, after which I can't get the GUI back. Keyboard and (presumably) mouse still fully operational - I can successfully log in blind to a text console and issue a reboot command. Doing /etc/init.d/gdm restart via ssh causes processes I know are running in the GUI (e.g. Firefox) to disappear, and the appropriate restart sounds, but the screen stays black.

About to ppa-purge and find out whether this is new behaviour or just Jaunty being itself on this box.

$ sudo ppa-purge ppa:brian-rogers/graphics-testing
$ dpkg --status libdrm-dev libdrm-intel1 libdrm-intel1-dbg libdrm-nouveau1 libdrm-nouveau1-dbg libdrm2 libdrm2-dbg xserver-xorg-video-intel xserver-xorg-video-intel-dbg | grep Version | uniq
Version: 2.4.5-0ubuntu4
Version: 2:2.6.3-0ubuntu9
$ sudo reboot

Correct text console behaviour restored.

OK, I have libdrm 2.4.11 for Jaunty and a rebuild of the Intel driver queued up.

Wow, that was a mess.

Sticking with your graphics testing PPA.

12:2.7.0,

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

libdrm2: 1:2.4.11-2+karmic3,

mesa 1:7.4.1-1ubuntu6+karmic,

Linux 2.6.31-19-generic.

No issues, only performance with this version.

I think the 2.6.32-50 kernel I uploaded for Lucid might perform better. If you want to try it in Karmic, you can get it directly here:
https://launchpad.net/~brian-rogers/+archive/graphics-fixes/+build/1534570/+files/linux-image-2.6.32-50-generic_2.6.32-50.22_i386.deb

Test Configuration:

emachines T3624 [VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)].

xserver-xorg-video-intel: 12:2.7.0,
libdrm2: 1:2.4.11-2+karmic3,
libgl1-mesa-glx: 1:7.4.1-1ubuntu6+karmic,
kernel: 2.6.31-19-generic

Test Scenario:

1a) Applications > Games > Robots: Made rapid moves for approximately 2 minutes w/ no freeze.
1b) System > Preferences > Appearance > Visual Effects > Normal: System searched for driver and appeared to change modes and immediately froze.

ssh, reboot.

2a) Applications > Games > Iagno, Help > Contents > Playing Iagno: Immediate freeze.

ssh, reboot.

3a) Started Firefox, gedit and synaptic and began preparing this summary.
3b) Applications > Games > Iagno: Played for 1-2 minutes - OK.
3c) Finished this summary.

Suggestions?

Configuration: emachines T3624 [VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 03)].
Kernel 2.6.31-20-generic

Status update: Put testing aside for a time pursuant to a stable platform via the following "work-arounds":

1) Created simple xorg.conf to select vesa driver. Acceptable performance with marked stability improvement (i.e., no freezing). Note: Used "Xorg -configure" to generate baseline xorg.conf - Xorg failed to start using this file. After a bit of "cut & paste" all was well.

2) Installed xserver-xorg-video-intel-2.4 per the instructions of ReinhardTartler (https://wiki.ubuntu.com/ReinhardTartler/X/RevertingIntelDriverTo2.4). Screen was improperly sized/positioned during startup. Included Modeline and Option "PreferredMode" in xorg.conf. Startup issues resolved, performance acceptable, no freezing.

3) Installed safe configuration per the instructions of pyske83 (http://ubuntuforums.org/showthread.php?t=1130582). Added device options (including "Tiling" "false") to the xorg.conf file of item 2 above. No startup issues, acceptable performance. Selected GLMatrix screensaver which ran over 12 hours w/ no freezing. System has been running over 18 hours w/ no freezing.

Glxgears performance: glxgears frame update rate was 125-150 fps for all of the work-arounds cited previously. Previously, the glxgears frame update rate was 280-300 fps. Note: psyke83 (see reference) urged caution regarding interpretation of glxgears performance metrics.

Note: During my research I read numerous forum and/or mailing list entries from individuals stating that they had or were about to abandon Ubuntu Linux because of this issue. Clearly, this malfunction should be rectified and hopefully these findings will be helpful to those more informed.

Thanks for your efforts!

$ dpkg --status libdrm-dev libdrm-intel1 libdrm-intel1-dbg libdrm-nouveau1 libdrm-nouveau1-dbg libdrm2 libdrm2-dbg xserver-xorg-video-intel xserver-xorg-video-intel-dbg | grep Version | uniq
Version: 2.4.11-0jaunty2
Version: 2:2.7.0-jaunty2
$ uname -rv
2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009

Boots into GUI OK. Attempting to switch to a text console causes same misbehaviour noted in comment #165.

Now trying your new libdrm with the old driver:

$ dv=2:2.6.3-0ubuntu9; sudo apt-get install xserver-xorg-video-intel=$dv xserver-xorg-video-intel-dbg=$dv
$ dpkg --status libdrm-dev libdrm-intel1 libdrm-intel1-dbg libdrm-nouveau1 libdrm-nouveau1-dbg libdrm2 libdrm2-dbg xserver-xorg-video-intel xserver-xorg-video-intel-dbg | grep Version | uniq
Version: 2.4.11-0jaunty2
Version: 2:2.6.3-0ubuntu9
$ uname -rv
2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009

Text console switching works again.

Just to clarify: I've had text console switching misbehaviour both times I've tried driver version 2:2.7.0-jaunty1. It's not a complete X freeze: the keyboard stays responsive, I can see the monitor turning its backlight off and on as I attempt to switch screens, and the monitor's OSD reports 1024x768 as it should. But the only way I've found to restore a non-black text or GUI screen is to reboot - restarting gdm doesn't do it.

Do you think this is related to the freeze we're chasing? Even if not, given that this misbehaviour is so quickly and reliably triggered, is it worth bisecting for in its own right?

I have a similar issue. After a while X freezes up and nothing works on the graphics part, but behind for instance I can log in into the machine using OpenSSH. I tried disabling the DRM with nomodeset but still the drm, i915 modules are loaded into the kernel (I tried to blacklist them also) and the issue remains. My video controller is VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01) and the lspci output is:

00:00.0 Host bridge: Intel Corporation 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface (rev 01)
00:02.0 VGA compatible controller: Intel Corporation 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 81)
00:1f.0 ISA bridge: Intel Corporation 82801DB/DBL (ICH4/ICH4-L) LPC Interface Bridge (rev 01)
00:1f.1 IDE interface: Intel Corporation 82801DB (ICH4) IDE Controller (rev 01)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01)
05:08.0 Ethernet controller: Intel Corporation 82801DB PRO/100 VE (LOM) Ethernet Controller (rev 81)

and the computer is a HP rp5000 model and the OS is Ubuntu Karmic Koala. Because of this random freeze ups the machine is unusable for work. Is there some workaround that solves this issue? Thank you!

P.S. I read all the comments on this bug and tried most of them except package updates (I'm very conservative about those methods because this is my work machine).

Flabdablet, any console switching issues are most likely separate bugs that have already been fixed in newer versions. Only random freezing during general use is important. Do you see that with my current Jaunty PPA packages?

crazybyte, the best workaround is probably using nomodeset and setting vesa as your video driver in xorg.conf.

Somewhat works if I disable modeset (nomodeset) and use vesa, but it's at the limit of usability, if I try to switch between text mode console and X the graphic screen freezes up and only the text console works (if I switch back). Also because I'm using VESA the screen resolutions are much much lower. Isn't there a fix (as a package or something that can be used to upgrade the system), even if it's unofficial, for Karmic? Thank you!

crazybyte: you might try Geir Ove Myhr's kernel #599; see
Comment #59 at bug
447892<https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/447892/>.
It's stable for me on an Intel 855;
incl. compiz, dual-head, kms, etc.; might work for you too.

It's frozen in time, of course; I'm deferring kernel updates until ...
well, hopefully not too much longer.

On Wed, Mar 10, 2010 at 12:23 PM, crazybyte <email address hidden> wrote:

> Somewhat works if I disable modeset (nomodeset) and use vesa, but it's
> at the limit of usability, if I try to switch between text mode console
> and X the graphic screen freezes up and only the text console works (if
> I switch back). Also because I'm using VESA the screen resolutions are
> much much lower. Isn't there a fix (as a package or something that can
> be used to upgrade the system), even if it's unofficial, for Karmic?
> Thank you!
>
> --
> [i845g] Karmic stops responding a few minutes after log in
> https://bugs.launchpad.net/bugs/456902
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in X.org xf86-video-intel: In Progress
> Status in “xserver-xorg-video-intel” package in Ubuntu: Triaged
>
> Bug description:
> Binary package hint: xorg
>
> After a do-release-upgrade -d from jaunty to karmic beta, I am getting
> "lock ups".
>
> If I don't log in and just leave gdm idling, the machine doesn't freeze.
> If I switch to a virtual console and use that, no freeze. I can ssh in
> just fine and do all kinds of stuff with no lock ups. But once I log in via
> gdm, I can go <strike>about 5-10 minutes</strike> EDIT 22 Oct 2009: anywhere
> from a few minutes to 12 hours or so until the machine:
>
> EDIT 26 Oct 2009: Please see comments for update on how the freezes
> behave!
>
> 1) <strike>stops responding to all mouse/keyboard input</strike> EDIT 2 Oct
> 2009: In all freezes, the keyboard stops responding and mouse clicks do
> nothing. Recent freezes have left the mouse pointer movable, but some of
> the first freezes I saw left the mouse pointer immovable.
> 2) CapsLock will not toggle
> 3) <strike>sshing in doesn't work anymore</strike> EDIT 2 Oct 2009: This
> may not be the case. The freezes occurring over the last couple of days
> have left ssh still operating.
> 4) alt+sysrq+reisub will cause a reboot, and the screen usually blanks
> after the 'i' is put in to send SIGKILL to all processes.
>
> I have the 82845G graphics chipset, and i915 is shown in the output of
> lsmod. As the problem only occurs when I'm in X, and as it doesn't matter
> whether I'm in GNOME or a failsafe xterm session, I suspect the graphics
> driver.
>
> EDIT 22 Oct 2009: I'm working through the X freeze troubleshooting tips at
> https://wiki.ubuntu.com/X/Troubleshooting/Freeze and will provide more
> info as soon as possible.
>
> ProblemType: Bug
> Architecture: i386
> CurrentDmesg:
> [ 18.816154] e100: eth0 NIC Link is Up 100 Mbps Full Duplex
> [ 18.816928] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [ 29.376013] eth0: no IPv6 routers present
> [ 59.736386] uart_close: bad serial port count; tty->count is 1,
> state->count is 0
> Date: Tue Oct 20 2...

Thanks! I will try that. Is this issue present in Lucid? Would upgrading to Lucid solve this issue? Thank you!

crazybyte, did you use Brian's PPA: https://launchpad.net/~brian-rogers/+archive/graphics-testing ?

This version is working on two of my PC's

I haven't yet seen the familiar freeze, but I've also not really had the
opportunity to work with that box for very long at a stretch, so I'm not
prepared to swear it's stable yet.

@shadetree Thanks! It seems that using Brian's PPA solves the issue in my case. Until now I didn't got a freeze and I'm using modeset and fully working X (without vesa driver).

It lloks that the packages from Brian's PPA repository finally solved the freezing issue for me. I'm using modeset and X (without graphical effects) and the machine is running since morning and didn't freeze at all.
@Brian Rogers Thank you for your amazing work and effort in solving this issue. Thank you again! :)

$ dpkg --status libdrm-dev libdrm-intel1 libdrm-intel1-dbg libdrm-nouveau1 libdrm-nouveau1-dbg libdrm2 libdrm2-dbg xserver-xorg-video-intel xserver-xorg-video-intel-dbg | grep Version | uniqowner@owner-desktop:~$ dpkg --status libdrm-dev libdlibdrm-nouveau1 libdrm-nouveau1-dbg libdrm2 libdrm2-dbg xserver-xorg-video-intel xserver-xorg-video-intel-dbg | grep Version | uniq
Version: 2.4.11-0jaunty2
Version: 2:2.7.0-jaunty2
$ uname -rv
2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009

Booted with vga=791 kernel parameter. xorg.conf as attached.

Been using this for quite a few hours now. It seems stable, and text console switching also works; without Driver "intel" in xorg.conf, X chose the vesa driver instead. My previous report about text console badness *does not apply* to the intel driver. I think we're back on track.

That's interesting because those are essentially the same versions that were unstable for you in Karmic. Can you attach /var/log/Xorg.0.log for both Karmic and Jaunty running graphics-testing?

OK, here I am back in Karmic, and just making sure we're all using the same stuff:

$ pkgs='libdrm-dev libdrm-intel1 libdrm-intel1-dbg libdrm-nouveau1 libdrm-nouveau1-dbg libdrm2 libdrm2-dbg xserver-xorg-video-intel xserver-xorg-video-intel-dbg'; sudo apt-get install $pkgs >/dev/null && dpkg --status $pkgs | grep Version | uniq && uname -rv
Version: 1:2.4.11-2+karmic3
Version: 12:2.7.0
2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 01:26:53 UTC 2010

I've attached Xorg.0.log from Jaunty per comment #184 and Karmic per this one. Will run in Karmic until I can verify that it freezes, then report and boot back into Jaunty.

Karmic froze. Now testing Jaunty.

20 hours freeze free - I'm prepared to call it stable.

Can you try Jaunty's kernel on Karmic and Karmic's kernel on Jaunty, to see if the difference in stability is due to the kernel versions?

Now using Karmic with Jaunty's kernel.

$ pkgs='libdrm-dev libdrm-intel1 libdrm-intel1-dbg libdrm-nouveau1 libdrm-nouveau1-dbg libdrm2 libdrm2-dbg xserver-xorg-video-intel xserver-xorg-video-intel-dbg'; dpkg --status $pkgs | grep Version | uniq && uname -rv
Version: 1:2.4.11-2+karmic3
Version: 12:2.7.0
2.6.28-18-generic #60-Ubuntu SMP Fri Mar 12 04:40:52 UTC 2010

Feels quite slow, and I'm only getting about 1/3 the usual fps out of glxgears. The attached Xorg.0.log looks like I'm loading the right driver, though.

Awaiting freezes.

It died, but not exactly the same way: this time, there was a sudden burst of disk activity during which everything went black, then no response to mouse or keyboard. I've attached Xorg.0.log retrieved via ssh before I rebooted; looks like X has crashed and then failed on restart.

Been out of testing for a while - busy and gave up testing with Lucid alpha 3 even more unstable than Lucid 2. Now testing with Lucid beta 1 - stable long enough to do updates via gui.

Have installed Lucid, updated and added ppa:brian-rogers/graphics-testing to sources, using gui. When I update I get complaints about lack of public key. But, because of the number of recent posts, not sure what to do now.

Would be grateful for:

1. confirmation that the latest testing is in ppa:brian-rogers/graphics-testing
2. details of public key and how to install, preferably via gui.

Thank, Mark

Hello Mark, I understand the many posts.....I have been on Brian-rogers/graphics-testing ppa karmic, with descent reliability.

Are you using his lucid or karmic compiled ppa?

Sorry, don't quite understand the question. (I'm not very techie!) I am
using karmic beta testing and have added brian-rogers/graphics-testing to
the sources. Cheers

OK, Brian's PPA: https://launchpad.net/~brian-rogers/+archive/graphics-testing, has a driver just for lucid.

You will need to choose and sub to that PPA.

There are potential fixes for this in the upstream development version. I uploaded it for Lucid to the following PPA:
https://launchpad.net/~brian-rogers/+archive/experimental

I can't simply upload this version for Karmic because it requires new versions of support libraries, but I can backport the important fixes. If someone can verify this version fixes the bug in Lucid, I'll backport the changes and we can get them in Karmic.

OK, at this point, I recommend the xorg-edgers PPA for testing. It now has the newest xserver-xorg-video-intel driver, as well as libdrm and Xorg. Updating just the first part may have caused some stability issues. Does xorg-edgers experience the freezing issue?

Oh, here is the link:
https://launchpad.net/~xorg-edgers/+archive/ppa

I have uploaded xserver-xorg-video-intel with the backported fix for
both Karmic and Lucid to my standard PPA:
https://launchpad.net/~gomyhr/+archive/standard/ . If I didn't make
any mistake in the backporting or building, there should be no
additional problems with this ones compared to the standard Ubuntu
packages, since the fix is the only thing that has changed.

@developers: I'm not too familiar with quilt, so I edited the source
tree directly instead of adding a patch in debian/patches, but for
testing purposes, this should be no problem. The only change from the
commit patch is to change the pixmap to pPixmap and change the
indentation.

$ pkgs='libdrm-dev libdrm-intel1 libdrm-intel1-dbg libdrm-nouveau1 libdrm-nouveau1-dbg libdrm2 libdrm2-dbg xserver-xorg-video-intel xserver-xorg-video-intel-dbg'
$ dpkg --status $pkgs | grep Version | uniq && uname -rv
Version: 2.4.14-1ubuntu1
Version: 2:2.9.0-1ubuntu2.2~gomyhr1~clipsolids~karmic
2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010

Will continue to use this box for general work and report any freezes.

Same old freeze while using remote desktop viewer.

Brian: after the last freeze, I accidentally rebooted into your patched kernel (2.6.31-50-generic) and ran it for a while with the same packages as in comment #200, and it also froze while I was using remote desktop viewer. So it looks like even that kernel's horrible GUI sloth doesn't actually prevent the freeze.

Flabdablet, can you try Lucid + xorg-edgers? The upstream driver has additional bugfixes that may be relevant.

Having trouble getting the box to boot at all with Lucid + xorg-edgers, as xserver-xorg-video-intel requires mode switching enabled in the kernel but leaving nomodeset=1 off the options line makes the machine boot into a video mode that its monitor doesn't support (probably related to bug 522488). Also, I no longer have bench space for that box at work; will bring it home in the next few days and report back once I get it working at all with Lucid.

I have a kernel for people to try in my experimental PPA:
https://launchpad.net/~brian-rogers/+archive/experimental

It contains the gtt chipset flush v7 patch from http://bugs.freedesktop.org/show_bug.cgi?id=27187 on top of linux 2.6.34-rc3. This patch has managed to stabilize the system for some i855 users, but hasn't seen much i845 testing yet.

You'll have to manually install linux-image-2.6.34rc3-51-generic after adding the PPA and reloading.

That experimental kernel (2.6.34-rc3-51.1~karmic) didn't do it for me: my
i855 froze up during login. I was running it with the following packages:
   libdrm 1:2.4.11-2+karmic3
   mesa 1:7.4.1ubuntu6+karmic
   xserver-xorg-video-intel 2:2.9.0-1ubuntu2.2~gomyhr1~clipsolids~karmic
My GPU: Intel 82852/855GM [8086:3582] (rev 02)

Maybe a different set of packages would've worked better with that kernel?

So far the only stable combination I've found is Geir Ove Myhr's (Jan. 2,
2010)
linux-image-2.6.31.1-855gmtest599-git522bb74_gomyhr1_i386 (downloaded from
http://www.kvante.info/855GMfreeze/) running with the standard Karmic
packages:
   libdrm 2.4.14-1ubuntu1
   mesa 7.6.0-1ubuntu4
   xserver-xorg-video-intel 2:2.9.0-1ubuntu2.1