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

[tritonxl34]

After updating to 10.7.4 I no longer have working battery detection/lid close detection. At first when trying to use your AppleACPIPlatform patch it would fail, and apparently Pages was trying to open the log file afterwards. I removed iWork and then tried the patch again and it completed successfully, but the log said that it had already seen that it was patched. After restarting nothing has changed.

 

Any thoughts?

[itwong]

@bcc9, has appleacpiplatform.kext been updated in the 10.7.4? I tried to run your acpi patcher 1.8.pkg and it finds no code to patch. The file may have been patched already. Any idea? I did get sound working again using your HDAidt patcher v1.pkg. Only thing not working now is just lid sleep and battery status.

[itwong]

has anyone managed to get working battery status under 10.7.4? If so , please share how you did it. Thank you.

[bcc9]

My AppleACPIPlatform patch needs to be tweaked slightly to handle 10.7.4. I haven't had time to do it yet (nobody else wants to step up here?)

I may have time in a day or so.

I only access this laptop about once a month at this point, so any maintenance I do for this laptop is going to get slower&slower.

[itwong]

My AppleACPIPlatform patch needs to be tweaked slightly to handle 10.7.4. I haven't had time to do it yet (nobody else wants to step up here?)

I may have time in a day or so.

I only access this laptop about once a month at this point, so any maintenance I do for this laptop is going to get slower&slower.

 

Thanks for the quick update on this, bcc9. Waiting is not a problem at all. Looking forward to your new acpiplatform patcher. Take your time and do it at your convenience. ;-)

[bcc9]

Ok, I've updated my AppleACPIPlatform patch package in post #1 to version 2.0 to fix osx 10.7.4 support.

The fix was like I suspected, the patch matching had to be relaxed so as to not be affected by relative addresses that can change between releases. The patch itself is still the same.

I haven't actually tried this myself on the dell laptop (I used my macbook to update the package while on a plane

But since the patch is the same as before I'm not expecting any surprises.

[itwong]

Ok, I've updated my AppleACPIPlatform patch package in post #1 to version 2.0 to fix osx 10.7.4 support.

The fix was like I suspected, the patch matching had to be relaxed so as to not be affected by relative addresses that can change between releases. The patch itself is still the same.

I haven't actually tried this myself on the dell laptop (I used my macbook to update the package while on a plane

But since the patch is the same as before I'm not expecting any surprises.

 

It now patches sucessfully. However, after reboot the battery icon shows but does not detect the status of the battery. I am using VoodooBattery.kext v1.3.3 under /EFI/Extra/Extensions. I can get working status using the same extra folder kexts for snow leopard. I have read elsewhere that the new AppleSmartBatteryManager.kext may conflict with voodoobattery.kext. Try removing it yields the same result. Any idea?

[bcc9]

I assume suspend on lid close works now too.

If voodoobattery is conflicting with standard osx, maybe try one of the alternative battery management kexts.

I don't have access to a 1340 this week so I can't look into it further myself.

[Allak]

Hi,

 

i have a problem with your dsdt-check.pl script. When I try to run it, it says "./showbootermemorymap: command not found".

 

Using your DSDT.aml hangs on "PCI Configuration Begin".

 

Using your DSDT-alt.aml ends with a blank screen.

 

With DSDT-alt and GE=No it works like a charm except the graphics. (Only 1024x768 etc.)

 

I think I have the same problem like Kelobb.

 

System: XPS 1340

P8600

9400m + 210

Bios v. A15

 

What should I do?

 

 

Thanks a lot!

[bcc9]

i have a problem with your dsdt-check.pl script. When I try to run it, it says "./showbootermemorymap: command not found".

What did you use to unpack dsdt.lion.v4.zip? showbootermemorymap is included in the zip file and marked executable:

% zipinfo dsdt.lion.v4.zip |grep showbootermemorymap
-rwxrwxr-x  3.0 unx	 2407 tx defN  9-Dec-11 16:27 showbootermemorymap
% unzip dsdt.lion.v4.zip
Archive:  dsdt.lion.v4.zip
 inflating: alt.dsl				
[text deleted]
 inflating: showbootermemorymap	
