OSX 10.7, 10.8 and 10.9 on the Dell XPS 1340 laptop

[bcc9]

So, I moved ACPI_SMC_PlatformPlugin out of /S/L/E and viola no more panic, and also I can boot with the 10.8.3 nvidia drivers. No more hang.

Digging further, it was 9400m_gstate_inject that was triggering the problems. Looks like mapping this system's AGPM g-state to control-id 16 no longer works. Everything is fine without 9400m_gstate_inject (and I no longer need to break ACPI_SMC_PlatformPlugin).

[cmputr]

Hi, first would like to thank bcc9 for this great guide and all your hard work. I followed the guide "exactly" for my Mountain Lion install but no matter what I do I'm getting this [ PCI Configuration Begin ] hang when using DSDT.aml (I CAN boot without it) I also don't have this PCI hang on 10.6.3. I CAN'T use the dsdt-check.pl because when I run it I only get "Address space not recognized. Please post the output from showbootermemorymap" so I tried both DSDT.aml / DSDT-alt.aml to no avail. I have also tried metamorphoise's metamorphoiseDSDT.zip .. I have been trying to get past this for more then a WEEK So if someone can help me out it would be greatly appreciated. I'll be waiting for someones response. THANKS

 

Edit: I've tried npci=0x2000

log.zip

[bcc9]

My dsdt-check.pl and showbootermemorymap were designed to troubleshoot the ACPI memory space issues that some users started seeing as of osx 10.7. The script doesn't work with older OSX (10.6), but that should be OK - it's meant to be run on the version of osx that you're trying to work with not an old release.

 

If that doesn't describe your issue, then you'd do well to post the showbootmermemorymap output as the script asked you to.

 

Now, normally I update post #1 to include the latest&greatest fixes, but the DSDT changes I made to support current OSX for users with discrete GPUs (9500m/g210m) continues to lack proper feedback. I cannot clean things up without some complete feedback. For reference, the two candidate fixes are:

 

v4: http://www.insanelymac.com/forum/topic/272546-osx-107-and-108-on-the-dell-xps-1340-laptop/page-9?do=findComment&comment=1861302

v5: http://www.insanelymac.com/forum/topic/272546-osx-107-and-108-on-the-dell-xps-1340-laptop/page-10?do=findComment&comment=1861410

 

If someone would benchmark which of these two actually lowers the power consumption for discrete GPU users (with kill-a-watt or some time-based measurements as asked for), then I'd know what to do next to clean things up.

 

If v4 really improves power consumption as much as v5 then v4 is probably the best fix, else some more refinement could be tried on v5 to fix its system_profiler side-effect.

 

Lacking feedback, post #1 remains busted and you need to use my v4 or v5 fix referenced above else discrete-gpu users see the system hanging during boot after "PCI Configuration Begin" is displayed.

 

PS: This same lack of feedback issue has been going on for a long time now:

http://www.insanelymac.com/forum/topic/272546-osx-107-and-108-on-the-dell-xps-1340-laptop/page-10?do=findComment&comment=1861540

 

http://www.insanelymac.com/forum/topic/272546-osx-107-and-108-on-the-dell-xps-1340-laptop/page-11?do=findComment&comment=1872146

 

if nobody is going to follow up with responses and instead just disappear once they've taken enough information to get their system working, then I propose this thread gets closed.

[cmputr]

My dsdt-check.pl and showbootermemorymap were designed to troubleshoot the ACPI memory space issues that some users started seeing as of osx 10.7. The script doesn't work with older OSX (10.6), but that should be OK - it's meant to be run on the version of osx that you're trying to work with not an old release.

I'm running the script from 10.8

 

If that doesn't describe your issue, then you'd do well to post the showbootmermemorymap output as the script asked you to.

 

