Dell XPS 1340 under OSX 10.6, including boot-132 install cd

[olegpronin]

Some days ago I noticed that battery life is {censored} in both Mac OS X Lion and Snow.

 

The one of reasons is that AppleGraphicsPowerManagement is not working normally.

Need some testing here in this thread with and without this kext (it was changed by me, so, just put it to extensions, check out graphic card ID and your macbook model).

 

Please write results here with and without this kext.

 

 

UPDATE.

I strongly recommend to all to use this patch. I have finally done testing, it's working. You only need to open info.plist in it and change your Mac model, probably we have different.

 

The result of this patch is that battery will work double time, little less than in windows, but very good.

 

I have 7800mha battery here (the biggest one), it works in mac os x now 4hours 30 minutes in surfing internet mode.

 

Before it worked around 2 hours 10 minutes.

 

All tests were done in CLEAN system. Tested in 10.6.3, 10.6.7 and 10.7.2 11C35.

Injector.kext.zip

[bcc9]

I did a little testing with this on my 9400m based 1340. I kept my system on wall power, but measured the wattage with a kill-a-watt. This with the system idle, and the antennas turned off.

 

Under windows 7, with the system idle: 16/17 watts

Under OSX 10.6.8, without any AppleGraphicsPowerManagement modification: 25 watts

Under OSX 10.6.8, with your AppleGraphicsPowerManagement injection strings: 19 watts. However, after a display sleep&resume cycle, the wattage settles back up at 25 watts

 

So in normal use, where display sleep is enabled, the effect of your change is negated after the first display sleep&wakeup.

 

Can you explain how you came up with the values you are using? It looks like you took the Threshold values from the macbook6,1 entry, but some of the other keys you took from other entries. You'd think that simply setting the product name in smbios.plist to match one of the apple models that uses the 9400m would be sufficient to get the best power handling but apparently not.

[olegpronin]

Here posted now better graphics PM kext. (10.7.2 11C37). MacBookPro5,5

AppleGraphicsPowerManagement.kext.1.zip

[JBraddock]

I did a little testing with this on my 9400m based 1340. I kept my system on wall power, but measured the wattage with a kill-a-watt. This with the system idle, and the antennas turned off.

 

Under windows 7, with the system idle: 16/17 watts

Under OSX 10.6.8, without any AppleGraphicsPowerManagement modification: 25 watts

Under OSX 10.6.8, with your AppleGraphicsPowerManagement injection strings: 19 watts. However, after a display sleep&resume cycle, the wattage settles back up at 25 watts

 

So in normal use, where display sleep is enabled, the effect of your change is negated after the first display sleep&wakeup.

 

Can you explain how you came up with the values you are using? It looks like you took the Threshold values from the macbook6,1 entry, but some of the other keys you took from other entries. You'd think that simply setting the product name in smbios.plist to match one of the apple models that uses the 9400m would be sufficient to get the best power handling but apparently not.

As far as I am concerned you are right in saying that setting the product name in smbios.plist is enough. But I could also add that graphic power management also looks for particular device name in DSDT, meaning that it either looks for GFX0 or IGPU. In my case, for 9600M GT, if I use GFX0 then I get the wrong control id error. In order to use GFX0, I have to modify the control id to 16 or create a new entry with my vendor and device ids. I haven't tested thoroughly so I don't know which one, GFX0 or IGPU, is better for me. But one thing is clear that once I've enabled this tweak, my CPU load drops and animations in Lion gets way better. The only problem is that GPU doesn't still throttle properly. It still gets stuck at level 2 but it performs better. It is more apparent when I use OS X on battery, which previously was very sluggish. I don't know how much difference tweaking those threshold values would make.

[bcc9]

Does anyone have working battery status with osx lion without reverting AppleACPIPlatform to a 10.6 version?

Nobody has figured out why evaluateObject() fails for _BIF? The problem doesn't lie with my EC patch, as even with the DSDT changed to return a static table in the _BIF method, evaluateObject() still fails.

[bcc9]

As far as I am concerned you are right in saying that setting the product name in smbios.plist is enough.

Actually I wrote that it should be but apparently isn't.

Since apple should have worked out the optimal voltages for a 9400m by now, we should be able to use one of their settings and get the optimal results as well.

 

I didn't see a tweak explained in the post you reference.

[olegpronin]

The reason of mod agpm for 1340 is that igpu agpm doesn't work normal with control I'd 16, it enables agpm but once it moved to high frequency, it never comes back. Changing igpu to control id 17 is enough.

[olegpronin]

bcc9, do you have working sleep on the lid close? Strange, but it doesn't work for me for unknown reason in lion.

[ghatsby]

Hi I have everything working apart from sound on my Dell XPS 1340 (A15, 9400/G210)

 

