[i845g] Display freezes (except for mouse pointer) without warning

[Daniel Richard G.]

Binary package hint: xserver-xorg-video-intel

This bug report concerns xserver-xorg-video-intel 2:2.9.0-1ubuntu2 on Karmic. It was originally reported as a comment to bug #469820, and is probably a duplicate thereof, but at the request of Geir Ove Myhr I have filed it as a separate report.

Occasionally encountered on a Dell OptiPlex GX260: a display freeze in which the screen image and mouse pointer become fixed (unchanging), and while the pointer can be moved around, clicking has no visible effect. The keyboard is similarly unresponsive to any keystroke, save for Alt-SysRq-*.

# 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 01)

A batchbuffer dump tarball is available at http://launchpadlibrarian.net/35735638/dri_debug-20091115.tgz .

[Geir Ove Myhr (gomyhr)]

This bug is very unlikely to be the same as bug 469820, since they occour on very different chipsets. You have 845G and the other bug is for GM45. Please also upload /var/log/Xorg.0.log, and the outputs of `lspci -vvnn` and `dmesg` as separate attachments to this report.

[Bryce Harrington (bryce)]

Hi skunk,

Thanks for including the attached files. Could you also include your /var/log/Xorg.0.log (or Xorg.0.log.old) from after reproducing the issue?

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Daniel Richard G. (skunk)]

Geir, please examine the tarball; Xorg.0.log and dmesg(1) output are in there.

Attaching the output of "lspci -vvnn". (This command would be good to add to the script on the "Troubleshooting X freezes" wiki page.)

[Daniel Richard G. (skunk)]

Let me know if there is anything more you need.

[Daniel Richard G. (skunk)]

Another batchbuffer dump tarball from the same system. This one has "lspci -vvnn" in the bundle.

[pjw (pjw1965)]

I've got the same bug on the same chipset.
Am I right, that your system also useses the i915 driver (and not i845G)? Then the title of the bug is wrong and should be changed.

[Daniel Richard G. (skunk)]

It seems to use i915, but then, the [i845G] tag was assigned by Geir, whom I presume has more in-depth knowledge of the hardware and driver.

[Geir Ove Myhr (gomyhr)]

> I've got the same bug on the same chipset.
> Am I right, that your system also useses the i915 driver (and not i845G)? Then the title of the bug is wrong and should be changed.

The tag and title refers to chipset, not driver. You can find the
chipset you are using with `lscpi -vvnn` or by looking for Chipset in
Xorg.0.log. There are different names for the different drivers. The
2D driver used to be called i810, but is currently called intel. Then
there is the i915 kernel module, i915 and i965 mesa 3D drivers, etc.
Bugs often only occur on only one chipset even though the same driver
is used (currently there are many reports of freezes with 845G and
855GM, but not many on 865G, 915G and 945G, for example, even though
they use the same driver).

[Daniel Richard G. (skunk)]

Another batchbuffer dump. Is this enough to go on, or the more the merrier?

[Geir Ove Myhr (gomyhr)]

> Geir, please examine the tarball; Xorg.0.log and dmesg(1) output are in
> there.

Daniel, we prefer to have those files attached as separate files to
each bug report, since that makes triaging much more efficient. I'm
attaching the files from the .tgz linked to in the description here.

> Another batchbuffer dump. Is this enough to go on, or the more the
> merrier?

I'm not sure, but I think the more the merrier, since I think there is
usually a mix of relevant and irrelevant data in the dump and more
dumps makes it easier to filter out the relevant part. That being
said, I haven't heard a lot back from upstream about the dumps we have
sent there, and I don't know how to read them myself.

Albert Damen has proposed a way to improve the usefulness of the
batchbuffer dumps in bug 447892, comment 23. That requires the very
newest driver from the xorg-edgers PPA,
https://launchpad.net/~xorg-edgers/+archive/ppa .

Meanwhile, Brian Rogers have made some interesting findings at a
similar bug, http://bugs.freedesktop.org/show_bug.cgi?id=24825 . It
looks like downgrading the kernel should work, but he hasn't found the
commit that triggers the freeze yet. You could check if you can
reproduce his findings using the mainline kernels (i.e that 2.6.30
does not freeze while 2.6.31-rc3 freezes). That may indicate that
you're having the same problem. See
https://wiki.ubuntu.com/KernelTeam/MainlineBuilds for more information
about the mainline builds. (Downgrading the kernel cannot be done
while running xorg-edgers, since xorg-edgers requires a recent kernel)

[Geir Ove Myhr (gomyhr)]

Sorry, the files didn't make it the first time...

[Daniel Richard G. (skunk)]

Okay, some updates.

I wrote a cron script for this system that would automatically record a batchbuffer dump and reboot if and when a GPU crash was detected. This worked well... a little too well. The crash was now occurring before GDM could even auto-login the user, and once I got thirteen dumps in a little over an hour (all attached here in a single tarball), I figured I may as well go with xorg-edgers---because it couldn't possibly be any worse than this.

