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

[bcc9]

Over the last couple years I have managed to keep my system running with my own tweaks here and there keeping it alive. For some reason though, with my 10.8.2 USB installer I am still unable to get graphics, using ANY of the new DSDTs including the latest one. For some reason when I boot into my 10.7.5 Install on the SSD ( graphics stopped working after the latest update in September) I can remote into the system using VNC but only after booting the system in safe mode. For some reason booting in verbose mode makes it kernel panic after the verbose output hits macx_swapon. Right before that line it prints NVDANV50HAL loaded and registered and then [AGPM Controller[ unknownPlatform followed again by the loaded and registered. The odd thing here is that when I am able to boot into it in safe mode with VNC, it doesn't seem to be detecting the display so I must be missing something. I can tell that the Installer for 10.8.2 has booted based on the blinking of my USB flash drive intermittently but the graphics never come up even after leaving it sit for a while (in the past the graphics would sometimes kick in automatically and the display would initialize . The problem to me seems to lie in display detection as the display doesn't even seem to power on at all now. Any input or diagnostics steps to troubleshoot would be much appreciated!

1075_ioreg_nodisplay.txt

Your ioregistry shows that you have something configured that is adding nvidia information to your 9200m coprocessor:

| | | | "model" = <"Dell GeForce 9200M GS">

| | | | "NVCAP" = <04000000000001000e0000000000000a00000000>

That of course will make your graphics not work.

I guess you're using GraphicsEnabler or some nvidia injector or your own custom dsdt. In post #1 the instructions were revised so that the 9200m part doesn't get any injection strings to avoid this problem.

 

Why don't you try to follow post #1 (see especially plists.v4.zip)?

[BWR]

I switched over to using the co-processor disabling DSDT revision 5 you posted back on page 10 of this thread. Trying to boot that with the boot.plist and smbios.plist provided in post #1 here and the latest chameleon bootloader seems to be a bust. It gets to NVDANV50HAL loaded and registered. Prints the line about the previous shutdown cause and then sits. I am thinking it's hitting a KP at this point because I can't get it to start for the life of me. I am at a loss having followed the instructions to a T short of there being something different about my setup than most I have no idea where to turn short of going back to 10.6...

IOREG_1082_Booter_dsdt-coprocessor.v5.txt

[bcc9]

I switched over to using the co-processor disabling DSDT revision 5 you posted back on page 10 of this thread. Trying to boot that with the boot.plist and smbios.plist provided in post #1 here and the latest chameleon bootloader seems to be a bust. It gets to NVDANV50HAL loaded and registered. Prints the line about the previous shutdown cause and then sits. I am thinking it's hitting a KP at this point because I can't get it to start for the life of me. I am at a loss having followed the instructions to a T short of there being something different about my setup than most I have no idea where to turn short of going back to 10.6...

IOREG_1082_Booter_dsdt-coprocessor.v5.txt

In your new ioregistry log, the 9400m part is missing the nvidia injection strings (see there are no NVCAP, model, etc. entries under the IGPU device). These are injected by the dsdt so I'm not sure what you've got going wrong.

I see you have chameleon patching your kernel (unlike in your previous ioregistry dump).

I've never tried that before (or recommended it) so maybe there is some problem in that part of what you're doing.

[BWR]

I had completely removed the GraphicsEnabler entry from my boot.plist at that point. I have tried forcing it to no and using the most minimal things to try to get it to boot to no avail. I think we are on the right track with it being an issue with the CoProcessor but aside from that I am in the dark. Before stumbling upon this post I had a completely working system based on bits and pieces I'd cobbled together seems enough has changed in 10.8 that my old methods don't work though sadly. Is there anything I can get from the system that might help in better finding a solution? I really don't want to go back to Windows 7 or Windows 8 :\

[bcc9]

I don't understand where you're coming from; you say you've cobbled your system together yet you say you followed post #1 to a T. Your dumps don't appear to show following of post #1, and there's no way you could cobble together a completely working 1340 without using my work; nobody else has patched AppleACPIPlatform to make the mcp79 GPE handler work, written an osx bluetooth driver for dell's hardware, etc. etc.

Recent posts in this thread do show exactly how to troubleshoot and get things working under 10.8 for systems with the 9200m coprocessor. Things are now working for everyone else with coprocessor hardware under 10.8 AFAIK.

 

Regardless, you do need to get your nvidia graphics injection strings into your ioregistry, if you don't, you won't be able to get QE/CI. Your latest dump has no such injection strings. They are in the DSDTs in post #1 (post #179 for 10.8 users with a graphics coprocessor). If you're trying to use the DSDT in one of those posts, break it down; figure out if you can inject ANYTHING or whether you have a basic problem like your pciroot is misconfigured (not that it should need configuring at all...)

[BWR]

Since my custom configurations stopped working back in 10.6.x times I'd been using bits and pieces some from this forum and others. Either way I scrapped all the custom modifications I'd made and used only the configuration files from this post including the DSDTs to no successful end. It seems to KP right before initializing the GUI.

[bcc9]

Since my custom configurations stopped working back in 10.6.x times I'd been using bits and pieces some from this forum and others. Either way I scrapped all the custom modifications I'd made and used only the configuration files from this post including the DSDTs to no successful end. It seems to KP right before initializing the GUI.

There's lots of simple things you can do wrong during setup that'll make the system panic or hang. Without the panic message details I can only speculate. I'm assuming you ran dsdt-check.pl to figure out the right dsdt to use.

[mikeraffone]

The HDA patcher doesn't work for me, after an update to 10.7.5

 

Upon running, it gets to the "Registering updated components" stage, and then fails.

 

It says:

 

 

Unexpected codec range match count: 0, 4 expected

Aborting with AppleHDA NOT patched

 

I'm trying to patch AppleHDA.kext version 2.2.5

 

Any ideas?

 

Mike

 

P.S. Thanks for your amazing work on disabling the co-processor. My G210m is now disabled.

[bcc9]

The HDA patcher doesn't work for me, after an update to 10.7.5

...

 

P.S. Thanks for your amazing work on disabling the co-processor. My G210m is now disabled.

My newer script:

http://www.insanelymac.com/forum/topic/284004-script-to-patch-applehda-binary-for-osx107108/

handles 10.7.5 which is a bit of a special case. So you'd just run:

patch-hda.pl 111d7675

with that newer version of the script. I'll see about putting the new script into the package installer. I never used 10.7.5 myself as 10.8 came out first (why bother with 10.7.5 in that case?)

 

As for the co-processor work, thanks. Tho I'm still not sure what version is best as nobody got back to me on the outstanding question about power consumption with version v5. Does v5 use less power than v4, or do they both use less power, or...? I can't really update post #1 with new recommendations with no feedback...

[bcc9]

Ok, I've updated AppleHDA.idt in post #1 to version 3, which includes the newer patch-hda.pl script with 10.7.5 support.

 

[rameshb_v]

Hello bcc9, I have updated from 10.7.3 to 10.7.5 on my Dell 1340 9500m. After the update, i also upgraded Chamaleon to latest build 2064, changed DSDT to v5 and used new smbios & org.cham.plist v4 files. Now I am not able to boot. It hangs after NTFS Volume Name , version 3.1. However, I am able to boot into Safe Mode properly and created the ioreg file. kernel log shows the following:

 

DSMOS has arrived

NVDA: : rmStart failed

NVDA, Display-B: Not Usable

nspace-handler-set-snapshot-time: 1355351754

Virtual bool IOHIDEventSystemUserClient::initWithTask(task*, void*, UInt32): Client task not preiveged to open IOHIDSystem for memory maping

 

 

Just as a test, i revereted back to old DSDT.aml and org.chameleon.plist and it hangs at "Still waiting for root device".

 

Please let me know what information I can provide to get advise. THanks..

ioreg.txt

[bcc9]

Hello bcc9, I have updated from 10.7.3 to 10.7.5 on my Dell 1340 9500m. After the update, i also upgraded Chamaleon to latest build 2064, changed DSDT to v5 and used new smbios & org.cham.plist v4 files. Now I am not able to boot. It hangs after NTFS Volume Name , version 3.1. However, I am able to boot into Safe Mode properly and created the ioreg file. kernel log shows the following:

 

DSMOS has arrived

NVDA: : rmStart failed

NVDA, Display-B: Not Usable

nspace-handler-set-snapshot-time: 1355351754

Virtual bool IOHIDEventSystemUserClient::initWithTask(task*, void*, UInt32): Client task not preiveged to open IOHIDSystem for memory maping

 

 

Just as a test, i revereted back to old DSDT.aml and org.chameleon.plist and it hangs at "Still waiting for root device".

 

Please let me know what information I can provide to get advise. THanks..

I have no idea what is going wrong in your case. Your ioregistry output only shows the top level nodes so it doesn't really explain anything. The "Still waiting for root device" error suggests a pretty basic misconfig like your bios doesn't have the disk drives in AHCI mode. Maybe you can narrow down which of the 5 or so changes you made is the one that is causing problems? I have no experience running 10.7.5 myself (since I simply moved forward to 10.8 before 10.7.5 came out).

 

[rameshb_v]

I have no idea what is going wrong in your case. Your ioregistry output only shows the top level nodes so it doesn't really explain anything. The "Still waiting for root device" error suggests a pretty basic misconfig like your bios doesn't have the disk drives in AHCI mode. Maybe you can narrow down which of the 5 or so changes you made is the one that is causing problems? I have no experience running 10.7.5 myself (since I simply moved forward to 10.8 before 10.7.5 came out).

 

Ok. I reformatted the disk and started from Scratch with 10.8.2 this time. I am using DSDT-alt.aml as your script that its the right one. I am using the latest version of chameleon 2069. Now with DSDT, org.chameleon..., smbios.plist in place, the system stops at:

 

It hangs after

NTFS Volume Name , version 3.1

Sandbox: sandbox(92) deny match-lookup com.apple.coresymonicationd

 

Now I tried with DSDT=Null, then it goes beyond NTFS point and then all the text on the screen disapper and the screen turns black(Just looks like I am the point where I am about to get the GUI, but never does). Did any one test DSDT-alt.aml ?

 

I again booted with -v and this time got the kernel Panic this time:

com.apple.iokit.IOGraphicsFamily(2.3.5)

dependency: com.apple.iokit.IOPCIFamily(2.7.2)

com.apple.GeForce(8.8)

dependency com.apple.NVDAResman(8.0.0)

dependency com.apple.iokit.IONDRVSupport(2.3.5)

dependency com.apple.iokit.IOPCIFamily(2.7.2)

dependency com.apple.iokit.IOGraphicsFamily(2.3.5)

 

 

PS: I am able to go to safe mode with GUI.

[bcc9]

Did any one test DSDT-alt.aml ?

Yes per earlier posts in this thread. You can of course dump your own dsdt and compare, and patch yourself to eliminate any question.

For your next step, you probably should try booting without the nvidia kexts in place as recommended in earlier posts. Then if you can boot fine with that you know your problem is limited to your nvidia graphics configuration.

 

[rameshb_v]

Yes per earlier posts in this thread. You can of course dump your own dsdt and compare, and patch yourself to eliminate any question.

For your next step, you probably should try booting without the nvidia kexts in place as recommended in earlier posts. Then if you can boot fine with that you know your problem is limited to your nvidia graphics configuration.

bcc9: I used your DSDT-coprocessor v4 and update the GeForce.kext to the latest driver and now everything works well. My 4 days of nightmare are now end. Thanks very much bcc9.

[bcc9]

 

bcc9: I used your DSDT-coprocessor v4 and update the GeForce.kext to the latest driver and now everything works well. My 4 days of nightmare are now end. Thanks very much bcc9.

Glad you figured it out. I'm confused what the underlying problem was for you - does DSDT-coprocessor v5 not work, with only v4 working, or is it that you had to use nvidia's cuda osx driver instead of the included OSX one?

[rameshb_v]

Glad you figured it out. I'm confused what the underlying problem was for you - does DSDT-coprocessor v5 not work, with only v4 working, or is it that you had to use nvidia's cuda osx driver instead of the included OSX one?

I updated to DSDT-coprocessor v5 with nvidia's cuda driver and it does work. Just for test I also rolled back to original GeForce.kext, and it did work as well. So I am keeping the original and your DSDT-Coprocessor V5. Mine has 9500m, not sure why it needs the coprocessor file. But probably you might need to update the first post with this info. Thanks for your efforts on this....... Attached is the IOREG. Let me know if you need any more info.

ioreg.txt

[bcc9]

 

I updated to DSDT-coprocessor v5 with nvidia's cuda driver and it does work. Just for test I also rolled back to original GeForce.kext, and it did work as well. So I am keeping the original and your DSDT-Coprocessor V5. Mine has 9500m, not sure why it needs the coprocessor file. But probably you might need to update the first post with this info. Thanks for your efforts on this....... Attached is the IOREG. Let me know if you need any more info.

I don't know what to put into the first post as I haven't heard back from anyone as to whether v4 uses more power than v5. If both v4 & v5 show reduced power usage, then the v4 fix is the best as v5 affects system_profiler output. If v5 is better for power usage, then I need feedback on the system_profiler issue.

Also not clear to me whether that is the only issue. Your posts made it sound like you were having nvidia driver version issues as well but then you said you went back to the stock version and things were fine. Yet your first post said you were already at dsdt v5 so I don't see why you had any problems.

 

[rameshb_v]

I don't know what to put into the first post as I haven't heard back from anyone as to whether v4 uses more power than v5. If both v4 & v5 show reduced power usage, then the v4 fix is the best as v5 affects system_profiler output. If v5 is better for power usage, then I need feedback on the system_profiler issue.

Also not clear to me whether that is the only issue. Your posts made it sound like you were having nvidia driver version issues as well but then you said you went back to the stock version and things were fine. Yet your first post said you were already at dsdt v5 so I don't see why you had any problems.

In My first post, I used the ordinary DSDT V5, not the DSDT coprocessor. Thats why I had the problem.

 

I used Kill a Watt and here are my results when XPS 13 is idle.

DSDT V4 Co Processor: 66 watts

DSDT V5 Co Processor: 61 watts

[bcc9]

 

In My first post, I used the ordinary DSDT V5, not the DSDT coprocessor. Thats why I had the problem.

Oops, if I had realized you weren't using the latest I would have recommended that first.

I used Kill a Watt and here are my results when XPS 13 is idle.

DSDT V4 Co Processor: 66 watts

DSDT V5 Co Processor: 61 watts

I don't believe those numbers. I got 19 watts on my 1340 when idle after the AGPM injector was installed:

http://www.insanelymac.com/forum/topic/181293-dell-xps-1340-under-osx-106-including-boot-132-install-cd/page__st__1000#entry1734100

[FUBARed]

so what's up with this thread with no replies since Decemeber 2012?? or a new section for the xps1340?

[bcc9]

so what's up with this thread with no replies since Decemeber 2012?? or a new section for the xps1340?

I don't know, I guess everyone got their system working to their satisfaction and nobody wants to bother with chores such as actually measuring whether there is a power improvement with some of the latest dsdt changes.

Or maybe just anyone else who might have contributed have moved on to more current laptops.

 

My old 1340 is still chugging away running the latest osx (now 10.8.3)...

 

[FUBARed]

I don't know, I guess everyone got their system working to their satisfaction and nobody wants to bother with chores such as actually measuring whether there is a power improvement with some of the latest dsdt changes.

Or maybe just anyone else who might have contributed have moved on to more current laptops.

 

My old 1340 is still chugging away running the latest osx (now 10.8.3)...

 

Thats probably it then hehe.. Before my last post I'd had 10.6.3 and was away for a while just lurking but never did anything else. Then my HDD crashed on the 1340 and of course I had no backup for my OSX, so decided to try a newer version of Mac and did 10.7.3 and worked fine. So then I decided to try ML and wall here I am.. and loaded 10.8.0 + Win8 + Win7 on an SSD drive and WOW it flies!!

 

Currently running 10.8.0 and only thing not working properly is the battery icon. I did see your post on how to fix that, but for some reason I don't get it LoL.

 

What do you recommend for me to go from 10.8.0 to 10.8.3 and the best way to get my battery icon working 100%? TIA

 

Its good to see you again BCC9, You've been a great help since Snow Leopard on my 1340.

[FUBARed]

NVM I figured it myself

[wormx]

First of all, bcc9, you're a godsend.

 

I have had ML 10.8 installed on my 1340 for a while now, but recently something happened (beats me) where my ML partition no longer showed up at Chameleon boot. I tried a few different things, but in the end, I ended up re-installing ML over top of it. Good news is, almost everything works immediately (it really seemed to have simply repaired the old installation). I had to install a few of the items from post #1, but everything else seems good.

 

The only issue I have now is lid detection. Whenever I close my lid, I cannot bring the display back up (even an external monitor). Just a black screen. Computer still appears active. Any thoughts to what might have changed or what I might have missed? I did reinstall the AppleACPIPlatform fix, but still nothing.

 

Everything else is great -- optical drive, battery status, touchpad, audio -- no problems (so far).

 

Any advice anyone can give would be greatly appreciated. Thanks in advance!