[G45] X freezes about 1-5 min after switching compiz on

Hi vyzivus,

Please attach the output of `lspci -vvnn`, and attach your /var/log/Xorg.0.log (and maybe Xorg.0.log.old) file from after reproducing this issue. If you've made any customizations to your /etc/X11/xorg.conf please attach that as well.

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

Hi Bryce, thanks for your reply. Here's the Xorg log:

lspci -vvnn

I added only a small change to xorg.conf but attaching anyway

I am having the exact problem on my Macbook in Jaunty too (GMA950). My backtrace on AMD64 is at http://paste.ubuntu.com/131446/ and is more or less identical to what you're seeing.

Both of you are missing the symbols for the drm calls - you need to install the libdrm package since it seems the crash is occurring inside that.

I have libdrm-intel1-dbg, libdrm2-dbg, xserver-xorg-core-dbg and xserver-xorg-video-intel-dbg installed however the backtrace is the same as in the original report. In the meantime the intel driver was upgraded to 2.6.3-0ubuntu1. Which dbg packages should I install?

Hmm, those packages should have done it. Well, not much more we can do to analyze it in ubuntu, guess this one should go upstream. Did you find the issue exists still on 2.6.3-0ubuntu1?

Yes, the bug is present in 2.6.3-0ubuntu1 as well, with the same backtrace (at least it seems so).

Wondering what the conditions of the crash are; if they're similar to mine, my bug #345119 would be a duplicate of this. Good to know, since it's being triaged.

My laptop has an Intel GMA X3100 (also known as the GM965). When it crashes, all on-screen action stops; however, my mouse (both Synaptics Touchpad and USB Mouse) continue to move around, just with nothing happening. I can't get to a virtual terminal, but I can reboot using the REISUB trick.

I can confirm, either way, that mine is a Compiz issue as well; I'm running from a Jaunty LiveUSB right now with Compiz disabled as soon as I logged in. Works just fine, using for over an hour long. Works just like - if not better than - my current Intrepid install.

In any case, I hope a fix is released soon.

My system behaves exactly like you described: everything besides Xorg seems to work - disk LED blinks, mouse moves. This is not a kernel panic, it's just that Xorg keyboard does not work, nor does the SysRq+R. The only keys that works are the SysRq magic keys. An ordinary Xorg freeze :-)

I am also having the same problem but I am using kubuntu, no compiz only kwin desktop effects. But for me freeze occured with and with out kwin desktop effects.

Gah, Jithin's right. I just the same freeze without Compiz enabled on a full Jaunty install. Martin, it's up to you to change the title of this bug, or I'll mark mine as non-duplicate.

Please reopen your bug zwaldowski . As this is not the bug we are facing.
 It just freezed 3 times on a row for me on log in . With no desktop effects on kubuntu.

You're right. It seems that compiz triggers this bug reliably. However, my system froze even without Compiz: while watching a video on xv, the freeze even occured during a normal work with Compiz disabled/no video watching.

My system froze when I was browsing this bug report. These freezing seems to be appearing very randomly now. Today it froze when I logged in ( 3 times in a row). Then now when I was browsing, which I was doing for past 2 hours. My applications running are kopete, eclipse, firefox korganizer, kate, dolphin and konqueror.

And during some freezes my laptop power button can shut down the system though no other keys works. But in some cases that also won't work, i have to use sys rq key combination or do a power cut off. I knew beta releases are going to be buggy, but never thought this buggy. Kubuntu Intrepid when in beta time was very stable than this.

having the same problem on an Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller, getting the same lockup conditions where everything is frozen except for the mouse which can't click on anything......I have also noticed that once I have enabled emerald that sometimes it will look like it is locking up, but will let me click on the minimize maximize and close buttons on the corner of a window which will enable me to control it again (this isn't a fix since I have experienced one incident when this did not work, but I thought it might prove useful to others.......This is NOT the entire os locking up as I have the openssh-server running and can ssh in, and everything appears to be running normally, other than the fact that the xserver isn't responding. I agree that this bug is extremely serious to be happening at this stage (beta) of the development compared to my experience with the past three betas, I have never experienced a bug that completely rendered my installation useless

