ML on E6430 with Intel HD4000 only

[ktbos]

You mentioned you had to reinstall chameleon to the Installer, what version do you have on your ML?

See if you could install the latest to your ML.

http://www.insanelymac.com/forum/files/file/59-chameleon-22-svn/

 

I've already got Chameleon 2.2svn.  When I did the Chameleon reinstall, I did it from myHack 3.2 BETA 8.  But I can see from the build number that it is a date later than the MyHack date, so I did the update.  I needed to boot in safe mode using the USB stick so I could run Chameleon installer.  Same result with the latest version of Chameleon (2.2svn-r2255).

 

I was reading that in Safe Mode, Quartz Extreme is disabled;  that's another sign that it may be a graphics-related issue.  Here is a screenshot from System Report:  SystemReport.tiff  It's running in Safe Mode, so perhaps a kext would be used if it weren't in safe mode - in other words, the reason for the incomplete contents in the report may be due to Safe Mode, not that Safe Mode is the only thing usable because the report contents would be incomplete regardless of mode. 

 

When I boot in Safe Mode, after it has been up for a while, it reports "System extension cannot be used "for myHack.kext", then again for all the parts inside of it. Again, I wonder if the inability to use the kexts is because of Safe Mode or if it would happen in not-Safe Mode too. 

[Jake Lo]

ktbos,

 

What version of Mountain Lion are you running? 

Just want to be sure you got the correct AppleIntelFramebufferCapri with your version installed and ran myHack to update cache and permission. 

[ktbos]

Jake, sorry I didn't get back to you right away yesterday - notification e-mails about post updates aren't coming through consistently. 

 

I'm using 10.8.4 and I chose the 10.8.4 kext version from the guide and renamed it as the guide suggests.  Although I did just try a test removing that kext from the Extra/Extensions directory on the USB stick and booting with UseKernelCache=No and the result was the same as if I had it: hanging before login screen.  I tried booting in Safe Mode again with the kext removed and it still worked the same as when the kext is in use.   So that kext does seem like a likely cuplrit.  Or maybe it's the DSDT/SSDT files aren't defining hardware that can be used by that FramebufferCapri kext?  (Again, I'm using the exact Extra folder that osxjeff posted above with only the change for the boot plist that he described in the post immediately following to fix a typo.  And then the changes I've described in my posts here in this topic.) 

 

Did everything look okay from my lspci output? 

[Hervé]

If this is a myHack installation, did you run myFix after deleting your kext(s)?

 

Removing the kext from /E/E does not change anything until do this. You have to remember that myHack copies kexts from /E/E to place them in the PlugIns of myHack.kext (itself in /S/L/E) when myFix is run. This is the greatness of myHack in that it leaves /S/L/E totally vanilla and allows to bump/override any original /S/L/E kext that may be necessary without doing any modification to that kext.

 

So basically, until you re-run myFix to update /S/L/E/myHack.kext (and also the cache), booting with or without kernel cache changes nothing.

[Jake Lo]

 

Really?  I didn't know lspci was on MacOS.  Feeling stupid about that...  (I only knew of it from Ubuntu!)  And thanks for the tip about the "-nn" too.  I'll remember that. 

lspci is possible through the lspcidrv.kext in E/E.

Yes, sorry I didn't mention to run myhack/myfix each time you replace or remove a kext in E/E. Thanks Herve for noticing.

I'm looking over osxjeff's Extra and noticed he included his entire Extra folder with files from running EDP as well. Inside Extension are almost the same files as mine.

So since you have the same CPU as osxjeff, try using my bootpack with AppleIntelFramebufferCapri and just replace DSDT and SSDTs with his. After replacing the files, launch myHack from Application, select myfix/full to rebuild cache and permission. Hopefully this will resolve your issue. Good luck.

[ktbos]

So basically, until you re-run myFix to update /S/L/E/myHack.kext (and also the cache), booting with or without kernel cache changes nothing.

 

Thanks for that info, Hervé.  No, I had not been consistently running myFix.  (And apologies to Jake for not picking up on what he meant in his last post.)  I had been before, but I wasn't sure what it was doing or when I needed to run it, so I had gotten lazy and skipped it the last few times.  But I had sat down at the keyboard to try figure out why there was no change (when there defintely should have been) so I was glad to read your post and realize quickly what I needed to do.  

 

I repeated the test now doing myFix after every change.  With osxjeff's Extra, I get the hang as I have been reporting.  Pulling the Framebuffer kext out and rerunning myFix made the screen go dark as it had the first time when I was following the guide and had not yet used the Framebuffer.  At least I'm seeing changes now! 

 

