I'm running Thinkpad X60 (with i945) and compiz.

I also see a "semi-hard lock" (semi, because the mouse still responds, but
nothing else).

After hard reboot, I see this in Xorg.0.log:

(II) intel(0): EDID vendor "MEL", prod id 17217
(II) intel(0): EDID vendor "LEN", prod id 16384
(EE) DoSwapInterval: cx = 0xad539e0, GLX screen = 0xa2afd70
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] mieqEnequeue: out-of-order valuator event; dropping.
<<<<< SNIP.  Last 2 lines repeated at hundreds of times.>>>>>

I do see the following in /var/log/messages (not sure its relevant):
Mar 19 06:42:37 localhost gdm-binary[2449]: DEBUG: GdmManager: NameOwnerChanged:
service_name=':1.408', old_service_name='' new_service_name=':1.408'
Mar 19 06:42:38 localhost gdm-binary[2449]: DEBUG: GdmManager: NameOwnerChanged:
service_name=':1.409', old_service_name='' new_service_name=':1.409'
Mar 19 06:42:38 localhost gconfd (tbl-5428): Resolved address
"xml:readwrite:/home/tbl/.gconf" to a writable configuration source at position 0
Mar 19 06:42:38 localhost gdm-binary[2449]: DEBUG: GdmManager: NameOwnerChanged:
service_name=':1.410', old_service_name='' new_service_name=':1.410'
Mar 19 06:42:38 localhost gdm-binary[2449]: DEBUG: GdmManager: NameOwnerChanged:
service_name=':1.411', old_service_name='' new_service_name=':1.411'
<<<<<SNIP>>>>>
Mar 19 07:54:14 localhost gdm-binary[2449]: DEBUG: GdmManager: NameOwnerChanged:
service_name=':1.1146', old_service_name='' new_service_name=':1.1146'
Mar 19 07:54:14 localhost gdm-binary[2449]: DEBUG: GdmManager: Removing display
for service name: :1.1146
Mar 19 07:54:14 localhost gdm-binary[2449]: DEBUG: GdmManager: NameOwnerChanged:
service_name=':1.1146', old_service_name=':1.1146' new_service_name=''

I would rather see whole thing.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.

Created attachment 298537 [details]
Xorg.0.log when google earth appeared to cause freeze

Sorry I did not attach this to start.

I am running without any xorg.conf file on a Thinkpad X60 with intel 945. Also
running compiz.

Created attachment 298585 [details]
Attached Log File

I also run without an xorg.conf file

Is there any other info I can provide on this? I'm still getting the hardlock of
google earth even after using todays rawhide.

I see the same as Kevin.

Not the same, I'm sure, but running "openuniverse" simulator produces a pretty
useless flickering window that seems to leave artifacts if the window is moved.

No messages in Xorg.0.log, though.....

Using today's updates

kernel-2.6.25-0.185.rc7.git6.fc9.i686
libdrm-2.4.0-0.10.fc9.i386
mesa-demos-7.1-0.21.fc9.i386
mesa-libGL-7.1-0.21.fc9.i386
mesa-libGL-devel-7.1-0.21.fc9.i386
mesa-libGLU-7.1-0.21.fc9.i386
mesa-libGLU-devel-7.1-0.21.fc9.i386
mesa-libOSMesa-7.1-0.21.fc9.i386
xorg-x11-drv-i810-2.2.1-17.fc9.i386


The problem is still repeatable

Previous report of lockup was with Thinkpad X60 (intel 945) running compiz and
with LIBGL_ALWAYS_INDIRECT=1 in my .bash_profile. [So, googleearth would run
with this setting.]

Changing my setup to remove the setting of the environment variable and instead
using the --indirect-rendering option to compiz, I get a different result:

Now, googleearth starts up, but runs very, very slowly, and crashes after a few
clicks. I no longer get system lockup.  System is latest Rawhide:

kernel-2.6.25-0.185.rc7.git6.fc9.i686
libdrm-2.4.0-0.10.fc9.i386
mesa-libOSMesa-7.1-0.21.fc9.i386
mesa-libGL-devel-7.1-0.21.fc9.i386
mesa-libGL-7.1-0.21.fc9.i386
mesa-libGLU-devel-7.1-0.21.fc9.i386
mesa-libGLU-7.1-0.21.fc9.i386
xorg-x11-server-common-1.4.99.901-16.20080401.fc9.i386
xorg-x11-drv-i810-2.2.1-17.fc9.i386

