Constant Kernel Panics on OS X Mountain Lion.

Yes...

These look like memory register faults:

Tue Mar 5 16:07:28 2013

panic(cpu 2 caller 0xffffff80270b7bd5): Kernel trap at 0xffffff8027315297, type 13=general protection, registers:

CR0: 0x0000000080010033, CR2: 0x000000010c7c0000, CR3: 0x0000000084c6a03a, CR4: 0x00000000000606e0

RAX: 0x00000000ffffffff, RBX: 0x7fffff8043899e80, RCX: 0x0000000021000001, RDX: 0x0000000000000000

RSP: 0xffffff81488136a0, RBP: 0xffffff8148813700, RSI: 0x0000000000000001, RDI: 0xffffff804387b688

R8: 0xffffff8148813490, R9: 0xffffff814881348e, R10: 0xffffff8040f6c47e, R11: 0x0000000000000028

R12: 0x0000000000000001, R13: 0xffffff8043877000, R14: 0xffffff804387b670, R15: 0x0000000000000001

RFL: 0x0000000000010286, RIP: 0xffffff8027315297, CS: 0x0000000000000008, SS: 0x0000000000000010

Fault CR2: 0x000000010c7c0000, Error code: 0x0000000000000000, Fault CPU: 0x2

Backtrace (CPU 2), Frame : Return Address

0xffffff8148813340 : 0xffffff802701d626

0xffffff81488133b0 : 0xffffff80270b7bd5

0xffffff8148813580 : 0xffffff80270ce4ed

0xffffff81488135a0 : 0xffffff8027315297

0xffffff8148813700 : 0xffffff80273189fc

0xffffff8148813730 : 0xffffff80271120af

0xffffff8148813760 : 0xffffff80270f18d3

0xffffff81488137b0 : 0xffffff80270f1021

0xffffff81488137f0 : 0xffffff80270f7dd6

0xffffff8148813820 : 0xffffff80270efdae

0xffffff81488138e0 : 0xffffff80272f0da2

0xffffff81488139e0 : 0xffffff80272f8f62

0xffffff8148813c00 : 0xffffff8027111674

0xffffff8148813c40 : 0xffffff80270eb79c

0xffffff8148813cc0 : 0xffffff80270eb18e

0xffffff8148813d80 : 0xffffff80270d9dd0

0xffffff8148813f50 : 0xffffff80273e182a

0xffffff8148813fb0 : 0xffffff80270ced33

I'm 99% certain that's the problem.

Clinton

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.

Looking forward to a fully working display.

If it's the faulty GPU - http://support.apple.com/kb/TS4088 - it looks as if they just updated that document a couple of weeks ago...

Clinton

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?

Clinton

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.

Clinton

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!

clintonfrombirmingham wrote:

Yes...

These look like memory register faults:

not register itself, see:

Fault CR2: 0x000000010c7c0000, Error code: 0x0000000000000000, Fault CPU: 0x2

"CR2 Contains a value called Page Fault Linear Address (PFLA). When a page fault occurs, the address the program attempted to access is stored in the CR2 register."

Scott Finlayson wrote:

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)

also on understanding pagefault error codes:

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.

dmdimon wrote:

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

here we go:

Serial ATA Device: Corsair Force 3 SSD, 120.03 GB

2011 MBP's have had problems with SATA III drives, exactly interface timeouts. There was 2 firmware updates for them. I had this problem also, now its gone.

A couple of weeks ago sporadic KP startet on my MBP Late 2008 (first unibody generation) with 10.8.2. After my research I believe Safari+Latest Flash Plugin causes my KP.

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.

Aramn V-

those are interesting theories and interesting experiments.

Please post a kernel panic log.