Bug 438017 - google earth hardlocks machine
google earth hardlocks machine
Product: Fedora
Classification: Fedora
Component: mesa (Show other bugs)
i386 Linux
low Severity low
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-18 14:09 EDT by Kevin DeKorte
Modified: 2018-04-11 04:51 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 13:34:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Xorg.0.log when google earth appeared to cause freeze (96.76 KB, text/plain)
2008-03-19 12:33 EDT, Tom London
no flags Details
Attached Log File (29.38 KB, text/plain)
2008-03-19 16:23 EDT, Kevin DeKorte
no flags Details
/var/log/Xorg.0.log when quake3 "crashed" UI (122.99 KB, text/plain)
2008-04-03 14:13 EDT, Tom London
no flags Details
~/.xsession-errors from frozen UI caused by running quake3 (19.83 KB, text/plain)
2008-04-03 17:53 EDT, Tom London
no flags Details
Xorg log (29.53 KB, text/plain)
2008-04-09 14:00 EDT, Kevin DeKorte
no flags Details
xorg.conf (595 bytes, text/plain)
2008-04-09 14:01 EDT, Kevin DeKorte
no flags Details

  None (edit)
Description Kevin DeKorte 2008-03-18 14:09:36 EDT
Description of problem:
Running google earth will hard lock a G35 based machine

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:
1. Install drivers
2. Start google earth
Actual results:
Machine hard locks, even ssh unaccessible

Expected results:
Google Earth should work

Additional info:

Appeared to work fine about 2 weeks prior to bug report, I don't run google
earth all the time
Comment 1 Tom London 2008-03-19 11:08:55 EDT
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'
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=''

Comment 2 Matěj Cepl 2008-03-19 12:21:38 EDT
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.
Comment 3 Tom London 2008-03-19 12:33:23 EDT
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.
Comment 4 Kevin DeKorte 2008-03-19 16:23:38 EDT
Created attachment 298585 [details]
Attached Log File
Comment 5 Kevin DeKorte 2008-03-19 16:24:32 EDT
I also run without an xorg.conf file
Comment 6 Kevin DeKorte 2008-03-26 10:14:04 EDT
Is there any other info I can provide on this? I'm still getting the hardlock of
google earth even after using todays rawhide.
Comment 7 Tom London 2008-03-26 10:54:31 EDT
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.....
Comment 8 Kevin DeKorte 2008-04-02 09:05:30 EDT
Using today's updates


The problem is still repeatable
Comment 9 Tom London 2008-04-02 14:20:47 EDT
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:


[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.
Google Earth has caught signal 11.

Stacktrace from glibc:
  ./googleearth-bin(__gxx_personality_v0+0x1e8) [0x8057fb4]
  ./googleearth-bin [0x8058399]
  /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]
  ./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(_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:


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]$
Comment 10 Kevin DeKorte 2008-04-03 12:40:25 EDT
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.
Comment 11 Tom London 2008-04-03 14:13:23 EDT
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

[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?
Comment 12 Kevin DeKorte 2008-04-03 16:59:31 EDT
I can play quake3, but I am not running compiz, I'm running metacity with

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.
Comment 13 Tom London 2008-04-03 17:19:54 EDT
Would be nice if there were some way to extract additional state information
before/during/after this occurs.....

Comment 14 Tom London 2008-04-03 17:53:33 EDT
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

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.....
Comment 15 Kevin DeKorte 2008-04-08 11:17:43 EDT
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.
Comment 16 Kevin DeKorte 2008-04-09 14:00:08 EDT
Upgraded to the following from koji


googleearth still hard locks machine

Attaching Xorg.0.log and xorg.conf
Comment 17 Kevin DeKorte 2008-04-09 14:00:42 EDT
Created attachment 301860 [details]
Xorg log
Comment 18 Kevin DeKorte 2008-04-09 14:01:00 EDT
Created attachment 301861 [details]
Comment 19 Kevin DeKorte 2008-04-10 15:07:02 EDT
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.
Comment 20 Kevin DeKorte 2008-04-16 12:38:59 EDT
Switching driver to use DRI2 mode also makes crashes and hard locks disappear.
Except for when using SecondLife for Linux
Comment 21 Bug Zapper 2008-05-14 02:41:41 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 22 Kevin DeKorte 2009-05-25 10:18:10 EDT
This problem appears to be fixed in Fedora 11
Comment 23 Bug Zapper 2009-06-09 19:47:48 EDT
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: 
Comment 24 Bug Zapper 2009-07-14 13:34:38 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.