[tbl@localhost Downloads]$ googleearth
Failed to initialize TTM buffer manager.  Falling back to classic.
do_wait: drmWaitVBlank returned -1, IRQs don't seem to be working correctly.
Try running with LIBGL_THROTTLE_REFRESH and LIBL_SYNC_REFRESH unset.
Google Earth has caught signal 11.

Stacktrace from glibc:
  ./googleearth-bin(__gxx_personality_v0+0x1e8) [0x8057fb4]
  ./googleearth-bin [0x8058399]
  [0x110400]
  /lib/libc.so.6(memcpy+0x1c) [0x630b70c]
  /usr/lib/dri/i915_dri.so [0x273d8dc]
  /usr/lib/dri/i915_dri.so [0x273d7c1]
  /usr/lib/dri/i915_dri.so [0x273dad0]
  /usr/lib/dri/i915_dri.so [0x273c3c9]
  /usr/lib/dri/i915_dri.so [0x2746940]
  /usr/lib/dri/i915_dri.so [0x27743c7]
  /usr/lib/dri/i915_dri.so [0x2774440]
  /usr/lib/dri/i915_dri.so [0x27756c7]
  /usr/lib/dri/i915_dri.so [0x2779dca]
  /usr/lib/dri/i915_dri.so [0x28194c8]
  /usr/lib/dri/i915_dri.so [0x2810754]
  /usr/lib/dri/i915_dri.so [0x276bad9]
  /usr/lib/dri/i915_dri.so [0x2810cc5]
  /usr/lib/dri/i915_dri.so [0x2809087]
  ./libIGGfx.so(_ZN3Gap3Gfx18igOglVisualContext11genericDrawEiiiii+0x597)
[0x57ea107]
 
./libIGGfx.so(_ZN3Gap3Gfx18igOglVisualContext12internalDrawENS0_11IG_GFX_DRAWEiiii+0xd7)
[0x5806b57]
  ./libIGGfx.so(_ZN3Gap3Gfx18igOglVisualContext4drawENS0_11IG_GFX_DRAWEii+0x3e)
[0x5806bee]
 
./libIGGfx.so(_ZN3Gap3Gfx15igVisualContext14drawNonIndexedENS0_11IG_GFX_DRAWEii+0x4d)
[0x57c92cd]
 
/home/tbl/google-earth/libevll.so(_ZN5earth4evll14TerrainManager8drawFansEPNS0_6UniTexEPKNS_12BoundingBoxdEf+0x1df)
[0x24ea699]
 
/home/tbl/google-earth/libevll.so(_ZN5earth4evll14TerrainManager16drawTexturedFansERNS0_6UniTexEPKNS_12BoundingBoxdE+0x1f)
[0x24f2e55]
 
/home/tbl/google-earth/libevll.so(_ZN5earth4evll14TerrainManager16drawFansAndTilesEPNS0_6UniTexE+0x55)
[0x24eca49]
 
/home/tbl/google-earth/libevll.so(_ZN5earth4evll14TerrainManager11drawTerrainEPNS0_6UniTexEfii+0x18b)
[0x24ecc11]
 
/home/tbl/google-earth/libevll.so(_ZN5earth4evll12SideDatabase14DrawTerrainAllERKNS0_6ViewerERNS0_12MainDatabaseEi+0x1bc)
[0x2454266]
 
/home/tbl/google-earth/libevll.so(_ZN5earth4evll12MainDatabase11drawTerrainERKNS0_6ViewerE+0x61)
[0x2425b7b]
 
/home/tbl/google-earth/libevll.so(_ZN5earth4evll13VisualContext6renderEb+0x801)
[0x25193ed]
  /home/tbl/google-earth/libevll.so(_ZN5earth4evll13VisualContext4drawEbb+0xa1)
[0x25199e7]
 
/home/tbl/google-earth/libevll.so(_ZN5earth4evll17RenderContextImpl4drawEv+0xa1)
[0x24d3b51]
  ./librender.so(_ZN12RenderWidget10paintEventEP11QPaintEvent+0x24) [0x92d97d0]
  ./librender.so(_ZN5earth6render11RenderTimer4fireEv+0x14) [0x92c660c]
  ./libbase.so(_ZN5earth5Timer10timerEventEP11QTimerEvent+0x31) [0x1539bb]
  ./libqt-mt.so.3(_ZN7QObject5eventEP6QEvent+0x82) [0x1098fc2]
  ./libqt-mt.so.3(_ZN12QApplication14internalNotifyEP7QObjectP6QEvent+0xa1)
