She's a thermal runaway
A while back, Aspyr bought me a 2.5 GHz G5 to replace a loaner G5 that had to go back to Apple. I've been trying to use it as my main development Mac, but I still keep all my personal stuff on my own G4. I don't like the idea of keeping my personal stuff on the G5 since it's not mine.
I have a USB switchbox to move back and forth between the 2 Macs (and my PC), but there's a freaky bug in OSX whereby if I move my mouse or hit the keyboard within 2-3 seconds of switching over, I lose all USB control in OSX and have to restart (it spews out some funky USB message to the console). I had filed a bug with Apple about this a while back, but they gleefully marked it as closed and I haven't been able to make any headway with them on it.
The G5 has been a real boon for Sims2 development, since compile times for the main app are on the order or 20 minutes on that box. I've never bothered to time it on the G4 because it's so long, but it's in excess of 40 minutes. The link time is crazy too - it can be anywhere from 4 to 8 minutes, which makes turnaround in the debugger an absolute killer.
But back to the G5. I've had freaky instances where it would spontaneously go to sleep while I'm doing stuff. At first I checked my screensaver settings and the energy saver settings but no luck. Then I thought perhaps I'm running an app that's attempting to put it to sleep, but that didn't really pan out. After some googling, I discovered what a lot of other G5 owners have experienced - "thermal runaway". It seems that when the CPU temperature hits a certain threshhold in a very short period of time, the system panics and immediately puts the Mac to sleep to cool it down, and it logs an entry into the "system.log" file about a thermal runaway something or other.
Most of the time, I can wake the G5 back up immediately (and of course I have to reconnect to iChat and our VPN as well), but today it went to sleep right as I was preparing to check in some code, and it refused to wake up for more than a few seconds before going back to sleep again. I'll let it sit for a while and hope that I can get it back awake later long enough to complete my check-in.
Unfortunately, it seems like this is an issue that's going to require the Mac to go in for repair, which is going to totally kill me short-term for Sims2 development. I may soon get an opportunity to time the builds on my G4. Anyone want to guess as to how long it'll take to do a full rebuild and link? :-)
Comments
This problem with the G5 makes me sad.
I am using a eMac 1.25Ghz since May when the new ones came out (my first Mac), and up to now (touch wood) haven't had any problems with it. Actually it's been absolutely fantastic.
My study door was always closed to make sure the ugly PC could not be seen from the living room (small house, OK...!?). Now the door is open most of the time - the eMac just looks so cute, and it lets everyone know when the new hour arrives. Sometimes it's the small things...
In any case, I want to upgrade to a G5 next year (KOTOR being one reason for the move), and I sincerely hope I won't be upgrading *and* downgrading at the same time. Hopefully the 2Ghz models don't have the thermal problems. :/
Posted by: Francois de Villiers | November 5, 2004 12:50 PM
We have some G5's here at work that exhibit the same issues. The things seem to think they're over heating, so they either won't boot up, or will try to boot, but the fans will be on full bore the entire time, even if the machine goes to sleep. It's REALLY annoying.
Posted by: vitaflo | November 5, 2004 03:14 PM
No problems so far on my Dual 2.5 except from a rather jealous family, but that's always an occupational hazard. It's so much quieter than the G4 that came before it. I run dnetc on my machine at all times which keeps the CPUs active, but nevertheless the fans do accelerate from time to time with disk or video activity.
I'm half wondering if it's possible to write a hack to mess with the fan speeds by accelerating/decelerating them to a certain rhythm, sort of like a jet engine :)
Posted by: Richard Bannister | November 5, 2004 03:32 PM
I don't think that the USB problem you describe is a general problem; I use a USB switchbox between my Mac and PC (the PC exists only for City of Heroes ), but the mouse and keyboard work on the Mac (which is a 1st gen Dual 2GHz G5) instantly. If there's any delay, it's shorter than the time it takes the DVI display to switch images. I *have* seen some USB console messages from time to time (don't recall any specifics), but no USB device has ever stopped working on me, and I've had those messages since before the KVM.
Posted by: Chris Backas | November 5, 2004 03:48 PM
I take it using Xcode & ZeroLink still isn't a viable option for Aspyr, either? Roll on Xcode 3.0...
Posted by: calum | November 6, 2004 02:38 AM
"Anyone want to guess as to how long it'll take to do a full rebuild and link?"
I'll guess 65 minutes.
Posted by: Eric Jury | November 6, 2004 06:24 AM
Put me down for 55 minutes.
Posted by: Arthur Langereis | November 6, 2004 09:29 AM
Why not use ZeroLink? That should help you turnaround quite a bit.
Posted by: Chris Hanson | November 6, 2004 04:37 PM
"Why not use ZeroLink? That should help you turnaround quite a bit."
I could probably fill another post on that, but the extremely abbreviated version boils down to this: we can't use Xcode (yet) for a variety of different reasons. Even if we could, we require the ability to override standard library functions with our own variants at link time. If we used ZeroLink, our copies would lose out to the system. If there's a way to guarantee that our standard library "overrides" could always win out even when using ZeroLink, that would be handy to know for the day when Xcode is ready for us. :-)
Posted by: Brad Oliver | November 6, 2004 07:33 PM
Is there a reason why you can't:
#define fopen win32_fopen
... etc.? It's worked for me in the past.
Posted by: calum | November 11, 2004 01:38 PM
"s there a reason why you can't:
#define fopen win32_fopen"
That trick doesn't work when using the std::* forms. More problematically, it causes us grief with having to be careful that we're not whacking the standard library headers by accident. because our override routines still call through to the originals rather than exist as a full replacement.
Posted by: Brad Oliver | November 11, 2004 01:51 PM
You might want to take a look at this page:
http://www.macintouch.com/g5reader07.html#jan08
They discuss this problem today.
Posted by: Patrik Montgomery | January 9, 2005 09:04 AM