Just posted this to zwaldowski's bug.

For me it's random, actions in all sorts of different applications seem to have triggered it.
- using kubuntu (KDE 4.2) but I think I even had this problem in 3.5...
- The mouse cursor still tracks the mouse.
- Mouse clicks and keyboard input are ignored, requests to change VT are ignored.
- The system itself is still up and running and I can log in remotely via ssh to get things shut down from a full shell. On one occasion this was during a kernel compile and I let that run for another 15 mins AFTER the console freeze, and sure enough it finished correctly.
- Nothing on the display updates, even though there is still clearly activity. eg amarok continues to play until the end of the current track, but amarok's time display stops updating.
- A system shutdown will pause and not close the box down, because it is unable to kill X - I have to intervene with a kill -9. Once I have killed X and stopped the kdm service manually a "poweroff" will work correctly.
- Sometimes a distorted version of the kubuntu shutdown screen appears, sometimes it doesn't.
- If you attempt to restart kdm after killing a dead X, a new X process will run but doesn't appear on the screen. You will also see "[drm:i915_gem_entervt_ioctl] *ERROR* Reenabling wedged hardware, good luck" in syslog.

I am on a MSI Wind / Advent 4211.

00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)
        Subsystem: Micro-Star International Co., Ltd. Device 0110
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at dfe80000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at d0f0 [size=8]
        Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at dff00000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: <access denied>
        Kernel modules: intelfb

Well, I guess my bug *is* a duplicate, then. I'll mark it in a couple of minutes; I'd rather just leave it up to get somebody to notice it (grumbles)...

This one is triaged already :-)

I can confirm

[drm:i915_gem_idle] *ERROR* hardware wedged

appears when I kill -9 the X process remotely to get out of the freeze. It does NOT appear until prompted by the kill.

It does NOT appear during subsequent X restart attempt by kdm (which fails repeatably), it's definitely at the time I kill the old server, not a few seconds later when the new one is spawned. Once it's broke, it's broke. :-)

I think we may have to send this upstream, found a couple of bugs in other distros that look very similar.

Yeah, I've seen this in Fedora (Beta) and Arch Linux, too; it just might be upstream. Xorg Crack Pushers (the PPA repository with bleeding-edge Xorg) also has this problem.

If any of you haven't gone back to Intrepid yet (I know I have, gone back that is), please try updating to today's xserver-xorg-video-intel package. A user on the Ubuntu Forums says that they've now been using their computer for over an hour without problems but, then again, so have I right before it freezes.

I, being a stubborn bastard refused to go back to intrepid, and my persistence may be vindicated by todays xserver-xorg-video-intel update. I can confirm that I too have been up and running for most of today without a single lock up (at least since early this morning before I updated). For most of the day I have been "walking on eggshells" so to speak, trying not to overload the xserver, but for the past few hours I have been testing its limits ( even testing out UXA ), and I haven't had a problem. In fact I am pretty sure that the lockups that a lot people testing UXA have been experiencing were due to whatever the hell this xorg bug was. I am unable to say whether its fixed for sure seeing as throughout this entire dreadful ordeal I haven't been able to find one error that was thrown from the X lockups. However I have my compiz effects settings dialed up too my liking, firefox along wit my preferred plugins is up an running fine, and I haven't crashed once yet. Will post again if this changes but for now it seems to be fixed......thanks to whoever fixed this :-)

Due to differences in hardware, symptoms, steps to reproduce, and so on, I'm not convinced everyone is seeing exactly the same bug. Symptoms for different freeze bugs are often indistinguishable.

So, I'm going to undupe zwaldowski's bug; it should be handled as a separate bug.

