Hardy freezes when using compiz

Bug #175744 reported by EzNet
42
Affects Status Importance Assigned to Milestone
Compiz
Fix Released
Unknown
compiz (Ubuntu)
Fix Released
High
compiz packagers
Hardy
Fix Released
High
compiz packagers

Bug Description

I am running alpha 1 of Hardy on a DV6000t (HP, 2 ghz Core2Duo, nVidia GO 7400). Since upgrading to Hardy I have been experiencing problems with the computer 'locking up' or 'freezing' when using the desktop. I believe the problem to relate somehow to Compiz as it does not occur when using Metacity. I have launched compiz from a terminal to attempt to discover any errors that are thrown to no avail. Compiz launches from the gnome console with no problems, and when the system does lock up no errors are displayed. When the lock-up occurs I am forced to hard re-boot (something I hate to do) as I cannot drop to tty1, kill X or soft reboot. The processor fan ramps up when the system freezes, which leads me to believe that there is something 'gobbling' up the processor.
I have posted this in a discussion on ubuntuforums and have had others respond with the same issues. If there is any further information that I can provide, please let me know.

Thanks,
Matt

Revision history for this message
Chris Halse Rogers (raof) wrote :

Thank you for your bug report, and for trying to help make Ubuntu better. However, the bug you see here is almost certainly a duplicate of bug #145112. When this happens you should be able to kill X (and everything else running in X) with the magic sysrq key (Alt+SysRq+k). Furthermore, the system log should have errors like "NVRM: Xid" in it.

Can you confirm this? You can browse the system logs with System->Administration->System Logs - kern.log should contain the Xid errors.

Changed in compiz:
assignee: nobody → raof
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Emil Soleyman (emilsoleyman) wrote :

I am experiencing the same exact problem except that I have Hardy running on a Lenovo Thinkpad Z61t with Intel 945GM. When Compiz locks up, I cannot use the keyboard to kill X or drop to a tty and my only recourse is to ssh into my machine and kill the Compiz process. Once that happens, everything goes back to normal and I can use the machine again without resorting to a hard reboot.

Please let me know how I can debug this situation further.

Revision history for this message
EzNet (zeroezezero) wrote :

Thanks Chris,
I have checked my kern.log as you instructed and I have the following line in there twice for yesterday, though it is not present for todays logs and it has locked up today:

"NVRM: Xid (0001:00): 13, 0000 01013900 00000039 00000328 00000000 00000080"

I also noticed that the architecture at bug #145112 is AMD and I am running an Intel Core2Duo - I do not know how significant this difference is, but there you have it :)
I have attempted to kill X with the alt+sysreq+k without success. ctrl+alt+backspace also does nothing as is the case with ctrl+alt+del. Also, when the freeze occurs I cannot do anything... I have discussed the issue with others who can drop to tty, but I cannot... I have even tried just sitting here pressing the key combinations multiple times over a 5 minute span with no lock.... just an ever faster fan.

Thanks again, despite any issues, I LOVE UBUNTU - even if I cannot use compiz!!!!

Revision history for this message
Emil Soleyman (emilsoleyman) wrote :

I forgot to add that the freezing that I experience is most always caused by a fullscreen window of epiphany or firefox running in both the foreground and background. I notice that if I change desktops away from or towards the browser window there is always some sort of tearing of the screen involved and performance in the browsers decreases significantly.

Revision history for this message
Gediminas Paulauskas (menesis) wrote :

It freezes for me too, although I have a Radeon graphics.
I don't think it happens randomly, but when I try to switch windows by clicking on a window button in window list of gnome-panel. The previous task remains pressed, the new one is pressed too, but what I think is a keyboard grab makes desktop unusable because only the mouse moves, the keyboard does not work except for Alt+SysRq keys. Could not find any errors in logs. Switching to other windows using Alt+Tab works without problem.

Revision history for this message
mtvoid (mtvoid) wrote :