$ sudo ./showbootermemorymap 
Type       Physical Start   Number of Pages
available  0000000000000000 000000000000009d
reserved   000000000009dc00 0000000000000002
reserved   00000000000d2000 0000000000000002
reserved   00000000000e4000 000000000000001c
available  0000000000100000 000000000006fdc0
ACPI_recl  000000006fec0000 000000000000000f
ACPI_NVS   000000006fecf000 0000000000000016
reserved   000000006fee5000 000000000000001b
reserved   000000006ff00000 0000000000010000
reserved   000000007ff00000 0000000000000100
reserved   00000000e0000000 0000000000010000
reserved   00000000fec00000 0000000000000010
reserved   00000000fee00000 0000000000000001
reserved   00000000fff80000 0000000000000080

For reference, the two candidate fixes are:

 

v4: http://www.insanelymac.com/forum/topic/272546-osx-107-and-108-on-the-dell-xps-1340-laptop/page-9?do=findComment&comment=1861302

v5: http://www.insanelymac.com/forum/topic/272546-osx-107-and-108-on-the-dell-xps-1340-laptop/page-10?do=findComment&comment=1861410

 

Still the same [ PCI Configuration begin ] hang  

 

Stupid Question: Could it be because I have only one 2gb stick of ram? The second stick gave out. ( also changed wireless card )

 

If someone would benchmark which of these two actually lowers the power consumption for discrete GPU users (with kill-a-watt or some time-based measurements as asked for), then I'd know what to do next to clean things up.

I would have no problem doing this for you but DSDT's still Hanging the system  

 

 

if nobody is going to follow up with responses and instead just disappear once they've taken enough information to get their system working, then I propose this thread gets closed.

Please dont close the thread i'll give you as much feedback as I possibly can.

 

I am hoping you can help me get this working. Any more suggestions will be appreciated.

[bcc9]

Still the same [ PCI Configuration begin ] hang  

 

Stupid Question: Could it be because I have only one 2gb stick of ram? The second stick gave out. ( also changed wireless card )

Ok, now we're getting somewhere. So your system does infact have a different memory region layout than everyone else, so you need a different DSDT with addresses that match yours.

Yes, it's expected that you are still hanging with the custom dsdts since they aren't matching your layout.

And yes, I'd assume your layout is different because you're running with 1/2 the normal memory.

Here's 2 DSDTs that match your layout, otherwise identical to the v4 and v5 candidates posted above.

 

I'd be very interested to know whether v4&v5 have the same power draw or whether v5 is better or what.

alt2-dsdt.zip

[cmputr]

Good news, I think we are making progress. 

 

Both DSDT's from alt2-dsdt.zip got me past [ PCI Configuration Begin ] but graphics are still at 1024 x 768. (9400M G + G210M)

 

EDIT: no battery status. LID close detection works but when I open the laptop I see a black screen and I lose mouse function.

[bcc9]

Good news, I think we are making progress. 

 

Both DSDT's from alt2-dsdt.zip got me past [ PCI Configuration Begin ] but graphics are still at 1024 x 768. (9400M G + G210M)

With the dsdt, your graphics strings should be getting injected into your ioregistry automatically. Check and or post your ioregistry to verify. GraphicsEnabler should no longer be used as it erroneously adds injection strings to both graphics pci IDs intead of just the 9400m part. Newer nvidia drivers only work with the injection strings on the 9400m part.

[cmputr]

With the dsdt, your graphics strings should be getting injected into your ioregistry automatically. Check and or post your ioregistry to verify. GraphicsEnabler should no longer be used as it erroneously adds injection strings to both graphics pci IDs intead of just the 9400m part. Newer nvidia drivers only work with the injection strings on the 9400m part.

 

not using GraphicsEnabler.

would you mind pointing me in the right direction to find the string in ioregistry? thanks

 

Edit: Very sorry, I'm new to hackintosh. I'm a long time Windows user. Anyway, Im looking in ioregistry and I see ..

IGPU@0

model   data  <"NVidia Geforce 9400M G">

 

I also just looked in About This Mac>Graphics/Displays and it says: "There was an error while gathering this information."