And just to make sure that the Framebuffer kext was the right one (since I was just copying osxjeff's Extra and didn't know what version the kext was), when I put the Framebuffer kext back, I copied it from the 10.8.4 guide zip, renamed it, and then reran myFix. The result is the same hang before login. 

 

Recapping:

 - Following the Guide but using osxjeff's Extra gets me stuck before the login. 

 - Not using the Framebuffer kext produces a black screen before login.

 - Running safe mode will get me in consistently

 

I wonder if the black screen I get without the Framebuffer is an indication that I have gotten further or not as far.  i.e. with Framebuffer it fails before the screen goes black perhaps because it is having a problem with the kext loading whereas when Framebuffer is not in there at all, it doesn't try to load it but then doesn't have what it needs to drive the display correctly. 

 

It's also interesting that safe mode works consistently.  And now knowing that the way myHack works is to copy the kexts into myHack.kext and seeing all of those warnings about myHack not being loaded when in safe mode, I wonder if the reason it works in safe mode is because those kexts weren't loaded. 

[Hervé]

It sounds like with the FrameBuffer, you get a dark screen right at the point where the OS switches to Mac OS desktop. When you boot in safe mode, yes, maybe the FrameBuffer is not loaded, so you could reach desktop with default unaccelerated graphics.

 

This is quite similar to what you would get on a D630 Intel without proper DSDT (which contains correct graphics settings). With the D630, if you booted with display out to an external screen, it would revert back to LCD at the point where the OS switched to Mac OS desktop. You could try an external screen, but I doubt it'll do the same in your case.

 

You say you boot with full screen resolution in safe mode but are you able to change res through the display pref pane? Thas is usually handled by the FrameBuffer. However, without FrameBuffer, if your boot plist specifies a specific resolution, the system can boot into that resolution without the ability to change it.

[ktbos]

So since you have the same CPU as osxjeff, try using my bootpack with AppleIntelFramebufferCapri and just replace DSDT and SSDTs with his. After replacing the files, launch myHack from Application, select myfix/full to rebuild cache and permission. Hopefully this will resolve your issue. Good luck.

 

Jake, not only were we replying at the same time, but that's the next thing I was going to try!  (In fact, I think I have tried it already but I probably didn't run myFix after it so that test would have been moot.) 

 

Here's what I did:

  - staged Extra directory using bootpack from guide (new copy to ensure no lingering junk from past attempts)

  - replaced dsdt.aml, SSDT.aml, SSDT-1.aml, and SSDT-2.aml in Extra with osxjeff's

  - added Framebuffer from guide using 10.8.4 version, renamed to AppleIntelFramebufferCapri.kext

  - modified boot plist to change resolution to 1600x900x32

  - Used myHack to load Extra on to USB stick

  - Used myHack to run myFix, Full

 

The result:  hangs in the same place before login. 

 

Next for me to try is pulling out kexts one by one and see if I can get any further (even if something else breaks).  Each time I do that, I'll need to rerun myFix.  It is so slow to run Full, though.  Any tips on when I should run Full vs. when I can run Quick?  It would save me a lot of time if I could do Quick when making these changes.  Or can I just remove the kexts from inside myHack.kext by deleting them from the file system under myHack.kext and then reboot with Kernel cache off? 

[ktbos]

You say you boot with full screen resolution in safe mode but are you able to change res through the display pref pane? Thas is usually handled by the FrameBuffer. However, without FrameBuffer, if your boot plist specifies a specific resolution, the system can boot into that resolution without the ability to change it.

 

How about that.  Safe Mode comes up fine at 1600x900 but I can't change it.  Even after changing to Scaling, the only choice is 1600x900.  At least something is behaving as expected...  Thanks for that explanation, Hervé. 

[Hervé]

Ok, I guess that if you changed to a lower res such as 1366x768 in your Cham boot plist, you'd get the same with the new res... I would say you have an issue either with the DSDT table in relation to screen definition or with the FrameBuffer. Did you try to boot in normal mode with display out to an external screen (HDMI or VGA, I don't know which you have/which works) ?
 
You have the Intel HD4000-only model, I mean no NVS 5200M, right?
 
Yes, you can delete kexts directly from SLE/myHack.kext PlugIns and boot without cache (-f UseKernelCache=No). That'll save you the myFix hassle during your testing phase. If you add kexts, you'll have to check permissions to ensure those added kexts are like the others. If need be, fix permissions with the following Terminal commands:
sudo chmod -R 755 /S/L/E/myHack.kext
sudo chown -R 0:0 /S/L/E/myHack.kext

I'm wondering if we need to look at Jake's DSDT from here and see if there's something editable for the screen res...