So the system has been apt-get-upgraded with the xorg-edgers PPA, and 'Option "DebugFlushCaches" "1"' in /etc/X11/xorg.conf, and everything is running smoothly so far. I'll report back here if and when it starts acting up.

[Daniel Richard G. (skunk)]

The system has been running with the xorg-edgers PPA drivers for a few days. So far, none of the same GPU hangs have been encountered. However, I'm now seeing intermittent crashes during use of the system, e.g.

Backtrace:
0: /usr/bin/X(xorg_backtrace+0x3b) [0x8133dbb]
1: /usr/bin/X(xf86SigHandler+0x55) [0x80c1395]
2: [0x3c8400]
3: /usr/lib/xorg/modules/drivers//intel_drv.so [0x2fb574]
4: /usr/bin/X [0x8181800]
5: /usr/bin/X(ProcPutImage+0x159) [0x808a4c9]
6: /usr/bin/X(Dispatch+0x35f) [0x808d1af]
7: /usr/bin/X(main+0x395) [0x8072515]
8: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0x3dfb56]
9: /usr/bin/X [0x80719c1]
Saw signal 7. Server aborting.

(from /var/log/Xorg.0.log.old)

which I've reported at

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

Can we have a discussion on how things got to this point in the first place? Why did Karmic ship with such a fatally flawed Intel driver? Who made the decision that this code was suitable for a stable release?

[Geir Ove Myhr (gomyhr)]

That was a little bit too quick, Pedro. The bug you marked as upstream was an unrelated one. I don't see how to remove the upstream report, so I move it to one which is at least related.

[Geir Ove Myhr (gomyhr)]

> Can we have a discussion on how things got to this point in the first
> place? Why did Karmic ship with such a fatally flawed Intel driver? Who
> made the decision that this code was suitable for a stable release?

I don't think such a discussion would be very fruitful [*]. What could
indeed be a fruitful discussion would be one about how to avoid
shipping an LTS in April with the same stability problems. Such a
discussion should take place on the ubuntu-x mailing list
(https://lists.ubuntu.com/mailman/listinfo/Ubuntu-x) and not on a bug
report.

I'm not an expert on xorg, but it seems that the batchbuffer dumps we
have sent upstream so far has not triggered any response. From
https://bugs.freedesktop.org/show_bug.cgi?id=24825 it seems that what
will be needed is that somebody affected by these problems get their
hands dirty and do some git-bisecting in order to find where the
problems were introduced. Brian Rogers has already started on that bug
report, but has only come as far as finding that the problem does not
occur with kernel 2.6.30, but is there in 2.6.31-rc1 - irrespective of
intel driver version. A first step would be to make sure that this is
also the case here, and then try to identify the commit that triggers
the freeze. My impression is that this would give the upstream
developers something to work on.

[*] Here is my impression in case you find it enlightening: First, I
don't agree that the intel driver has become flawed recently. It has
improved a lot over the recent iterations (we had some freeze bugs
like this on i9xx that are now gone). The problem seems to be one
introduced in the kernel (maybe a change there triggered a
long-existing bug in the driver). Second, there seems to have been
very few people testing Ubuntu development releases on i8xx chipsets.
There was a call for testing on the ubuntu-x mailing list back in
April, with some - but not overwhelming - response. Bug reports for
freezes on 845G and 855GM only started ticking in late October, see
[1] and [2] for lists. At this time, we were already in final freeze,
and since these bugs are hard to fix, it was at the time unrealistic
to get it fixed before the release. I think that it was only well
after the release that it became clear that a lot of people had this
problem.

[1]: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs?field.searchtext=&orderby=-datecreated&field.tag=845g+freeze&field.tags_combinator=ALL
[2]: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs?field.searchtext=&orderby=-datecreated&field.tag=855gm+freeze&field.tags_combinator=ALL

[Daniel Richard G. (skunk)]

(Sorry for not following up sooner; I am currently travelling and my Internet access has been sporadic.)

Geir, my concern is that the Intel hardware on which these freezes have been occurring is quite common, and that reflects very poorly on the development side of things. It's one thing if this were on old 3dfx Voodoo boards, or NVidia boards with the Nouveau driver, but Intel?

It wouldn't be so bad if there were some sort of straightforward fallback that could be used. I saw something somewhere about downgrading the Intel driver to version 2.4 (IIRC), that this makes some problems go away. But this required the use of a PPA, gave no assurance that it would address any specific problem, and otherwise was not connected to the Intel driver developers in any way (i.e. no one who actually knows what's going on with the Intel driver was saying anything like "if the latest stuff is giving you headaches, this is the last known-good version, and we recommend you use that until we shake out the bugs.")

It's bad enough that no one (yet) knows what's going on with this bug, but the worse part is that no one foresaw that this sort of problem might arise, and so no workarounds went into the release (nor -updates, nor -backports as of yet). So we're left in a situation where the latest Ubuntu release is unusable for people with some very common Intel video hardware, unless you're willing to run experimental PPA packages with Git pull dates in the version strings. I.e. the worst possible outcome for everyone involved.