[0x102d9a1]
  ./libqt-mt.so.3(_ZN12QApplication6notifyEP7QObjectP6QEvent+0xef) [0x102e4af]
  ./libqt-mt.so.3(_ZN10QEventLoop14activateTimersEv+0x1ed) [0x102143d]
  ./libqt-mt.so.3(_ZN10QEventLoop13processEventsEj+0x57b) [0xfd324b]
  ./libqt-mt.so.3(_ZN10QEventLoop9enterLoopEv+0xa9) [0x10474e9]
  ./libqt-mt.so.3(_ZN10QEventLoop4execEv+0x26) [0x10473e6]
  ./libqt-mt.so.3(_ZN12QApplication4execEv+0x1f) [0x102d39f]
  ./libgoogleearth.so(_ZN5earth6client11Application3runEv+0x24f) [0x710821]
  ./googleearth-bin(main+0x11f) [0x8058817]
  /lib/libc.so.6(__libc_start_main+0xe6) [0x62a95d6]
  ./googleearth-bin(__gxx_personality_v0+0x75) [0x8057e41]




We apologize for the inconvenience, but Google Earth has crashed.
 This is a bug in the program, and should never happen under normal
 circumstances. A bug report and debugging data are now being written
 to this text file:

    /home/tbl/.googleearth/crashlogs/crashlog-0AE8D2C5.txt

This bug report will be sent to Google automatically next time you run
 Google Earth. Its data, which contains no personal information, will help
 us correct problems without bothering you further. If you would rather
 this info not be transmitted, please delete the above file before running
 the program again. If you want bug reports to NEVER be sent, remove the
 above 'crashlogs' directory's read/write permissions.

[tbl@localhost Downloads]$

Found another app that hard locks the machine. Nexuiz, the issue with this one
is a little different in that you can run around a bit, but when you pick up the
plasma gun and then fire it, the machine hard locks. I'm wondering if it is a
transparancy issue or something like that with the G35 card. 

Still unable to capture any debug info, since when the machine locks it locks
hard and no debug information is spit out.

Created attachment 300298 [details]
/var/log/Xorg.0.log when quake3 "crashed" UI

Found another one too: quake3-1.34-0.9.rc4.fc9.i386

Starting this on Thinkpad X60 (intel 945) running latest Rawhide and compiz,
the application starts, but "freezes" the UI pretty quickly.

The system appears to still be running, as rhythmbox is still playing music....


I attach the complete Xorg.0.log, but I get an apparent endless supply of the
following:

[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Is there some way to turn on additional debugging/tracing?

I can play quake3, but I am not running compiz, I'm running metacity with
composite. 

Talked to the intel driver guys and they are saying the EQ overflowing might be
related to the graphic chip locking up. But is a pretty generic error as far as
X goes.

Would be nice if there were some way to extract additional state information
before/during/after this occurs.....

Ideas?

Created attachment 300350 [details]
~/.xsession-errors from frozen UI caused by running quake3

Not sure its useful/interesting, but after locking up the UI running quake3, I
hard rebooted to runlevel 3 and snarfed the .xsession-errors file.  Attached
here.

There are a bunch of 'failed to create drawable' messages; I can create these
at will by clicking to produce a pulldown menu.

I cannot parse the quake3 messages.....

Anyway, we can get a newer snapshot of mesa to test against in Koji. I would
really like to see this problem resolved soon. Since none of my 3d apps (except
q3) work.

Upgraded to the following from koji

glx-utils-7.1-0.22.fc9.i386
mesa-debuginfo-7.1-0.21.fc9.i386
mesa-demos-7.1-0.22.fc9.i386
mesa-libGL-7.1-0.22.fc9.i386
mesa-libGL-devel-7.1-0.22.fc9.i386
mesa-libGLU-7.1-0.22.fc9.i386
mesa-libGLU-devel-7.1-0.22.fc9.i386
mesa-libOSMesa-7.1-0.22.fc9.i386


googleearth still hard locks machine

Attaching Xorg.0.log and xorg.conf

Created attachment 301860 [details]
Xorg log

Created attachment 301861 [details]
xorg.conf

did some bashing away at this today and found that I could get googleearth to
work, but here is what I did

1. deleted $HOME/.googleearth
2. Set 'Option "Tiling" "False"' in xorg.conf
3. upgraded to git master versions of drm, mesa and xf86-drv-intel

After all that I can get googleearth to work

Got nexuiz to work in this config also after setting all graphic options to 'off'
etracer works now, but with tiling off the frame rate drops from 29fps to 17fps,
so it slows the rendering down alot

Not a real fix to any of this, but just some things to show that the Fedora
packages still need some work.

Switching driver to use DRI2 mode also makes crashes and hard locks disappear.
Except for when using SecondLife for Linux

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This problem appears to be fixed in Fedora 11

This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.