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

[rameshb_v]

You're welcome.

So first, what error were you getting from the perl script?

Injector kexts just add/modify values in the ioregistry, they are not drivers that remain running while the system is up.

I'm not totally sure what you mean by not on, have you tried the mDNSResponder fix I mentioned a few posts back?

To boot without verbosity, remove the -v from Kernel Flags in the org.chameleon.Boot.plist

Error was something like "Unknown symbol _mh_execute_header"..

I did not try the mDNSResponder fix as my issue is different where the wireless does not turn on. Even if i try to turn on, it wont and the wifi light is off. Next time when i get the issue, I will try the fix.

[bcc9]

Error was something like "Unknown symbol _mh_execute_header"..

I did not try the mDNSResponder fix as my issue is different where the wireless does not turn on. Even if i try to turn on, it wont and the wifi light is off. Next time when i get the issue, I will try the fix.

 

Well of course you have to turn the wifi hardware on before it can be used by the OS. If the wifi light is not on then the hardware is not on. Turn it on via the keyboard hotkey.

[rameshb_v]

Well of course you have to turn the wifi hardware on before it can be used by the OS. If the wifi light is not on then the hardware is not on. Turn it on via the keyboard hotkey.

I turned it on with the hotkey but it turn's off again immediately. I had to restart the machine to bring it back.

[dmullaney]

Wow, this is a brilliant guide. I managed to pick up a broken XPS 1340 for nearly nothing, and now after just a new HD, new RAM and replacement fan, I'm rocking an fast, good looking Lion machine!!

 

The only thing that I haven't been able to get working is the Audio. I'm running 10.7.3, installed exactly by the guide and then updated with combo updater. I ran the ACPI and HDA patch mpkgs after the 10.7.3 update.

 

Anyone got any ideas about how to troubleshoot this??

 

Do'h - So it looks like this was entirely my fault :-) I had flashed a later version of Chameleon assuming it would have the right fixes in it - soon as I reverted to the version linked in the post #1 - all fixed. Apologies for polluting the thread with my ignorance :-)

Edited February 4, 2012 by dmullaney

[bcc9]

I just got around to trying the 10.7.3 update on my old 1340.

 

This update is easy in that my AppleHDA patch from post #1 is the only one that must be re-applied after updating.

AppleRTC and AppleACPIPlatform remain untouched from 10.7.2 even with the combo update.

 

You may also want to re-apply the firewire workaround from post #2 as AppleFWOHCI is reinstalled with the update.

 

If there's some regression with the current version of chameleon, please report it to the chameleon folks.

[piarullir]

Thank you guys, my xps is a fully working mac!

 

A question: My Bluetooth is working fine (the small bluetooth led is active), but when i resume from sleep it doesn't work! (the bluetooth led is now disabled). Any idea?

[mikeraffone]

Hi all,

After updating to 10.7.3 (from 10.7.2) my graphics through the HDMI out flickers and judders. It's pretty unusable.

 

I see that the following files have been updated in the new version:

System.kext

IOPCIFamily.kext

IONDRVSupport.kext

IOGraphicsFamily.kext

 

I'm going to try downgrading those kexts (except System.kext) to 10.7.2 versions and let you know how I go.

 

But, bcc9 (or anyone else) would you have a more elegant solution than just using old versions of kexts?

 

Is this a problem you're having as well?

 

Cheers,

Mikeraffone

 