I can accept that this bug was triggered by a kernel change, and so may have flown under everyone's radar until late in the game. But the lack of any good options for disabling the troublesome cutting-edge functionality, or reverting to an older version of the driver that is known to work, or anything else that a mostly-newbie can do to get the system back into a usable state, is inexcusable. I can't believe that Canonical would have no better response than "Wait till Lucid, it might just possibly run on your stock Dell system without freezing."

[Geir Ove Myhr (gomyhr)]

Daniel, I agree that this looks bad and is very annoying for those
that have the affected chipsets. I don't have have the affected
chipsets, so I can't do anything else than guiding the bug reporters
in what to report.

I think one problem with this bug is that none of those that are
affected are very experienced linux users and therefore able to
troubleshoot on their own. What I think is needed is someone bisecting
the kernel and or the intel driver to find the commit(s) that
triggered this. Hopefully, that will give the upstream developers an
idea of what might be wrong. Unfortunately, we haven't seen any
upstream activity on the 845G and 855GM freeze bugs that we have
reported so far.

To me this sound like a serious problem that both Canonical and Intel
(and Mandriva, etc.) should have high on their priority list. It
doesn't look like it is the case, though.

> I can't believe that
> Canonical would have no better response than "Wait till Lucid, it might
> just possibly run on your stock Dell system without freezing."

Have you seen this response anywhere? So far I haven't seen any
response from Canonical at all on this problem. Indeed, I would expect
that unless a linux user does some more investigation to get this bug
fixed, it will still be present in Lucid. Sad but true.

[Geir Ove Myhr (gomyhr)]

I have compiled three test kernels for finding the triggering commit that introduced these freezes on 845G into ubuntu. They can be downloaded from http://www.kvante.info/845Gfreeze/ . There is some more detailed information in the comments to bug 456902. If this bug is the same as bug 456902, the kernels with freezetest1 and freezetest8 should not cause the freeze, while the one with freezetest9 should cause a freeze. If this is not the case for you, we know that your bug is different from bug 456902 and we will have to do some additional tests.

I originally compiled the kernels on Jaunty, but tests by others seems to indicate that the tests can also be done in Karmic or Lucid. A problem with Karmic and Lucid is that the default kernel will cause a freeze while it doesn't in Jaunty.

[Daniel Richard G. (skunk)]

Hi Geir, hope you had a good holiday!

> To me this sound like a serious problem that both Canonical and
> Intel (and Mandriva, etc.) should have high on their priority
> list. It doesn't look like it is the case, though.

That's what frustrates me about this bug. Given how common Intel onboard video is, especially in business-class systems, you'd expect the driver for it to be particularly stable---and if there's a problem with it, that it would get fixed quickly. If there were a kernel-panic bug in the Intel NIC driver, how quickly would that get addressed?

> Have you seen this response anywhere? So far I haven't seen any
> response from Canonical at all on this problem.

My point was, it's the lack of a response that says as much. Whether or not this bug is fixed on Lucid shouldn't depend on some random Linux guru taking the initiative. Ubuntu is their product; where are they on this?

Anyway, for now, are the three freezetestN kernels still in need of testing, or should I move on to the drivers in Brian Rogers' PPA? (Presumably with the latest mainline kernel?)

[Geir Ove Myhr (gomyhr)]

> Anyway, for now, are the three freezetestN kernels still in need of
> testing, or should I move on to the drivers in Brian Rogers' PPA?
> (Presumably with the latest mainline kernel?)

The kernels themselves do not need any more testing. We know now that
the change from freezetst8 to freezetest9 triggers the freezes for a
lot of people. You may still want to test them, since if you _don't_
see this behaviour, you are experiencing a different underlying bug
from most other people, and we will have to make sure to treat it like
that.

You may follow Brian Rogers' PPA (not sure with which kernel, but at
least Karmic or newer), but there seems to be plenty of people
following that already. Once they narrow it down to a commit, there
should be two versions ready for testing (similar to the kernels
freezetest8 and freezetest9).

While Brian is homing in on the bad commit in libdrm or
xserver-xorg-video-intel, i have somewhat switched strategy and now
report any freeze bugs upstream once we have a batchbuffer dump from
Lucid with xorg-edgers and a new mainline kernel. That way upstream
will have several bug reports with the newest versions of the driver
stack. It seems that it is somewhat random if a batchbuffer dump is
able to catch the problematic code, so this should have some value
beyond making the problem more visible.

[fcolcord (fcolcord)]

This has happened to me as well. Installing 9.10 onto Dell Optiplex GX260. LiveCD was fine. Installation went fine. Boot up after installation hung on blank screen. Googled for instructions, removed compiz, still didn't boot properly. Had to boot with F3. Then everything looks ok. But recently screen froze. This is the only bug report which has the term optiplex GX260, so I'm filing it here. I enclose

desktop:~$ 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 01)

thanks for all your efforts to make old hardware usable.
Frank