% ls -l showbootermemorymap
-rwxrwxr-x@ 1 bcc9  staff  2407 Dec  9 16:27 showbootermemorymap*
%

 

What should I do?

You could post the debug info that kelobb was asked for but kept failing to collect (bdmesg output, ioregistry output, your dsdt).

Or you could go back and troubleshoot IOPCIFamily if you don't want to troubleshoot and just assume that's the problem. You could first try rolling back to the most recent 10.6.x version. Second recompile the 10.7.x kext from source with the pci relocation disabled. Assuming those work, you could narrow down what pci device relocation is not working as expected.

 

I'm assuming you followed post #1 completely. If you instead used a different install method, then I suspect that's your problem.

[Allak]

What did you use to unpack dsdt.lion.v4.zip?

I used the lion standard unzipper.

 

You could post the debug info that kelobb was asked for but kept failing to collect (bdmesg output, ioregistry output, your dsdt).

Look in the attachment.

 

I'm assuming you followed post #1 completely.

 

Yes I did.

debug info.zip

[bcc9]

I used the lion standard unzipper.

As is shown above. So the problem must be with your usage. Open a terminal window and cd into the directory where you have both dsdt-check.pl and showbootermemorymap. Run dsdt-check.pl as shown in the readme. You should run this from your OSX laptop running 10.7.

 

Other possibility is you're missing dtrace (/usr/sbin/dtrace), but that should not be.

 

From your bdmesg log:

No DSDT found, using 0 as uid value.

Using PCI-Root-UID value: 0

nVidia GeForce 9200M GS -4095MB NV1ff [10de:06e8] :: PciRoot(0x0)/Pci(0xc,0x0)/Pci(0x0,0x0) device number: 1

nVidia GeForce 9400M G 256MB NVac [10de:0866] :: PciRoot(0x0)/Pci(0x10,0x0)/Pci(0x0,0x0) device number: 2

 

So you actually have a 9400m+9200m not a 9400m + 210

Others have reported success with this config. Also in the above, you're just showing the case where you're not using a dsdt. If you could send in bdmesg output from when you're using the right DSDT that would be better (you can ssh in to run bdmesg).

[Allak]

As is shown above. So the problem must be with your usage. Open a terminal window and cd into the directory where you have both dsdt-check.pl and showbootermemorymap. Run dsdt-check.pl as shown in the readme. You should run this from your OSX laptop running 10.7.

Thanks, it was my fault. Script is working fine and it says that dsdt-alt is the right one.

 

you can ssh in to run bdmesg

Don't know what that means.

 

If you could send in bdmesg output from when you're using the right DSDT that would be better

I used dsdt-alt.aml NVEnabler64.kext to get graphics to save the bdmesg. I hope that's no problem.

debug info.zip

[bcc9]

So to troubleshoot GraphicsEnabler, you need the bdmesg and ioregistry info from when graphicsenabler is actually in use. You sent in output from 2 cases where it wasn't possible to work right (1 case you had it off, other case the dsdt was stock, and so the PCIRootUID mismatched).

 

ssh is an easy way to login to your machine from another when the GUI interface does not start. You turn on the remote login service via system preferences->sharing->remote login. I suggest you read up on ssh or I'm sure there are other remote management solutions that would work, I just haven't used any myself.

 

If your GUI interface is working fine with a kext injector solution, then it seems that the fix should be easy and you just need to compare what GraphicsEnabler is injecting vs the kext injector.

[Allak]

Login via ssh worked fine.

 

Ioregistry and bdmesg are in the attachment.

 

If your GUI interface is working fine with a kext injector solution, then it seems that the fix should be easy and you just need to compare what GraphicsEnabler is injecting vs the kext injector.

 

NVEnabler64 is working, but I get kp using HDMI.

allak.bdmesg.txt

allak.ioreg.txt

[bcc9]

Allak,

So the problem seems to be that chameleon's GraphicsEnabler is putting AAPL,boot-display on wrong graphics device (the 9200M part not the 9400M part). It's also adding the rest of the injection strings to the 9200M device.

My DSDTs which injected the graphics strings used to leave the 9200M part alone.

I'm not sure what your kext injector is doing as you didn't include ioregistry output from that case.

