Monday, March 26, 2007

SLED 10 and Google Earth commingle, cause desktop to crash

I was running Google Earth 4 on SLED 10 this morning when I decided to go and 'visit' Denver, Colorado. You can see the screenshot of it below, taken right before the desktop crashed and kicked me back out to the login screen.

Before I get into the gory details of the crash, let me describe what happened up to that point. I'd navigated to Denver and oriented the view as you see above. I had 3D buildings enabled. I noticed that it took 15 minutes for the view to completey render, which was far, far longer than another other city I've been to via Google Earth. While it was rendering is was chewing processor time up like nobodies business (according to the Gnome system monitor). Moving from screen to screen was sluggish, so much so that when flipping to Google Earth's screen it froze for a number of seconds in mid-turn, before showing full on. This, on a machine running SLED for X86_64 using an Athlon FX-55 with 4GB of memory. It has never taken this long to render any view, and it still doesn't, as long as I stay away from Denver. What's interesting about Denver is that the 3D buildings being rendered are very high quality and very high detail, far more so than any other city I've viewed to date. I'm sure that played into the very long render time and the subsequent crash.

After Google Earth was finished (Streaming posted 100%), I took the screen shot you see above. Then I attempted to zoom in and re-orient the view to take a closer look at the Qwest building. That's the tall round, brown building near the lower right edge of the screen shot.

Here's Denver again, but this time I've moved in and around for a better look at the Qwest building. This is using Google Earth 4 on Windows XP (the Gateway M685 notebook). The detail is gorgeous, and by the way it looks every bit as good on Linux. The problem is that looking at Denver with Google Earth on Linux causes performance and stability problems.

Here's the setup on the Linux system:
  • Boxx system using Athlon 64 FX-55, with 4GB of ram, nVidia Quadro FX 540.
  • the nVidia drivers are installed, the monitor ia a Samsung SyncMaster 740B at 1280 x 1024.
  • SLED 10, X8674.
  • Compiz desktop manager enabled and running.
When I attempted to zoom in on the Qwest building, the desktop crashed. I was kicked off the desktop and back out to the login screen. When I logged back in, the compositing desktop features were disabled. I couldn't figure out why at first, but a clue was that the desktop would not fit completely in the monitor's screen. When I checked the screen resolution I discovered the screen's resolution has been kicked to 1400 x 1050. That broke Compiz (it looks like Compiz won't handle the odd screen resolution). So I put the resolution back and rebooted first the desktop, then eventually the entire box. I'm back to working on the desktop.

I guess I should be thankful that unlike Windows I didn't get a BSOD. But crashing the X desktop is no less acceptable, especially when the resolution is seemingly screwed up. And considering that this is an Enterprise release (that's what the 'E' in SLED stands for) I have very little tolerance for loosing my work this way. I had all four screens filled with something running (NetBeans 6 on one screen, Protege 3.3 on a second, and Google Earth 4 on a third, not to mention Firefox and terminals...). I can live with applications crashing, but not an application crashing and taking a major part of my OS with it along with all my work. No, the machine did not lock up. Yes, I lost all my work up to that point. A crash of this magnitude is as bad as a Windows BSOD. I had the same loss of time and productivity. I am not amused.

I'd be curious to hear what Suse folks have to say about this.

No comments:

Post a Comment

All comments are checked. Comment SPAM will be blocked and deleted.

Note: Only a member of this blog may post a comment.