Mac OS X Lion 10.7 (11A511)

 

16/08/2011 12:38:25.000 kernel: Kext com.apple.driver.AppleHDAController - library kext com.apple.iokit.IOGraphicsFamily not found.

16/08/2011 12:38:25.000 kernel: Can't load kext com.apple.driver.AppleHDAController - failed to resolve library dependencies.

16/08/2011 12:38:25.000 kernel: Kext com.apple.driver.AppleHDAController failed to load (0xdc00800e).

16/08/2011 12:38:25.000 kernel: Failed to load kext com.apple.driver.AppleHDAController (error 0xdc00800e).

16/08/2011 12:38:25.000 kernel: Kext com.apple.driver.AppleHDAController might not load - kextd is currently unavailable.

16/08/2011 12:38:29.000 kernel: Sound assertion ""( kRequestStateMatch == fCodecRequest->state )"" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDAController/AppleHDAController.cpp" at line 3621 goto handler

16/08/2011 12:38:29.000 kernel: Sound assertion "0 != executeCodecCommand ( fCodecList[addr], command, &fCodecVendorProductIDArray[addr] )" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDAController/AppleHDAController.cpp" at line 2967 goto Exit

16/08/2011 12:38:30.000 kernel: Sound assertion ""( kRequestStateMatch == fCodecRequest->state )"" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDAController/AppleHDAController.cpp" at line 3621 goto handler

16/08/2011 12:38:30.000 kernel: Sound assertion "0 != err" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/IOHDAFamily/IOHDACodecDevice.cpp" at line 147 goto Exit

16/08/2011 12:38:35.000 kernel: Sound assertion "0 == codecListArray" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDACodecGeneric.cpp" at line 126 goto Exit

16/08/2011 12:38:35.000 kernel: Sound assertion "0 == codecListArray" failed in "/SourceCache/AppleHDA/AppleHDA-179.1.4/AppleHDA/AppleHDACodecGeneric.cpp" at line 126 goto Exit

[olegpronin]

ghatsby, read some posts back in this thread, bcc9 posted his patch for lion's and 10.6.8 applehda.

[ghatsby]

ghatsby, read some posts back in this thread, bcc9 posted his patch for lion's and 10.6.8 applehda.

 

 

I've used his patch with no joy...

[olegpronin]

I've used his patch with no joy...

 

just wondering, you used this: http://www.insanelymac.com/forum/index.php...t&p=1708300 ?

[bcc9]

bcc9, do you have working sleep on the lid close? Strange, but it doesn't work for me for unknown reason in lion.

It works for me. But you're mixing&matching AppleACPIPlatform across releases, right? Ie you are using a 10.6 version as otherwise you don't have working battery status, right? If so, I'd suspect that's your problem. Have you tried lid close with the 10.7 version?

[olegpronin]

I'm using now 10.7.2 with appleacpiplaform from 10.6.7 patched + appleacpibattery. Lid close - no reaction.

[bcc9]

I'm using now 10.7.2 with appleacpiplaform from 10.6.7 patched + appleacpibattery. Lid close - no reaction.

Right, and so if you use the proper 10.7 version....?

[bcc9]

I've used his patch with no joy...

Meaning what? You didn't explain what you did so we can't tell you what you did wrong.

Did my package installer say it completed successfully?

[olegpronin]

Right, and so if you use the proper 10.7 version....?

 

doesn't work. and doesn't work in 10.6.3 as I tested some minutes ago. I think something wrong in kexts/system/dsdt. will check later.

[bcc9]

So with acpi debugging turned on, I was able to see that under lion, calls to evaluateObject("_BIF", ...) were failing with

"ACPI Error (psparse-0632): Method parse/execution failed"

just like used to happen before I came up with the original edited DSDT:

http://www.insanelymac.com/forum/index.php...t&p=1172606

 

I removed some remaining DSDT warnings (that should have been cosmetic), and that fixed the evaluateObject() calls for the _BIF method.

 

So apparently the 10.7 AppleACPIPlatform is using stricter aml parsing than the 10.6 version.

 

I did wind up making _BIF and _BST static in the process; have to figure out how to clean up UPBI() and UPBS() before this will work right under lion.

[olegpronin]

bcc9, thank you for hard working on new AppleACPIPlatform, I know, you'll find the way! Sad that I can't help with it, don't know how I can help since have no mind about it.

 

UPDATE.

 

bcc9, sorry me for wrong information, there was my bug. Sleep on lid close works with any variation of AppleACPIPlatform kexts. Now works fine with 10.7 + appleacpi from 10.6.7.

[tritonxl34]

bcc9, thank you for hard working on new AppleACPIPlatform, I know, you'll find the way! Sad that I can't help with it, don't know how I can help since have no mind about it.

 

