seems apple has a new test suite since I was last in (Q3/Q4 last year) because the genius ran the test utility in front of me this time and when it failed agreed to replace it free ("special program" he said) even though it's a mid-2010.

This does NOT seem to me like a hardware problem at all. Not memory, not logic board, not graphic card. This is a SOFTWARE issue that Apple needs to fix. It's not because of 3rd-party extensions either. There are threads ALL OVER the interwebz about Mac users getting KPs ever since upgrading to Mountain Lion. And in this thread alone there are instances of people who downgraded their OS to a previous version and the KPs *STOP*.

Plus, how many ppl in this thread alone have gone to the Apple Genius bar and had some sort of hardware "fixed"... only to have it KP again.

The evidence seems way-too-strong pointing towards an issue SPECIFICALLY with Mountain Lion - and in the current (and recent) update builds. "Graphics" is one of the places they are having devs focus on testing. I am hoping the next release will solve both the KP issue and the "monitors rearranging on restart" issue.

What doesn't seem like a hardware problem to you? Using unspec'ed RAM? Bad NVIDIA cards on the mid-2010 model? Anf, of course, kernel panics can be caused by third-party kexts. I haven't seen any kernel panics that are directly related to Mountain Lion - where is your evidence?

I'm not saying non-spec' RAM, bad video cards or 3rd-party extensions CAN'T cause KP's... they absolutely can. But just the name of this thread ALONE should be the first bit of evidence. "Constant KPs on Mountail Lion".

There are too many claims in THIS thread and others online that EXPLICITY MENTION that they never had KP's on their machine until upgrading to Mountain Lion. Myself included. My machine had *NEVER* experienced a KP in the 4 years (and numerous OS upgrades) leading-up to Mountain Lion. Within 5 minutes of updating to M.L. I had my first KP on this machine,

My machine is 100% Apple built with Apple-offered cards, RAM & drives. I have had more KPs since Mountail Lion's install than I've ever had on all my computers combined. I can go 2-3 days without one... or some days I've had 10-12 of them. It's unpredictable.

It's also way too coincidental that *MY* hardware failed the exact moment I upgraded to M.L. - as well as the NUMEROUS others in this thread (and other threads).

Reading how many people have downgraded and successfully stopped the KPs means that the OS version is absolutely a variable in this equation... as well as the fact that it STARTS with everyone here since upgrading. I find it odd that you do not consider the OS to possibly be at fault. How can anyone *NOT* consider the OS a potential culprit...? It would seem to be ignoring the obvious. And to rule-out the obvious just for the sake exploring other possibilities seems short-sighted.

That's all I'm saying. It's walking like a duck... it's quacking like a duck...

I have run the hardware test on MY machine and there are no reported issues.

I have been a Mac/Apple user since 1993 and I have enough experience with troubleshooting to know when the obvious is also the probability. Could I be wrong? Yup! You bet. But I just don't think I am.

MOST - if not all - of the kernel panics in this thread are hardware or software related, if you bother to read them. They have nothing at all to do with Mountain Lion - excpect that it's in the thread header.

If you're experiencing kernel panics, post a panic report. I would bet that we could find out the problem... and it won't be 'just' Mountain Lion.

So... in your opinion, it is not possible that Mountain Lion is a potential cause of many users' Kernel Panics?

I'm not trying to prove *YOU* wong personally.

I'm saying there's enough evidence - most of which I've already spelled-out - that leads me to believe that there is an explicit issue with Mountain Lion causing KPs for users of machines that do not have hardware issues and never had KP issues before. Apple, themselves, are putting focus on "graphics" as one of the handful of areas of focus for the next release - and there have been rumblings (rumors are not fact, I know) that a good portion of this is to deal with the numerous KP & Grfx issues encountered by many users after the MntnLion upgrade.

If you choose to live more by-the-book and see the trees and not the whole forest, there's nothing wrong with that. Decyphering panic reports is an absolutely valid approach to dealing with individuals one-by-one... but when you take a few steps back and see the larger patterns that emerge and the commonalities... I just can't help but point towards M.L. - again... if I'm worng... then I'm wrong. But this just looks far too much like a bug they need to squash in an upcoming release.