[bcc9]

not using GraphicsEnabler.

would you mind pointing me in the right direction to find the string in ioregistry? thanks

 

Edit: Very sorry, I'm new to hackintosh. I'm a long time Windows user. Anyway, Im looking in ioregistry and I see ..

IGPU@0

model   data  <"NVidia Geforce 9400M G">

 

I also just looked in About This Mac>Graphics/Displays and it says: "There was an error while gathering this information."

Failing to get working battery status or native resolution (which in turn is due to failure to get the nvidia accelerated framebuffer kext to run) are symptoms of a misconfig. I think if you'll look back at previous posts in this thread you'll see this is almost always the case. The exception is when a new release comes out and something breaks. You should look back to see if the previous solutions apply to you.

 

Usually people say they are following post #1 but they are instead just cherry picking what parts of post #1 they think are important, and they wind up with a misconfig. The easiest way to get a misconfig is to use tonymac's installers which will configure a bunch of things without your knowledge.

 

If your ioregistry output really shows "NVidia Geforce 9400M G" (sic) not

"NVidia GeForce 9400M G" then you installed something else such as an old nvidia kext injector that is messing things up. Some of the older injectors mis-capitalized GeForce (compared to a genuine mac). Not that the capitalization matters to the driver, but it's a telltale sign.

 

If you don't know what to look for, posting all of the ioreg -lw0 output is the usual starting point.

 

For your particular case, you want the IGPU@0 sub-tree to be populated with the expected nvidia injection strings, ie all of those found in my dsdt edit especially NVCAP, and you want the XVR0 subtree to have no nvidia injection strings attached.

Additionally you want to see that both of these subtrees are flagged as matched&active, and that the nvidia driver added the other usual strings such as NVDA,gart-width.

 

As for the system_profiler output, I did just tell you that v5 of my dsdt breaks this as a side effect. This probably can be fixed, but I don't even know whether the v5 changes are necessary vs v4. I do not have a 1340 with discrete graphics so again I've been waiting for feedback before doing anything.

[cmputr]

bcc9 your alt2-dsdt.zip files worked. Everything is working now. 

 

I'm not exactly sure where I went wrong but after reading your post I went back and looked over everything in ioreg. Everything you said that should be in there was in there. So I decided to just start from scratch.

 

So I redid my usb installer and reinstalled everything over again. After following your guide the second time and using the DSDT-alt2 everything is working. 

 

If your ioregistry output really shows "NVidia Geforce 9400M G" (sic) not
"NVidia GeForce 9400M G" then you installed something else such as an old nvidia kext injector that is messing things up. Some of the older injectors mis-capitalized GeForce (compared to a genuine mac). Not that the capitalization matters to the driver, but it's a telltale sign.

 

Sorry, "NVidia Geforce 9400M G" was a typo on my part. It does infact say "NVidia GeForce 9400M G"

 

If someone would benchmark which of these two actually lowers the power consumption for discrete GPU users (with kill-a-watt or some time-based measurements as asked for), then I'd know what to do next to clean things up.

 

Here you go. Hope this is what you need. 

 

DSDTv4 ( Laptop sitting with screen on - not running anything )

START: 3:45pm @100% battery

STOP: 5:30pm @7% battery

Total :: 105 mins.

 

DSDTv5 ( Laptop sitting with screen on - not running anything )

START: 7:53pm @100% battery

STOP: 10:06pm @7% battery

Total :: 133 mins.

 

I know you've done tutorials for OS X on this laptop for a while now ( Without you we wouldn't be running this great OS on our laptops ) so I hope you don't mind me asking but will you be doing a tutorial on OS X Mavericks? If not then that's cool   I just thought I'd ask.

 

Thank You for this tutorial and for helping me out! 

[bcc9]

Ok, so it looks like DSDTv5 is necessary to get the power savings, and it is the vendor-id change in DSDTv4 that is causing the system_profiler error.