EDIT: I should say I'm running the XPS1340 version with g210m and onboard 9400m. The g210m isn't functioning or recognised. Instead of using graphicsenabler=yes (which couldn't handle two cards at once and kernel panicked) I have taken the DSDT injection from bcc9's 10.6 solution and implemented them in my 10.7 DSDT. So as it is, the 9400m was working perfectly under 10.7.2 - but now it's like there is a problem with the frame buffer or something.

 

EDIT: GROAN! After a little too-ing and fro-ing I realised what it was. Nothing to do with the system kexts at all. The Display Settings had defaulted to 1080i for some reason, instead of 1080p - which my monitor needs. It was as simple as changing settings in System Preferences. Please ignore me.

Edited March 15, 2012 by mikeraffone

[LatinMcG]

by the way bcc have u tried to fix firewire with the power conservation disabled fix ? add to the scope _GPE and _PRW to the device

[bcc9]

by the way bcc have u tried to fix firewire with the power conservation disabled fix ? add to the scope _GPE and _PRW to the device

A long time ago I tried a bunch of power management related tweaks to no avail. Most advice concerning firewire is not applicable here as the firewire is not via a discrete card, it is integrated into the ricoh controller that includes the sd card slot. If someone has the ricoh controller working properly with osx, maybe the firewire port would stop failing to wakeup too. Even that idea was mentioned in the last 1340 thread.

If you have a change that is known to fix ricoh firewire I'd like to know the specifics. One could spend all day trying to guess what power state config might work.

[LatinMcG]

my 1520 has ricoh card reader i believe.. so it might be viable

[bcc9]

my 1520 has ricoh card reader i believe.. so it might be viable

So again if someone has a specific solution to share that'd be nice. I tried a whole set of different dsdt changes, including a _PRW method for the pci id of the ricoh controller, injection strings such as "built-in", "fwhub"...

[kelobb]

Hello folks,

Bcc9 - I have a weird problem:

 

my fresh lion install doesn't recognize 9400M card, software renderer (with GE=yes) or blank screen.

However I remembered that with SL I could see QE/CI with the same hardware.

I use dsdt-alt.

Maybe EFI strings or modyfing dsdt or iopciprimary.kext?

 

Any Ideas

[bcc9]

Any Ideas

Verify whether or not you really have GraphicsEnabler injecting the proper strings (check bdmesg output, check for the injection strings with ioreg).

[kelobb]

Chameleon correctly recognizes Geforce 210M & 9400GM, but my display goes blank before graphic mode in osx (system is running ok, i can blindly shutdown etc).

Maybe there is some problems recognizing dsdt strings of lcd, svd, or crt devices?

I'll try 10.6 install with old dsdt (a14) from 10.6 thread to see if this works correctly (1 year ago was).

 

Thanx

Could You can analyze log or ioreg output to help? which one?

 

(Edit) SL and a14 dsdt works fine, is there any chance of modify a14dsdt from SL to Lion (pci stops error) that my nvidia card will be recognized?

[bcc9]

(Edit) SL and a14 dsdt works fine, is there any chance of modify a14dsdt from SL to Lion (pci stops error) that my nvidia card will be recognized?

Sounds llike you're missing <key>GraphicsEnabler</key> <string>Yes</string> in your org.chameleon.Boot.plist

 

You can statically put back those injection strings into the new dsdt instead of using GraphicsEnabler, but that would be a messier config.

[kelobb]

hmm injecting efistrings, PCIUID=1 - nothing works with your dsdt-alt - resolution is 1024x768 no kext loaded.

But with EvilIOPCI and EVILACPI kexts and your a14 dsdt (from 10.6) my graphics card is working normally with full QE/CI

 

Trying to investigate why this dsdt is broken for my laptop revision, but I haven't your knowledge bcc9, any help

With EvilIO kexts I cannot have battery stats. etc.

 

Anyway thanks,

[bcc9]

hmm injecting efistrings, PCIUID=1 - nothing works with your dsdt-alt - resolution is 1024x768 no kext loaded.

bdmesg output? ioreg output?

 

Basically it seems you just need to figure out what you're doing that is different than what is in post #1 which is working for everyone else.

Shouldn't be hard to get the debug details since your system isn't hanging or anything like that.

[kelobb]

bcc9,

I've set up a lot of machines for OSX (from 10.5 to 10.7), so this one is weird enough this time. Seems that your DSDT edits have interefenced with my dells revision (a15 bios). What was your DSDT's edits to pass "pci stop error" with a14 or DSDT-alt version? Some _BBN or UID orders? I guess - I don't know DSDT low level "language".

[bcc9]

bcc9,

I've set up a lot of machines for OSX (from 10.5 to 10.7), so this one is weird enough this time. Seems that your DSDT edits have interefenced with my dells revision (a15 bios). What was your DSDT's edits to pass "pci stop error" with a14 or DSDT-alt version? Some _BBN or UID orders? I guess - I don't know DSDT low level "language".

It sounds like you didn't look at my dsdt readme.txt?

I pointed out on line 1: "A14/A15 BIOS DSDT (they have identical DSDTs)".

 

There is no actual dsdt edit to avoid any of the several reasons why one's machine might hang after displaying "PCI Configuration Begin". You were originally reporting that your system comes up so there was no reason to suspect this issue. But your latest post makes it sound like you were having this issue.

 

In any case, for 10.7, on this platform, the most recent reason for hanging at "PCI Configuration Begin" was that with 10.7, the OS is depending upon the ACPI memory region addresses in the dsdt. Again the readme directs one on how to select a dsdt with the right addresses for your machine. Did you run the dsdt-check.pl script per the instructions? It seems like you didn't.

 

I did split all my dsdt changes into individually described patches; not much more I can do for the 99% of users who aren't going to learn ASL (ACPI source language).

[kelobb]

Bcc9, trust me, I'm not an noob, I carefully read your posts and docs.

My machine's behavior is something different,

First of all, your dsdt-check.pl points me to alt version of your dsdt. OK.

But with this settings my graphics card is not recognized (with GE=no, correcty no strings then), but with GE=Yes its blanking screen (rest of all working ok). So where is the problem? My thoughts is DSDT - with oldest A14 10.6 (strange is that pci0 root ID pointing to 1 not 0) system is running perfectly, but with modified IO an ACPI kexts, beacuse of no fix in that a14dsdt.

So I have one ask to modify that a14 dsdt to 10.7 IOPCI kext needs.

Maybe my laptop revision and hardware is something different that yours, thats all. Do you need clear DSDT (from ubuntu or windows) from my machine?

Anyway thanks for discussion

[bcc9]

bdmesg output will show you whether the correct PCI root uuid was selected. If chameleon isn't able to pick up the right value, GraphicsEnabler will fail.

bdmesg output will also show you more generally whether the GraphicsEnabler option was performed.

ioreg output, specifically just the subtree under IXVE@10, will show whether the correct graphics injection strings were injected into the io registry (see especially the NVCAP injection string).

A DSDT dump would verify whether your machine exactly matches the primary or alternate dsdt from post #1, eliminating any need to speculate on dsdt differences. You can compare your dumped dsdt.aml with the two untouched amls from post #1. No need to decompile the aml even to do that.

Accessing the DSDT from linux (/sys/firmware/acpi/tables/DSDT) is probably the easiest for users that have linux installed.

 

Since your machine apparently worked ok with 10.6, it's very likely that you're just running into a simple misconfig situation.

 

I don't mean to be an !#%, but, lacking troubleshooting information, there is little more to do besides continue to speculate.

Normally an experienced user would provide a bug report that would include detailed dumps of the information asked for (3 times now for much of it), and or other detailed info from which one's problem can be reproduced. Lacking that, you have an unreproducible problem that can remain a mystery if you wish.

[kelobb]

Thanks for response, my investigation so far gives me very stange response.

I have 2 configurations - say "A" with old a14.dsdt and "B" with lion.dsdt-alt - both running with EvilIOPCI and EvilACPI kexts.

"A" configuration gives QE/CI and right internal LCD display with correct resolution.

"B" configuration gives blank black screen, and if I access XPS from another comp thru VNC I see that "no display detected" and only standard resolutions (4:3 etc).

Running IOREG app gives the same results (visually) on registry keys NVCAPS are the same.

In system profiler one thing is different - order of Monitor and Geforce card in "graphic cards/monitors" - doesnt't matter or...?

Injection of EFI strings doesn't help to configuration "B" - still no "display".

 

From my experience - the strings were hit "empty" place where do nothing.

Why?

 

One thing extra:

putting NVenabler64 kext to configuration "B" gives correct resolution, unknown card with 256MB mem, but random KP, and no DP output. So inoperative.

Two:

Maybe GraphicsEnabler=Y and your dsdt-alt incorrectly recognize secondary GF210 card id, and switch order?

 

Which check should be most important - which module gives hooks on connectors of nvidia display? how to debug?

[bcc9]

I don't know what "EvilIOPCI and EvilACPI kexts." means, but it sounds like you're not following post #1 instructions.

I'm also still not seeing bdmesg output, which seems likely to be relevant here. Example output showing GraphicsEnabler working:

% bdmesg | grep -1 UID
Read HFS+ file: [hd(0,2)/Extra/DSDT.aml] 34646 bytes.
Using PCI-Root-UID value: 0
nVidia GeForce 9400M G 256MB NVac [10de:0866] :: PciRoot(0x0)/Pci(0x10,0x0)/Pci(0x0,0x0)
%

[kelobb]

Ok, I'll explain why I'm not showing any output from bdmesg.

1. My first try. Grabbed your kexts, DSDT etc. Applying dsdt script - shows alt version. Correctly set up install and post install Lion... and no Display (using latest Chimera, or Chameleon builds). Blank screen. With GE=Yes.

bdmesg correctly identify both cards 9400M and GF210M.

2. Tried to mix different options PCIrood uid 1 or 0. Nothing changed. Stack at GE=No, and no QE/CI of course.

 

Secondart attempt:

Use your old dsdt from SL thread. But it stops at "PCI configuration begin" and halted OS. So I read some info from other forums, why it stops, and apply some fixes - Different IOPCIFamily kexts (from 10.6) or Evil kexts (EvilIOPCIfamily and EvilAppleACPI...kext) and..... with evil ones my Graphics card which is injected into dsdt working with QE/CI - very stable.

(PCI-root-uid=1) and only one graphic card recognized in profiler.

 

So I tried to inject 10.6 strings to DSDT-alt version, or simply put EFI strings at org.cham...plist - and nothing...

 

OK, I can put bdmesg log, but it's OK, the problem is in DSDT, I suppose.

 

Maybe the key is to disable secondary (hybrid) card GF210?

[bcc9]

If the bdmesg output shows graphics enabler working, then compare your ioregistry output for the IGPU@0 subtree between the working case and the failing case. If the injection strings match up but the nvidia kexts are mysteriously not loading, then make sure that those kexts are manually loadable. If so, then you can turn on iokit logging to log the kext matching.