There's enough room on the web for us to differ in analysis of what's been said - and we may both be right - there may be an issue with ML that gets solved - AND - people had issues with hardware and/or kexts. I'm just not ready yet to let Apple off the hook for this.

I think it's most likely that it's a combination of Mountain Lion AND some hardware issues. Remember, there are many different faults being reported by users, it's not all the same problem.

It's true that KPs seem to have mushroomed following the release of ML, and my own problem only started after I upgraded to ML. In my case it does appear that there's a known issue with ML (or something to do with multiple displays running through the Thunderbolt ports anyway) that Apple is expecting to fix in a future update. However, from what I've read on here and elsewhere I suspect that ML also reveals hardware issues that were already there, but which were not evident prior to upgrading to ML.

I guess you could call that a problem with ML, but you can't deny that if it wasn't for the hardware fault being there, it wouldn't be a problem at all, and Apple have acknowledged some hardware faults that they're fixing on request. If it really was just the software at fault, I'm sure they wouldn't be wasting money replacing hardware unnecessarily!

So... in your opinion, it is not possible that Mountain Lion is a potential cause of many users' Kernel Panics?

You are both right and wrong.

ML uses more hardware-offload of tasks that was bound to CPU in previos versions of OS. It is good thing as it makes any appropriate computer to run faster and to be more responsive and so on. All Apple core technologies like OpenCL, GCD and so on pushes software to use merged power of underlying hardware. This is really cool and revolutionary.

But from dark side of things - hardware is pushed harder. It is NOT pushed off limits, but it is pushed close to limits. And if you had hidden fault in hardware that newer showed itself under lighter load - now it shows up.

It is smarter for Apple to replace faulty computers than stop their core architectural progress. Furthermore, most oses also went this way, AMD, nVidia and Intel right now are implementing this paradigm in hardware (in slightly different ways) - so it is a way of progress.

I mean this will NOT be fixed somehow in future releases - it is plain impossible. (IMHO)

6.3. Page faults

When a process does something the memory-management unit doesn't like, a page fault interrupt is thrown. Situations that can cause this are (not complete):

Reading from or writing to an area of memory that is not mapped (page entry/table's 'present' flag is not set)

The process is in user-mode and tries to write to a read-only page.

The process is in user-mode and tries to access a kernel-only page.

The page table entry is corrupted - the reserved bits have been overwritten.

The page fault interrupt is number 14, and looking at chapter 3 we can see that this throws an error code. This error code gives us quite a bit of information about what happened.

Bit 0 If set, the fault was not because the page wasn't present. If unset, the page wasn't present.Bit 1 If set, the operation that caused the fault was a write, else it was a read.Bit 2 If set, the processor was running in user-mode when it was interrupted. Else, it was running in kernel-mode.Bit 3 If set, the fault was caused by reserved bits being overwritten.Bit 4 If set, the fault occurred during an instruction fetch.

The processor also gives us another piece of information - the address that caused the fault. This is located in the CR2 register. Beware that if your page fault hander itself causes another page fault exception this register will be overwritten - so save it early!

so with error code 0x0000000000000000 we have all registers unset and - as so - interpretation:

something from kernel mode (driver, e.g. kext ?) tried to read data at linear address 0x000000010c7c0000, but that memory page was NOT present.

I'd say that problem is not with RAM but with HD read timeout (or kext bug). Just my thought.

Meanwhile I found a time-consuming but reliable way to reproduce (my) KP:

Start Safari and start any stream on twitch tv

Turn standby off

Wait

I was able to reproduce the kernel panics over and over again within 8 hours. I checked my Ram which is fine and also checked my hardware. I'm now pretty certain that it isn't a hardware issue.

Today I've tried my test with Google Chrome (Safari closed) and the book kept on working for now 1,5 days straight.

It would be great if anybody could confirm my findings... I let my book run on any stream for the night. If you wake up in the morning and your book has turned off or restarted, you either haven't turned of standby or you're Mac crashed. In latter case OSX will prompt you with a corresponding message.

More Like This

Incoming Links

Related Articles

This site contains user submitted content, comments and opinions and is for informational purposes only.
Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site.
All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.