So, here's a v6 with the power-off command for the co-processor but without the vendor-id change. If this one boots then it should provide the power savings & working system_profiler at the same time.

 

If OSX 10.9 requires completely new install instructions (doubt it), then I'll probably not bother. If it's just one or two tweaks to the existing instructions, I'll probably post them here. My old 1340 will probably be relegated to spare parts in a few months so any software upgrades to it are becoming lower&lower priority.

 

Edit: This new dsdt is merged into post #1.

[cmputr]

Ok, so it looks like DSDTv5 is necessary to get the power savings, and it is the vendor-id change in DSDTv4 that is causing the system_profiler error.

So, here's a v6 with the power-off command for the co-processor but without the vendor-id change. If this one boots then it should provide the power savings & working system_profiler at the same time.

 

It boots and as far as I can tell dsdt-coprocessor.v6 is working perfectly.

Again thank you for all your hard work. I wouldn't have a fully functional 10.8 install without your help.

[bcc9]

It boots and as far as I can tell dsdt-coprocessor.v6 is working perfectly.

Again thank you for all your hard work. I wouldn't have a fully functional 10.8 install without your help.

Great, looks like we have a winning version. I've merged the new DSDT into the version in post #1, and also updated the dsdt-check.pl script so that it can auto-generate .dsl for any new address space flavors that turn up (we've seen 3 different values so far).

[bchan]

I am unable to get the battery working.

 

The dsdt script fails and says it command not found.

I managed to run it by itself in sudo but I don't know what it means.

 

 

Type       Physical Start   Number of Pages

available  0000000000000000 000000000000009d

reserved   000000000009dc00 0000000000000002

reserved   00000000000e4000 000000000000001c

available  0000000000100000 00000000000afdc0

ACPI_recl  00000000afec0000 000000000000000f

ACPI_NVS   00000000afecf000 0000000000000016

reserved   00000000afee5000 000000000000001b

reserved   00000000aff00000 0000000000010000

reserved   00000000bff00000 0000000000000100

reserved   00000000e0000000 0000000000010000

reserved   00000000fec00000 0000000000000010

reserved   00000000fee00000 0000000000000001

reserved   00000000fff80000 0000000000000080

available  0000000100000000 00000000000c0000

 

[bcc9]

The dsdt script fails and says it command not found.

I managed to run it by itself in sudo but I don't know what it means.

If you unpack all of the dsdt .zip from post #1 into a directory, then dsdt-check.pl and showbootermemorymap are in the same directory and dsdt-check should locate showbootermemorymap without a problem.

 

I don't understand how you were able to unpack both scripts and somehow get an error. Lacking an error message, I have to assume you just unpacked the perl script by itself first. ?

 

Your output from showbootermemorymap shows the standard address for the ACPI memory regions, and so the main DSDT.aml is applicable for your machine. Ie copy DSDT.aml to /Extra/DSDT.aml

[Alex Neres]

After some attempts, I finally managed to install the Mountain Lion on my 1340. The only issues, as was to be expected, is the icon battery and the sleep. But my battery is on the final lifetime and this functionality does not make me miss. 

 

So, I resolved to test part this installation guide to install the Mavericks Developer Preview. For my surprise, works perfectly like the Mountain Lion. The inicial setup I do with myHack and the post install, using the step-by-step of post #1. The icon battery and sleep still not running!

 

Thanks for the help of everyone who contributed to this topic. And sorry for poor english! 

[bcc9]

After some attempts, I finally managed to install the Mountain Lion on my 1340. The only issues, as was to be expected, is the icon battery and the sleep. But my battery is on the final lifetime and this functionality does not make me miss.

I wouldn't say these are expected issues, as there is no known problem with those items when post #1 is followed fully. AFAIK.

So, I resolved to test part this installation guide to install the Mavericks Developer Preview. For my surprise, works perfectly like the Mountain Lion. The inicial setup I do with myHack and the post install, using the step-by-step of post #1. The icon battery and sleep still not running!

 

