Trouble booting installer 10.8.0 with ProBook 4440s

[kpkp]

I wonder if an SSDT that maps the HD3K device-id to one that is *not* supported might work to keep HD3K kext from loading. The one attached maps to to 0x0122 (happens to be unsupported desktop HD3K):

Maybe I got wrong what you said... But using safe mode on hd4000, I still need to have the right Platform-Id or i get a black screen. So I would agree that -x doesn't prevent the graphic driver from loading.

 

[RehabMan]

Maybe I got wrong what you said... But using safe mode on hd4000, I still need to have the right Platform-Id or i get a black screen. So I would agree that -x doesn't prevent the graphic driver from loading.

Yes, that's what I would expect given what we are seeing here...

My thought is to force the generic graphics driver to load by mapping the device-id to one unsupported (just to boot the installer). Because I was thinking that safe mode would keep these drivers from loading (because people reported safe mode solving some issues graphics-wise) when clearly it doesn't. Why safe mode helps at all for some people, I'm not sure -- probably a different driver causing problems...

 

[kpkp]

Yes, that's what I would expect given what we are seeing here...

My thought is to force the generic graphics driver to load by mapping the device-id to one unsupported (just to boot the installer). Because I was thinking that safe mode would keep these drivers from loading (because people reported safe mode solving some issues graphics-wise) when clearly it doesn't. Why safe mode helps at all for some people, I'm not sure -- probably a different driver causing problems...

Safe mode defiantly does help in same cases, I know because I did quite some experimenting with the hd4000 driver and not always things went smooth. So sometimes i had to overwrite a driver from a different OSX installation or something shady like that... And in that case safe mode helped.
But yes, a unsupported device-id should get you the "VESA mode".

 

[BigDonkey]

Perhaps manually patching the kext will be less time consuming in this case rather than new DSDT?

http://www.tonymacx86.com/graphics/53925-qe-ci-hd3000-series-7-mainboards.html


I'm pretty sure I tried everything on 4540S with SandyBridge CPU including safe mode attemps and tricks to load it in "Vesa Mode" before reverting back to Ivy CPU in order to fix DSDT.

I should have better documented my experience with Sandy CPUs on motherboard with the latest chipset and PBI+mini SSDT solutions. Will do next time.

 

[RehabMan]

It is weird that the IMEI inject via SSDT doesn't work.

But now after trying safe mode on my own ProBook I see why it might not help much. On my 4530s, AppleIntelSNBGraphicsFB.kext still loads with "-x". Updates to the screen are slow, but the FB is still active according to About this Mac and in the ioreg.

I wonder if an SSDT that maps the HD3K device-id to one that is *not* supported might work to keep HD3K kext from loading. The one attached maps to to 0x0122 (happens to be unsupported desktop HD3K):

I found it took a bit more 'brute-force' to keep the graphics driver from loading on my HD3K 4530s. In addition to device-id inject, needed to also inject 'compatible'.

The SSDT attached, copied 'by itself' to /Extra/ssdt.aml on a Unibeast USB, gives me VESA graphics driver on my 4530s. It keeps the HD3K driver from loading by mapping the device-id to something not recognized by OS X. Same effect as removing the /S/L/E/AppleIntelSNBGraphicsFB.kext from the USB. I would imagine it would have the same effect with an Ivy setup, as both devices are _SB.PCI0.GFX0.

I think this is probably a pretty good technique to have... it should take graphics issues completely out of the picture (for HD3K/HD4K) when trying to get into the OS X installer. Assuming the VESA driver always works, and there is no other issues (AMD switchable, etc)...

Contents/source of the SSDT:

DefinitionBlock("ssdt.aml", "SSDT", 2, "HPQOEM", "general", 0x00001000)
{
    External(_SB.PCI0.GFX0, DeviceObj)
    Method(_SB.PCI0.GFX0._DSM, 4, NotSerialized)
    {
        If (LEqual (Arg2, Zero)) { Return (Buffer() { 0x03 } ) }
        Return (Package()
        {
            "device-id", 
            Buffer() { 0x22, 0x01, 0x00, 0x00 },
            "compatible",
            Buffer() { "pci8086,122" }
        })
    }
}

 

[willpower101]

Ok. just for note, two more things I can try are:
1. using that other ssdt that rehabman posted
2. Manually patching the graphics kext

I'm still in the process of patching my own dsdt.
It's a mess because the macbook pro is on 10.6.8 so maciasl won't run.
So, after extracting the dsdt with rw-everything in windows I had to swap the i3 back over to the g770 to use maciasl.