UPDATE.

 

bcc9, sorry me for wrong information, there was my bug. Sleep on lid close works with any variation of AppleACPIPlatform kexts. Now works fine with 10.7 + appleacpi from 10.6.7.

 

I have yet to ever get Sleep/Resume to ever work on either SL or Lion. I have everything else working. What variations of each kexts are you using to get it to work?

[olegpronin]

1736315[/url]']

I have yet to ever get Sleep/Resume to ever work on either SL or Lion. I have everything else working. What variations of each kexts are you using to using it to work?

I understood right that sleep does not work for you? Post here kernel log.

 

• Something seems wrong with the IOAHCISerialATAPI driver. Upon wakeup from suspend the disk activity light flashes every 2 seconds or so apparently with the driver trying to stat the dvd-rom drive. Putting a disk in the drive fixes this.
  

Does it still a problem? I have no this issue.

[bcc9]

I have yet to ever get Sleep/Resume to ever work on either SL or Lion. I have everything else working. What variations of each kexts are you using to get it to work?

If you follow post #1, then sleep works in 10.6 for all releases. Sleep also works in 10.5 &10.7...

[bcc9]

Here is a patched DSDT for lion.

This version fixes the UPBI and UPBS methods for dynamic battery status.

(VoodooBattery now works with this DSDT). There should no longer be any temptation to use a rolled-back version of AppleACPIPlatform. (In general I recommend avoiding mixing&matching of system kexts from different OSX releases, even though hackintosh users often do this. You never know what problems you're introducing with mismatched kexts).

 

I've also removed almost all of the graphics injection strings, as chameleon rc5 has been handling the injection of these for a while now. When I originally wrote the graphics injection strings, chameleon did not have code to dynamically compute NVCAP like it does now. So, be sure to configure <key>GraphicsEnabler</key><string>Yes</string> as well as <key>PCIRootUID</key> <string>1</string> in your com.apple.Boot.plist.

 

Does it still a problem? I have no this issue.

You're right, I'm not seeing the disk-activity light problem after resume from suspend anymore. I wonder when that got fixed...

 

Edit: new version of this dsdt in the 10.7 thread:

http://www.insanelym...howtopic=272546

[olegpronin]

ok, I can confirm, now it works with lion's GPE-patched appleacpiplatform kext + voodoobattery. But I don't like voodoobattery actually - it injects ACAdapter too and mainly the starting of mac is much longer than with AppleACPIBattery kext...

 

Btw, AppleACPIBattery.kext panics at the start or random panics after system startup with patched AppleACPIPlatform from Lion. (but as I understand, it's the problem if AppleACPIBattery kext.)

 

Thanks a lot for fixing DSDT, there genius things were done.

 

update. I found that you added hdmi sound thing, thank you. Anyway I continue to use the voodoohda driver because it has no problems with volume (nvram thing bugs - here the video record what I'm talking about, only Russian interface, but you'll understand all. http://cl.ly/0y0q3L3M3O1t0N2x1D1P ). I still have no idea why AppleHDA has these problems.

[bcc9]

ok, I can confirm, now it works with lion's GPE-patched appleacpiplatform kext + voodoobattery. But I don't like voodoobattery actually - it injects ACAdapter too and mainly the starting of mac is much longer than with AppleACPIBattery kext...

Can you explain? I haven't noticed any startup time differences between using VoodooBattery vs not using anything.

I'm not attached to Voodoobattery, can you point me to the source code for appleacpibattery & the current release, so that I can compare? I couldn't find the source last I checked.

It would be nice if there was a fully working replacement for voodoobattery as I don't like depending upon abandon-ware.

Btw, AppleACPIBattery.kext panics at the start or random panics after system startup with patched AppleACPIPlatform from Lion. (but as I understand, it's the problem if AppleACPIBattery kext.)

So it sounds like VoodooBattery is clearly the way to go at least until someone troubleshoots that.

Thanks a lot for fixing DSDT, there genius things were done.

Thanks, figuring out that the battery status update methods needed to be rewritten to do 8 bit I/O to avoid the "Method parse/execution failed" errors was a key part...

 

update. I found that you added hdmi sound thing, thank you.

hdmi audio won't actually work however, as av-signal-type is failing to be set to 0x8 as required. If someone could figure this final piece out they'd be my hero

Anyway I continue to use the voodoohda driver because it has no problems with volume (nvram thing bugs - here the video record what I'm talking about, only Russian interface, but you'll understand all. http://cl.ly/0y0q3L3M3O1t0N2x1D1P ). I still have no idea why AppleHDA has these problems.

Hmm, I hadn't noticed volume problems with AppleHDA. Sure enough, looks a little buggy. I always just adjust the volume using the dell hotkeys on this laptop which works OK.