Having continued to test our solution to the Apple OS X ‘superbug’, we have discovered some more information about the problem and the solution(s), some of it good, some of it not so good.
Let’s start off with the worst first. That way we can read the better news the further that we continue with the article (along with optionally singing along to ‘Things Can Only Get Better‘ if desired).
Unfortunately, on our testing machine, after implementing the solution documented previously we encountered another kernel panic, very similar to the ones previously being experienced every five minutes. Obviously this was a huge disappointment. However, one good thing to come from this is the previous solution is still successful, albeit not the permanent solution we originally hoped it was.
The solution has shown to significantly decrease the number of kernel panics involved. On our testing machine it reduced the number of kernel panics by a factor of 168x – which is a good result in our books. However, kernel panics, even much less frequent, are still extremely inconvenient, annoying and unproductive.
The main culprit is once again NVDAResman – which is a process related to the nVidea discrete graphics card. So we’ve had a look into using gfxCardStatus again, as it would seem that, although not ideal, if we can effectively disable switching to the discrete graphics card and restrict OS X to just on the onboard Intel based graphics card, that should eliminate the panics totally.
One issue remains though, and that is the strange behaviour and inability of the Intel graphics card to render the screen in any kind of readable or useable format when using the Intel graphics card only. This happened periodically to use throughout testing which is initially why we searched for another solution.
However, to our delight, the previous solution that we gave appears to have rectified the issues regarding the display of the screen using only the Intel graphics card.
So the updated advice is to complete the previous solution and to continue to us gfxCardStatus on the ‘Integrated only’ option. Thus far, on our testing machine, this has prevented further kernel panics and logic would dictate that if the nVidea graphics card is not in use, NVDAResman won’t be causing further kernel panics. We’re going to continue with testing the revised solution and keep you informed. So far, so good.
As previously mentioned, the downside to using gfxCardStatus and the ‘Integrated only’ option is that the integrated Intel graphics card is the least powerful of the two. However, better to be using a less powerful graphics card than to have an unusable machine.
Another note that we would like to add regarding information about the problem.
We have noticed that one thing that seems to trigger a lot of kernel panics, basically exacerbating the problem and speeding up the frequency of them, is frequent switching between windows. Whether this is happening due to switching windows itself or a common underlying process being shared by other system components is not known at this stage. Obviously, switching windows has been quite a fundamental part of computing since multitasking OS’s in the 90s and it’s equally unproductive to minimise window switching. However, frequent window switching is know to accelerate the rate of the kernel panics quite significantly.
As always, we will keep you updated on our tests and how the issue develops.