I used your patch repo but there are 5 compile errors that I have no idea how to fix. Can you take a quick look?
http://www.mediafire.com/download/u54q8dmsjd5u5g5/DSDT-sandy4440sorig.asl.aml
http://www.mediafire.com/download/7wvngv94mu9qjue/DSDT-sandy4440spatched.dsl

Am I right in assuming that using your repo to apply the patches automatically grabs things like 07_MEI_4x40s_Sandy.txt? (It appeared that it was included in the dsdt after the patch)
Is that the imei patch that BigDonkey is speaking of?


[Edit] Sweet! I'll try that above disabler. I want to make sure my dsdt edits are correct first because I dont' want to have to swap the i3 back over again.

 

[RehabMan]

Ok. just for note, two more things I can try are:
1. using that other ssdt that rehabman posted
2. Manually patching the graphics kext

I'm still in the process of patching my own dsdt.
It's a mess because the macbook pro is on 10.6.8 so maciasl won't run.
So, after extracting the dsdt with rw-everything in windows I had to swap the i3 back over to the g770 to use maciasl.

I used your patch repo but there are 5 compile errors that I have no idea how to fix. Can you take a quick look?
http://www.mediafire.com/download/u54q8dmsjd5u5g5/DSDT-sandy4440sorig.asl.aml
http://www.mediafire.com/download/7wvngv94mu9qjue/DSDT-sandy4440spatched.dsl

You can also use DSDT Editor to patch from 10.6.8, or could even use patchmatic from Terminal (sorry, no instructions written down anywhere for that).

I downloaded your 4440spatched.dsl and it compiled zero errors. Don't confusing warnings/remarks with errors.

Am I right in assuming that using your repo to apply the patches automatically grabs things like 07_MEI_4x40s_Sandy.txt? (It appeared that it was included in the dsdt after the patch)
Is that the imei patch that BigDonkey is speaking of?

Yes, the repo maintains some files 4x30s.txt, 4x40s_IvyBridge.txt, 4x40s_SandyBridge.txt as combinations of the other files.

[Edit] Sweet! I'll try that above disabler. I want to make sure my dsdt edits are correct first because I dont' want to have to swap the i3 back over again.

Yeah, give it a try. It might help isolate graphics from the rest...

 

[willpower101]

You can also use DSDT Editor to patch from 10.6.8, or could even use patchmatic from Terminal (sorry, no instructions written down anywhere for that).

I downloaded your 4440spatched.dsl and it compiled zero errors. Don't confusing warnings/remarks with errors.

Good deal. I did indeed confuse them. brb with more info.

 

[willpower101]

No Dice on the ssdt's. (Worked perfect with the dsdt I made though)

Tried just the disablegrahics ssdt by itself.
Tried both the disablegraphics ssdt and the imei as ssdt-1.

In both cases I tried (in this order):
1. -v
2. -v PCIRootUID=0
3. -v PCIRootUID=0 GraphicsEnabler=No
4. -v -x PCIRootUID=0 GraphicsEnabler=No

All hung on the "using buffer headers" line just after "mac framework" (No BT init)

I'm glad to keep testing for you if you would like to find a solution other than having to build a dsdt pre-install.

 

[RehabMan]

No Dice on the ssdt's. (Worked perfect with the dsdt I made though)

Tried just the disablegrahics ssdt by itself.
Tried both the disablegraphics ssdt and the imei as ssdt-1.

In both cases I tried (in this order):
1. -v
2. -v PCIRootUID=0
3. -v PCIRootUID=0 GraphicsEnabler=No
4. -v -x PCIRootUID=0 GraphicsEnabler=No

All hung on the "using buffer headers" line just after "mac framework" (No BT init)

I'm glad to keep testing for you if you would like to find a solution other than having to build a dsdt pre-install.

You would have to get back to the point where it stops at BT init (where we started this conversation). Because if you're hanging after "MAC framework..." then you're not making it to the point of graphics init. It would be truly weird if having the SSDT (disabler) present prevents you from getting to the BT init, but without it you get there!??

It would be nice to know what DSDT patch/addition allows the installer to start, because then we might be able to figure out a kext deletion/modification, or SSDT add-on to help.

With a patched DSDT, you boot the installer with no flags, I suppose.

But having to pre-patch your DSDT is not such a bad thing, especially if you have a Mac you can run MaciASL on. It just isn't very noob friendly.