Thanks for the help of everyone who contributed to this topic. And sorry for poor english! 

Cool, good to know 10.9 works on this system as well. The post #1 procedure should basically work for 10.9 too, I just need to generalize the volume names now that apple changed them in 10.9 and add 1 more step for extracting mach_kernel.

[bchan]

If you unpack all of the dsdt .zip from post #1 into a directory, then dsdt-check.pl and showbootermemorymap are in the same directory and dsdt-check should locate showbootermemorymap without a problem.

 

I don't understand how you were able to unpack both scripts and somehow get an error. Lacking an error message, I have to assume you just unpacked the perl script by itself first. ?

 

Your output from showbootermemorymap shows the standard address for the ACPI memory regions, and so the main DSDT.aml is applicable for your machine. Ie copy DSDT.aml to /Extra/DSDT.aml

I got "/Users/Ben/Desktop/dsdt/dsdt-check.pl

sudo: ./showbootermemorymap: command not found"

 

I'll try the DSDT though

[bcc9]

I got "/Users/Ben/Desktop/dsdt/dsdt-check.pl

sudo: ./showbootermemorymap: command not found"

 

I'll try the DSDT though

Oh I see finally, you typed out the whole path to the perl script instead of using ./dsdt-check.pl as per the readme. I've updated the script in post #1 to handle this case as well.

Also updated post #1 to include 10.9 installation instructions, though I have not tried it yet myself on this laptop. The basic install instructions should be correct however. No need to use some unsupported 3rd party install tools.

[Alex Neres]

So far, no solution to the battery icon? 

[bcc9]

So far, no solution to the battery icon? 

Battery status works, at least up until 10.8.3 (I haven't tried 10.8.4 yet myself). What release are you having problems with?

[Alex Neres]

So that's! I'm using 10.8.4. I did the update from 10.8 directly to 10.8.4.    

[bchan]

Oh I see finally, you typed out the whole path to the perl script instead of using ./dsdt-check.pl as per the readme. I've updated the script in post #1 to handle this case as well.

Also updated post #1 to include 10.9 installation instructions, though I have not tried it yet myself on this laptop. The basic install instructions should be correct however. No need to use some unsupported 3rd party install tools.

Ah sorry, I didn't understand the instructions so I just drag and dropped it into terminal, I did it the way I was supposed to and indeed it did say DSDT.aml

 

My battery however still isn't working. When its loading in verbose it says that voodoo is working, but still it does not display the battery reading.

[bcc9]

So that's! I'm using 10.8.4. I did the update from 10.8 directly to 10.8.4. 

Typically battery status only breaks if AppleACPIPlatform has major changes that break my installer in post #1. Since AppleACPIPlatform is the same in 10.8.3&10.8.4 I would expect there to be no problem.

Sounds like you forgot to re-run my AppleACPIPlatform patch after upgrading.

And/or you don't have the patched DSDT being loaded.

My battery however still isn't working. When its loading in verbose it says that voodoo is working, but still it does not display the battery reading.

Same answer for you I think. If you've truly followed post #1, next step is to turn on acpi debugging.

[bchan]

Typically battery status only breaks if AppleACPIPlatform has major changes that break my installer in post #1. Since AppleACPIPlatform is the same in 10.8.3&10.8.4 I would expect there to be no problem.

Sounds like you forgot to re-run my AppleACPIPlatform patch after upgrading.

And/or you don't have the patched DSDT being loaded.

Same answer for you I think. If you've truly followed post #1, next step is to turn on acpi debugging.

I get this, so I assumed that it was already patched:

Found no matching instructions to patch.  AppleACPIPlatform may already be patched
Aborting with AppleACPIPlatform NOT patched

I'm using 10.7.4 if it makes any difference.

 

How do I debug or reset it to normal so I can run it? My lid works, but the rest of it does not, so I assumed it was the DSDT. When I try to put it to sleep, it restarts if it means anything.

 

And thank you very much for helping.