I can confirm this bug too. Trying to switch to a window by clicking on it in the window list plugin causes the display to freeze (not always, but often enough that I'm now wary of using the window list to switch and use Alt-Tab exclusively). The mouse moves, but the X display is frozen and unresponsive otherwise. The other instance when the system hangs like this is at times when I click on a visible window title bar to select and bring it to the foreground. This seems to happen more often if that window is a fullscreen window.
After a freeze, I have to use the Alt-SysRq+K to kill the X server, and after I login back again, running top shows a compiz.real process hogging all the CPU time, and I have to kill it.
I don't see any message added to syslog when a freeze occurs. I have an Intel 945GM graphics chipset.

Revision history for this message
EzNet (zeroezezero) wrote :

145I am still having occasional hangs, but they have definitely reduced in frequency since the most recent rounds of updates... I don't quite know the process that lead me to this point or what upgrades were responsible for it... Yesterday, after updating, every time I logged on my CPU would shoot to 100% - compiz crunching away... I would have to kill it and use metacity. When I would start it up in a console it would jack up to 100% again and keep throwing an error about 'core' plugin already being loaded... I loaded the gnome-compiz-preferences and enabled desktop effects in there and now things SEEM to be working... odd thing is, every time I load gnome-compiz-preferences it gives me an error about not being able to load the settings - type mismatch error... I need to find the location of the config file for that frontend as I am sure it is damaged (or not, who knows.... I have exams I have to take before I get to that :) )... Also, there doesn't seem to be any recent activity in Bug #145112...

Revision history for this message
Sami Haahtinen (ressu) wrote :

I'm attaching a backtrace of compiz while it was hung. I wasn't able to find any debugging symbols so it might not be too helpful.

Revision history for this message
B. Clausius (barcc) wrote :

I can confirm this bug too. Compiz freezes randomly, but i found a way to enforce the freeze:
(1) open gnome-terminal
(2) $gedit &
(3) ALT-TAB back to terminal
(4) $gedit &
At this point the freeze occurs, but not yet completely.
The display freeze, but keyboard is reacts normal, as i see in gedit after i killed compiz.real. I can also Ctrl-Alt-Fn and see there that compiz.real is running with cpu 99%.
I can move the mouse and the pointer changes (normal-pointer, text-pointer, sizing-pointer, ...), but
(5) Mouse-Click
And now freeze is complete. I can move the mouse pointer, but it does not change.
Alt-SysRq+K is the only way to kill the X server and after login i have compiz.real two times and after killing the one running at 99% everything is normal (until next freeze)

Attachment is (gdb) bt after step (4)

Revision history for this message
Sami Haahtinen (ressu) wrote : Re: [Bug 175744] Re: Hardy freezes when using compiz

On Tue, 2007-12-18 at 00:26 +0000, barcc wrote:
> (3) ALT-TAB back to terminal

This would appear to be the key, it would appear that the problem always
appears after using the application switcher (alt-Tab). Also the problem
appears to present itself more often if you quickly (press-release)
switch from one application to another.

- S

--
Sami Haahtinen <email address hidden>

Revision history for this message
Henrik Nilsen Omma (henrik) wrote :

I'm raising the importance of this to High because the hard freeze during desktop use will often lead to data loss. Targeting for Hardy.

Changed in compiz:
importance: Medium → High
assignee: raof → compiz
Changed in compiz:
status: Unknown → New
Revision history for this message
David Prieto (frandavid100-gmail) wrote :

Subscribing because I'm suffering this bug too.

Changed in compiz:
status: New → In Progress
Revision history for this message
Sarah Kowalik (hobbsee-deactivatedaccount) wrote :

This bug is fixed for me. Thanks a lot! I suspect the others are other bugs in compiz, which are similar. I now am only getting the hardlocks while unlocking screens - we're making progress here!

Changed in compiz:
status: In Progress → Fix Released
Revision history for this message
B. Clausius (barcc) wrote :

This bug is fixed for me too. Thanks!

Changed in compiz:
status: Incomplete → Fix Released
Revision history for this message
Tommaso R. Donnarumma (tawmas) wrote :

Since about one week, I've got very similar symptoms as those described in this bug report, i.e.:
- X freezes (no mouse, no keyboard, no SysReq)
- X uses up 100% processor
- I can ssh into my machine, anyway killing compiz or attempting to kill X does no good for me
- Xorg.0.log is full of these messages (they keep adding as I try to move the mouse pointer or type on the keyboard):

tossed event which came in late
mieqEnequeue: out-of-order valuator event; dropping.

I'm not totally sure this is a bug with Compiz, or at least it got worse after the last xserver-xorg-core update. In fact, the lock happens so soon now that I cannot reach for the appearence preferences to disable Compiz and see if it goes away, so I'm basically stuck...

I don't know what to do to help track the problem, but if someone can tell me what they need I can gather data, run tests, etc.

I'm asking that this bug be reopened.

Revision history for this message
Travis Watkins (amaranth) wrote :

Please file a different bug report.

Revision history for this message
Tommaso R. Donnarumma (tawmas) wrote :

Done. Anybody interested please see bug #184430.

Revision history for this message
Thom Pischke (thom-pischke) wrote :

I'm experiencing the symptoms of this bug right now on a fully-updated intrepid. Entered detailed info in bug 161000, including log files with errors similar to, but not identical to those in this bug report.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.