Found the true negative qualm about integrated graphics...

[miniConvert]

I still use the same Windows-esque idea that you shouldn't touch the computer while it's burning a cd, encoding, etc...

I'm with you. It may sound unreasonable by todays standards, but if any of my machines are burning, or even ripping, I leave them be.

 

[7on]

Even if your IIG is the reason, it not fair to say now IIG are crap because of one bug. Because if thats so the whole screen of my iMac is crap(when really it has only one dead pixel)

Welcome to the wonderful world of Rev A hardware

I didn't say IIG were crap. I said I found a negative qualm about them. The stuck pixel argument is a poor relation because the stuck pixel is a common known computer fallacy.

This is really not a Rev A hardware fault. If the MagSafe poweradapter or closing mechanism malfunctioned then yeah, that'd be a problem. The problem lies in Apple's software and I'm not too worried about it. I just wanted to post to see if others had encountered the same mishap.

Where did I say IIG were crap graphics cards?

 

[SC68Cal]

If this was truely a problem with integrated graphics, I think that this error needs to be replicated repeatedly to demonstrate. Otherwise, it could be absolutely anything, including Act of God scenario.

 

[Maxiseller]

Love you too.

*Laughs*

Thats brilliant stuff...my coffee is now in a small pool on my desk!

 

[7on]

If this was truely a problem with integrated graphics, I think that this error needs to be replicated repeatedly to demonstrate. Otherwise, it could be absolutely anything, including Act of God scenario.

yeah, I agree. Though it could be random like 1 in 7200 attempts yields this result. Like I mentioned, the System 1 had a bug where copying and pasting crashed the system. Something about the clipboard taking over kernel/system memory. However the only way to reproduce the bug was if you copied an odd numbered amount of bytes. All internal testing had no bugs but moments before a public demo the bug was discovered and had to be quickly silenced.

I'm not saying the exact same senerio has happened - just something akin to it. Like the original Romeo and Juliet play relates to the Leonardo Dicaprio movie version.

 

[thejadedmonkey]

"Maybe, but with only system RAM, wouldn't the RAM- and processor-intensive rendering process run into problems when the system tried to preempt RAM for video?"

I should not, the OS should take care of that. That's why it has protected memory. Unless of course some nasty Widget does illegal things addressing memory.

Edit: now I notice these big Quote buttons

Me: Quick everyone, let's all point and laugh and say "n00b" with me!
All: n00b!

Yay!

I do believe this thread is disentigrating the more it gets read..

 

[purelithium]

*Laughs*

Thats brilliant stuff...my coffee is now in a small pool on my desk!

At least it's not on your keyboard!

 

[realityisterror]

Geez... some of you guys are really blowing this out of proportion...

His computer borked, and the shared RAM may or may not have been the issue.

No one knows for sure, and all of us can only guess.
Just to make that clear...
kk

 

[combatcolin]

I still use the same Windows-esque idea that you shouldn't touch the computer while it's burning a cd, encoding, etc...

Me too!

 

[Krevnik]

My guess is that when you clicked on the widget, you had to open dashboard, a RAM hungry app. (especially for video). Dashboard tried to preempt a whole bunch of RAM and iDVD couldn't give it up fast enough, causing iDVD to crash, but without releasing its RAM back to the system. So all of a sudden you were using a Mac with like 0 MB of RAM available and everytime some new app tried to do anything, it ran into a brick wall.

The problem with being an armchair engineer is that an actual one might notice when you are wrong.

What you describe isn't even close to the real memory model in OS X. Each app has their own, isolated, 2GB memory space (even if you don't have 2GB of RAM). An app doesn't "give it up" for another app, nor is any one app aware of any other app's memory (unless you explicitly share memory between the two apps). The kernel itself decides what parts of what apps are actually in RAM, and which parts aren't.

What is more likely to cause a cascading failure like this is that the kernel or some other core component gets into a bad state... the Window Server comes to mind in this case. All drawing calls go through this Window Server application, and if it mis-behaves, and can very likely crash other apps with a GUI, even though the kernel/etc is still rock solid. The description here is definitely makes me think of Window Server as the culprit. It is a user-land app, and can't take down the system on its own (unless it causes a failure in the kernel), but it can sure cause the experience the OP is reporting. I haven't had Dashboard trigger it, but I /have/ made the UI completely unusable, and can still login remotely using SSH, and run command-line applications that way.

Maybe, but with only system RAM, wouldn't the RAM- and processor-intensive rendering process run into problems when the system tried to preempt RAM for video?

See above.

 

[gloss]

Geez... some of you guys are really blowing this out of proportion...

His computer borked, and the shared RAM may or may not have been the issue.

No one knows for sure, and all of us can only guess.
Just to make that clear...
kk

Borked.

Hee hee hee.

 

[Abstract]

.....there is not way to know if the problen is due to sharing video and system RAM is if the problen is the cosmic ray event. More information would be required to determine which.

No no, you have as much proof as 7on, so you are obviously both right.

No one knows for sure, and all of us can only guess.

No no, that makes too much sense. 7on is right. He said so.

 

[idea_hamster]

The problem with being an armchair engineer is that an actual one might notice when you are wrong.

What you describe isn't even close to the real memory model in OS X. Each app has their own, isolated, 2GB memory space (even if you don't have 2GB of RAM). An app doesn't "give it up" for another app, nor is any one app aware of any other app's memory (unless you explicitly share memory between the two apps). The kernel itself decides what parts of what apps are actually in RAM, and which parts aren't.

What is more likely to cause a cascading failure like this is that the kernel or some other core component gets into a bad state... the Window Server comes to mind in this case. All drawing calls go through this Window Server application, and if it mis-behaves, and can very likely crash other apps with a GUI, even though the kernel/etc is still rock solid. The description here is definitely makes me think of Window Server as the culprit. It is a user-land app, and can't take down the system on its own (unless it causes a failure in the kernel), but it can sure cause the experience the OP is reporting. I haven't had Dashboard trigger it, but I /have/ made the UI completely unusable, and can still login remotely using SSH, and run command-line applications that way.

Thanks -- very interesting.

But then what is the difference between the way OS 9 (and prior species) dealt with memory (i.e., that whole allocation thing) and the way OSX does (i.e., what I've heard referred to as "preemptive" memory allocation)?

 

[Josias]

Name one.

Lacking amout of RAM. Do you realize how much iDVD rendering a DVD eats? In any case more than 1 gig. This would also have happend with X1300. You eat up all the system memory, and you crash by opening the widget. The IIG is not fed enough memory, and that is why you lacked the graphics in the reboot window.

just my 40% of a nickel.