Regardless, assuming I'm right about the problem, one can fix this by either

1. Changing the vendor_id for the 9200M part so that chameleon doesn't touch it
   
2. Switching back to injecting the graphics strings via the DSDT like I did before instead of using GraphicsEnabler
   
3. Fixing chameleon to prefer to inject graphics strings to the device whose address matches the IGPU device in the DSDT. This would seem to be the best fix but also the most difficult since chameleon doesn't yet have an AML parser built in.
   

In any case, I can make a DSDT with fix #1 in it.

 

Edit: fix #1 doesn't work; fix #2 applied to post #1.

[Allak]

I'm not sure what your kext injector is doing as you didn't include ioregistry output from that case.

Here it is. (Attachment)

 

1. Changing the vendor_id for the 9200M part so that chameleon doesn't touch it

So the 9200M is turned off and won't work anymore, right?

 

3. Fixing chameleon to prefer to inject graphics strings to the device whose address matches the IGPU device in the DSDT. This would seem to be the best fix but also the most difficult since chameleon doesn't yet have an AML parser built in.

What's the advantage of this method?

 

In any case, I can make a DSDT with fix #1 in it.

That would help me a lot.

nvenabler64.ioreg.txt

[bcc9]

So my first idea doesn't work as the device ID is read-only in pci configuration memory (unlike the device subid). I didn't realize this.

If it did work, the 9200m would probably remain powered on, just not initialized (like it has always been under osx).

 

Idea number 3 would be best as then the fix would work for other laptops that have a GPU co-processor as well. I'm not prepared to go to all the trouble of adding proper AML parsing to chameleon.

 

So then, here's solution #2 for you to try. I haven't tested it on a 1340 yet. You would simply boot with this dsdt without graphicsenabler.

 

Regarding nvenabler64.ioreg.txt,

That dump is confusing, it still shows AAPL,boot-display on the wrong device.

But it includes superfluous vbios injection strings, and some errors such as strings whose keys start with "@1," or "@0,".

I suspect you had both GraphicsEnabler running and your kext injector. Not sure since this dump doesn't include bdmesg output.

 

Edit: New DSDT is now found in updated version in post #1. Has been tested with 9400m model of 1340 too.

[Allak]

Wow! It works perfectly!

 

Amazing work. If you have an Paypal account I would spend you some beer for all that work.

 

Thanks!

 

EDIT:

 

Ok first problem:

 

My multimedia keys (play, pause, volume up etc.) don't work anymore.

 

Is it my fault? Just deleted NVEnaber and replaced the old DSDT with the new one.

 

EDIT: Ok strange... Sometimes it works, sometimes not... I'm going to observe this

[bcc9]

Wow! It works perfectly!

 

Amazing work. If you have an Paypal account I would spend you some beer for all that work.

Thanks. Basically I just rolled back the config to the way I had it pre-10.7, giving up on GraphicsEnabler doing the right thing for 2 GPU chip machines.

If one started accepting money for this stuff that'd put one in similar legal grey area as Psystar (and we all know how well that worked out for them).

EDIT: Ok strange... Sometimes it works, sometimes not... I'm going to observe this

Not sure about this. Sometimes it seems like the ACPI events get queued up/backlogged. voodoobattery problem perhaps...

[Allak]

Another question: Is it possible to get my WWAN card running? (It's not recognized on Mac OSX)

[bcc9]

Another question: Is it possible to get my WWAN card running? (It's not recognized on Mac OSX)

I don't know, it would depend upon the model I should think. I have no experience with WWAN cards.

[itwong]

I don't know, it would depend upon the model I should think. I have no experience with WWAN cards.

 

Have you got a chance to look at the battery kext for 10.7.4?

[bcc9]

Have you got a chance to look at the battery kext for 10.7.4?

No, still not on 10.7.4 on the 1340 I borrow. Any details on the claimed AppleSmartBatteryManager confliclt?

[kelobb]

Hello,

 

Thx Alllak for debugging my issue, I had to suspend my 1340 fights for some time.

I suppose that latest bcc9' dsdt will work with my hardware too.

 

Thx to our guru bcc9, which is working hard!

 

So we will wait for 10.8 thread?