I also want to isolate the "freeze after activating compiz" from freezes after other activities. Given that they're appearing on the same hardware, yes it could be the same underlying bug, but the differences in reproducing the error just muddies the water. And it would not be at all unusual to have two or more freeze bugs on the same hardware. So I think it will be easier to handle each of the freeze scenarios as a different bug. If nothing else, it gives us test cases to check when we do think we have a solution.

I will update this bug to focus only on one freeze scenario, on one specific intel chip. Other scenarios and other hardware need new bugs filed on them.

Interesting. I, too, cannot reproduce the bug anymore. It seems that upgrading to xserver-xorg-video-intel 2.6.3-0ubuntu9 resolves this bug. xserver-xorg is 7.4~5ubuntu18. Compiz is stable for an hour now. Going to test more, will post results later.

But I had a freeze yesterday night. I have these same packages. Though I use kubuntu and do not have desktop effects enabled. Any way number of freezes have decreased I had just 3 yesterday :)
And even with desktop effects on they appear just randomly not in 1-5 mins

On Fri, Apr 10, 2009 at 12:15:21AM -0000, Jithin Emmanuel wrote:
> But I had a freeze yesterday night. I have these same packages. Though I use kubuntu and do not have desktop effects enabled. Any way number of freezes have decreased I had just 3 yesterday :)
> And even with desktop effects on they appear just randomly not in 1-5 mins

From my vantage looking at all the different freeze bug reports, there
are definitely multiple freeze bugs out there. I can also easily
imagine that individuals are experiencing multiple ones. Since freezes
are hard to tell apart, one typically assumes all the freezes are being
caused by the same bug, but that's not necessarily true.

So, I could easily imagine that one bug gets solved, so one person sees
the issue completely go away, while another person who had that bug plus
another freezer, merely sees the freezes reduce in frequency.

That said, the change to #345796 was to fix a crash bug when entering
DPMS, not a freeze situation. I suppose possibly fixing that also
resolved secondary issues, but I've seen too many cases where a freeze
seemingly went on vacation for a day or so, but then came back with full
fury.

Anyway, Jithin since your experience is differing from the original
reporter, if you want your issue analyzed as well you should report your
bug separately.

Created a new bug report
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/359392
Please look into

I ran on Compiz six hours without a single crash, I even watched video on Compiz without a crash. From my perspective I consider the bug fixed. Thank you all, guys!

I didnt have this problem for like 2 days but when it came back it happened in 2 quite succession, am happy that the status of this bug has been set to high which means the ubuntu devs are taking it seriously. just want to state that testing the system for just 6 hours is no way to determine if a bug is fixed

agreed, I was going good for a few days and am now plagued again, I see that there is a compiz update that blacklists my video card (gm965), Jithin I see that the changelog on the update refrences your bug report, and it would seem that this is my bug, so I will check out your report......also, I saw this blog that is a how to for installing the bleeding edge xorg drivers, and installing the 2.6.29 kernel as a means to improve intel video cards performance in jaunty, was just wondering if anyone had tried this route and if so whether it thwarts this bug, here is the blog: http://www.ubuntu-inside.me/2009/04/how-to-boost-your-intel-cards.html

We have a PPA with some new tools for debugging X freezes:

  https://launchpad.net/~ubuntu-x-swat/+archive/x-freeze-test

I know how irritating X freezes can be. They're also typically
quite hard to debug, but the information provided by these new
tools should help upstream figure them out.

You can help by doing the following:

 A. Install the PPA packages on Jaunty and boot kernel 2.6.30-rc2
 B. Reproduce your freeze
 C. ssh into the machine and run the steps to collect the info
 D. Attach the tarball of the results to this bug report

With this information, we'll be able to forward your bug upstream.

(For more information on triaging X freeze bugs, see
 https://wiki.ubuntu.com/X/Troubleshooting/Freeze )

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.