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

[olegpronin]

Hi, I replaced the boot file and was able to login Factime but now i get a message at boot and reboot

/extra/com.apple.boot.plist is depreciated what does that mean? it still boot and i can still use it, but like to get rid of that message.

 

thanks

 

peelers

rename com.apple.boot.plist to org.chameleon.boot.plist

[olegpronin]

I was very very wrong.

 

I tried your patch, The king, I don't know actually what it does, but I heard that apple reads all by name, so subsystem is ok, I'll save that patch for myself.

And I added method to _WAK - looks like it save injector data after resume (will test).

 

I missed only that thing:

 

<key>SensorOption</key>
					<integer>1</integer>
					<key>SensorSampleRate</key>
					<integer>4</integer>
					<key>TargetCount</key>
					<integer>1</integer>

 

this needs to have it all working.. My mistake I left it.

 

But I think I have another problem. It never changes to 2 or 3 states in control-id 16 (I'm using lion 10.7.2 11c43).

Sep  2 20:29:45 localhost kernel[0]: AGPM: GPU = IGPU Initialized, Control ID 16
Sep  2 20:29:48 GFKxx kernel[0]: AGPM: GPU = IGPU G-state set to 1 from 3, ControlID = 16
Sep  2 20:29:49 GFKxx kernel[0]: AGPM: GPU = IGPU G-state set to 0 from 1, ControlID = 16
Sep  2 20:29:56 gfkxx kernel[0]: AGPM: GPU = IGPU G-state set to 1 from 0, ControlID = 16
Sep  2 20:32:22 gfkxx kernel[0]: AGPM: GPU = IGPU G-state set to 0 from 1, ControlID = 16
Sep  2 20:32:26 gfkxx kernel[0]: AGPM: GPU = IGPU G-state set to 1 from 0, ControlID = 16
Sep  2 20:32:30 gfkxx kernel[0]: AGPM: GPU = IGPU G-state set to 0 from 1, ControlID = 16
Sep  2 20:32:33 gfkxx kernel[0]: AGPM: GPU = IGPU G-state set to 1 from 0, ControlID = 16

 

UPDATE

And here more VERY INTERESTING information, and thanks to the king because I didn't see that - the states 2 and 3 are going to be activated only when battery is going on without AC adapter. So, all work with id 16 as we wanted.

 

Thanks to all!

9400m_gstate_inject.kext.zip

[bcc9]

Seems my DSDT tricks does a better job then AGPM replacement in Injector.kext, so i cleaned that section, look why:

Reference? If there is a patch for our dsdt that would achieve the same power savings result as injecting custom AGPM, a dsdt edit would be preferable.

 

 

 

Speaking of power, I've also noticed that when bluetooth is active, the power usage increases by about 5 watts. The catch is it never drops down when bluetooth should be idle. Under windows, the increase is the same but goes back down after ~30 seconds when my bluetooth mouse is idle.

[THe KiNG]

Reference? If there is a patch for our dsdt that would achieve the same power savings result as injecting custom AGPM, a dsdt edit would be preferable.

 

Reference HERE

Latest version, not commented since was not much interest in develop then download, HERE

 

The trick is in HACK Method:

    Method (HACK, 0, NotSerialized)
   {
       Store (Zero, \_SB.PCI0.IMAP.EMTY) // IMAP No Subsystem & No Device ID hack
       Store (Zero, \_SB.PCI0.P4MI.EMTY) // P4MI No Subsystem & No Device ID hack
       Store (0x00B9106B, \_SB.PCI0.IXVE.IGPU.ASDI) // IGPU Apple Subsystem & Device ID hack
       Store (0x000010DE, \_SB.PCI0.IXVE.NDID) // IXVE nVidia Subsystem & No Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.SBUS.NVID) // SBUS nVidia Subsystem & Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.NVPM.NVID) // NVPM nVidia Subsystem & Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.OHC1.NVID) // OHC1 nVidia Subsystem & Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.EHC1.NVID) // EHC1 nVidia Subsystem & Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.OHC2.NVID) // OHC2 nVidia Subsystem & Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.EHC2.NVID) // EHC2 nVidia Subsystem & Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.HDEF.NVID) // HDEF nVidia Subsystem & Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.GIGE.NVID) // GIGE nVidia Subsystem & Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.SATA.NVID) // SATA nVidia Subsystem & Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.LPCB.NVID) // LPCB nVidia Subsystem & Device ID hack
       Store (0xCB7910DE, \_SB.PCI0.PCIB.NVID) // PCIB nVidia Subsystem & Device ID hack
       Store (Zero, \_SB.PCI0.PCIB.PCMD) // PCIB Disable Bus Master
       Store (Zero, \_SB.PCI0.GIGE.MSIE) // GIGE Enable MSI
   }

 

Have fun!

 

P.S. How du you measure the power, hardware tool or some software?

[bcc9]

Reference HERE

Latest version, not commented since was not much interest in develop then download, HERE

Interesting, thanks. Looks like it'll take some time to figure out what parts might be necessary&sufficient to affect AGPM on the 1340.

P.S. How du you measure the power, hardware tool or some software?

http://www.amazon.com/P3-International-P44.../dp/B00009MDBU/

Those things are dirt cheap these days. Some review sites even use them for measuring cpu&gpu TDP on desktop systems.

[olegpronin]

There one my friend clubber watched for us the applehda sound for fixing volume bugs and mic things.

 

We tested a lot of different builds. There no volume bug fixed on the speaker.

 

But he did some additional things for internal mic like noise-deletion and changing the sensitivity.

 

There the line in mic input was added too (in the autodetect with internal mic), but for strange reason it works here only with earphones, but not with mic. Please, bcc9, test it and may be you can find how fix that.

 

I attatched modified kexts (10.7).

10.7_olegfixed_a_little.zip

[bcc9]

There the line in mic input was added too (in the autodetect with internal mic), but for strange reason it works here only with earphones, but not with mic. Please, bcc9, test it and may be you can find how fix that.

I never got the line-in mic working under osx with applehda, only under linux. I spent hours debugging it already and gave up long ago. I had a bunch of posts about this back in 2009.

[olegpronin]

I never got the line-in mic working under osx with applehda, only under linux. I spent hours debugging it already and gave up long ago. I had a bunch of posts about this back in 2009.

 

ok, do you know why it works when I insert the earphones to it?? I can't understand.

 

There for internal mic something was added too in kext

[bcc9]

ok, do you know why it works when I insert the earphones to it?? I can't understand.

What works?

[olegpronin]

What works?

 

Repeating again. I have only one mic at home, may be it doesnt work.

 

The changes in working internal mic around the cam - sensivity changes, noise-deletiong added.

When you insert the mic to mic jack in the panel, it autodetects it, but no signal.

If you insert the earphones to this MIC jack, it works like a mic without problems. I don't know why.

 

Please check with your mic, may be my mic doesn't work.

 

UPDATE. bcc9, download it to yourself and check please.

[bcc9]

But I think I have another problem. It never changes to 2 or 3 states in control-id 16 (I'm using lion 10.7.2 11c43).

Sep  2 20:29:45 localhost kernel[0]: AGPM: GPU = IGPU Initialized, Control ID 16
Sep  2 20:29:48 GFKxx kernel[0]: AGPM: GPU = IGPU G-state set to 1 from 3, ControlID = 16
Sep  2 20:29:49 GFKxx kernel[0]: AGPM: GPU = IGPU G-state set to 0 from 1, ControlID = 16
Sep  2 20:29:56 gfkxx kernel[0]: AGPM: GPU = IGPU G-state set to 1 from 0, ControlID = 16
Sep  2 20:32:22 gfkxx kernel[0]: AGPM: GPU = IGPU G-state set to 0 from 1, ControlID = 16
Sep  2 20:32:26 gfkxx kernel[0]: AGPM: GPU = IGPU G-state set to 1 from 0, ControlID = 16
Sep  2 20:32:30 gfkxx kernel[0]: AGPM: GPU = IGPU G-state set to 0 from 1, ControlID = 16
Sep  2 20:32:33 gfkxx kernel[0]: AGPM: GPU = IGPU G-state set to 1 from 0, ControlID = 16

 

UPDATE

And here more VERY INTERESTING information, and thanks to the king because I didn't see that - the states 2 and 3 are going to be activated only when battery is going on without AC adapter. So, all work with id 16 as we wanted.

 

Thanks to all!

When you change the control-id back to 16, the system no longer achieves g-state 3 when idle, with or without ac adapter, thus negating the effect of injecting anything. That is, unless I'm missing some other piece, which I probably am since you seem to be responding to a private conversation...

I did try king's dsdt hack to spoof pci subsystem IDs, and those work, but seem to have no effect on anything (including AGPM).

 

 

 

Please check with your mic, may be my mic doesn't work.

 

UPDATE. bcc9, download it to yourself and check please.

You could test your mic under windows and then you'd know if you have a valid test set up. I don't want to waste more time on this unless you have a working fix, as I don't even have a use for an external mic at this time.

[SubMedia]

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.

Hi bbc9. Thanks for your great work.

My laptop is Packard Bell EasyNote TM85. Can you explain me, how to patch my DSDT?

 

I was trying to apply your patched.dsl file for my dsdt.aml using DSDT Editor, but no success (a lot of errors while compiling), and I simply put patched dsdt.aml into /Extra folder, it invokes kernel panic.

 

I understood, that I should replace some sections in my dsdt.aml with one from your patched.dsl, but I don't know what sections must be changed. Please look at my DSDT (attached below).

dsdt.aml.zip

I would appreciate your help so much.

Sorry for my English

[bcc9]

Hi bbc9. Thanks for your great work.

My laptop is Packard Bell EasyNote TM85. Can you explain me, how to patch my DSDT?

You can't use DSDTs from unrelated hardware.

To get started, try reading some of the hackintosh dsdt editing guides.

[SubMedia]

You can't use DSDTs from unrelated hardware.

To get started, try reading some of the hackintosh dsdt editing guides.

OK. I know. So I use DSDT Patcher to create dsdt.aml for my hardware.

I tried add to dsdt the whole section Scope (\_SB.PCI0.LPC) and separately Methods UPBI, UPBS from patched.dsl, but nothing works. It's a pity.

[bcc9]

OK. I know. So I use DSDT Patcher to create dsdt.aml for my hardware.

I tried add to dsdt the whole section Scope (\_SB.PCI0.LPC) and separately Methods UPBI, UPBS from patched.dsl, but nothing works. It's a pity.

You didn't start by saying you were merely asking about editing your DSDT's battery information for OSX 10.7 support. We were lately discussing AGPM related DSDT editing changes, so how would I know? Garbage in, garbage out...

 

I explained how to correct the battery methods in earlier posts.

If you look at your _BIF and _BST methods in your DSDT they are referencing 16 bit fields within the embedded controller's memory space. You have to edit the DSDT to make those references be 8 bit at a time.

 

Again, I don't have time to do these edits for other platforms so please stop asking me to look into DSDTs for those platforms.

[SubMedia]

I understood, how to get started.

Thanks a lot for help.

[bcc9]

I understood, how to get started.

Thanks a lot for help.

I did already answer the how to get started part.

If the existing guides don't make sense to you you'd be better off finding someone who has DSDT editing experience and your model of laptop, and work with them.

[lennyG]

With a 1 off report with no debugging there was nothing to go on, but it sounds like there is an issue for some users. Still not clear if A/B comparisons have been done. In other words, are you sure that these other issues don't occur independent of the npci setting?

 

Perhaps everything is fine unless one has 2 integrated graphics devices (such as the 9400M + 9200M=9500M combo?)

I have the 9400M only model of the 1340.

 

Wait, you guys who are having problems aren't even using dell xps 1340s are you? Your pci memory layout is likely quite different.

 

I found my 1340 w/ 9500m hangs on PCI configuration begins updating to 10.6.8/Lion from 10.6.7

npci=0x2000 didn't work for sure.

 

I googled and found this:

http://www.projectosx.com/forum/index.php?...1647&st=327

 

Is this relevant to 9500m case too? I am afraid this is the only clue we might have.. since I am a total noob to make DSDT and compile anything..

 

Please let me know anything about this.. I am ready to do anything!

[bcc9]

I found my 1340 w/ 9500m hangs on PCI configuration begins updating to 10.6.8/Lion from 10.6.7

npci=0x2000 didn't work for sure.

Do you really mean hang or just that your text mode output stopped after the configuration begin message? npci=0x2000 is only to address the later. The former may happen for many different reasons, such as failure to load fakesmc, or problems with your system UUID, and you'd have to debug that.

[lennyG]

Do you really mean hang or just that your text mode output stopped after the configuration begin message? npci=0x2000 is only to address the later. The former may happen for many different reasons, such as failure to load fakesmc, or problems with your system UUID, and you'd have to debug that.

 

Thank you for your kind answer, bcc9.

 

It really means "hang". I don't see and hear any HDD activity.

 

I followed this guide for lion:

http://www.insanelymac.com/forum/index.php?showtopic=256729

for 10.6.8, I just upgraded online and had no problem with 10.6.0-7 which I've been using with your guide.

I installed the latest chameleon before each update.

In both cases, they showed the same result.

 

How do I debug those? I am sorry I never had this big issue with my 1340

[bcc9]

History: About a month ago, I updated OS X from 10.6.4 to 10.6.7 on my Dell Studio XPS 1340 without any problems (ran the patches for sound and battery icon, etc). Everything was good.

 

Today, however, I downloaded and installed the 10.6.8 update, only for my computer to hang at the Apple Logo boot screen when it rebooted.

 

I left it waiting for 30 minutes, nothing happens: it just gets stuck at the Apple Logo boot screen (when I try booting OS X again).

 

Any help is highly appreciated

 

Edit: booted via verbose mode.. hangs on [ PCI Configuration begin ]

I can't replicate any such problems booting 10.6.8 on the 1340, even without setting SystemId in your com.apple.Boot.plist.

As of 10.7, you should have a SystemId defined as the 1340 doesn't have a UUID defined in its SMBIOS and booting hangs for a minute or so without it.

 

You guys need to do some more troubleshooting. Such as:

Enable some verbose debug output (debug=0xxx kernel flag)

Remove kexts which may be hanging (such as the graphics framebuffer kext NVDAResman, etc)

Try a newer version of chameleon (what version are you using anyways?)

Boot with Wait=yes and look for problems there

 

I only have my 1340 around part time these days (I've upgraded to a macbook air) so don't expect so much support from me on 1340 specific problems going forward.

[bcc9]

This source indicates that if OS X 10.6.8 stalls in verbose mode on [ PCI configuration begin ], installing the IOPCIFamily FIX available in [url=&quot;http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/&quot;]#####[/url] 3.8.0 resolves said issue.

 

Only problem: OS X doesn't boot. :/

Doesn't sound applicable. Not sure what they mean by "the" IOPCIFamily fix. There are many reasons the system can appear to hang after printing "PCI configuration begin", there is no global magic fix.

[Buster85]

Doesn't sound applicable. Not sure what they mean by "the" IOPCIFamily fix. There are many reasons the system can appear to hang after printing "PCI configuration begin", there is no global magic fix.

 

I have the same problem, updated to 10.6.8 from 10.6.4 with the boundle and now I can't boot OS/X. I have Win7 and Linux here, but none of them have write access to the OSx partition as far as I can see, so any idea how to get this to boot? Cheers all.

[bcc9]

I have the same problem, updated to 10.6.8 from 10.6.4 with the boundle and now I can't boot OS/X. I have Win7 and Linux here, but none of them have write access to the OSx partition as far as I can see, so any idea how to get this to boot? Cheers all.

Works fine for me. For others, some troubleshooting is in order:

 

Turn on some logging when booting with -v (I assume you guys are using npci=0x2000 as well).

Make sure your kext cache is built correctly.

See if you can at least boot single user mode.

Try booting without the framebuffer kext.

If you still can't figure out which kext the system is hanging on, you can enable the system to panic when the power button is pressed, and check the tracebacks to see what the system was doing at the time.

[Buster85]

Works fine for me. For others, some troubleshooting is in order:

 

Turn on some logging when booting with -v (I assume you guys are using npci=0x2000 as well).

Make sure your kext cache is built correctly.

See if you can at least boot single user mode.

Try booting without the framebuffer kext.

If you still can't figure out which kext the system is hanging on, you can enable the system to panic when the power button is pressed, and check the tracebacks to see what the system was doing at the time.

 

I'm using chameleon to boot,and single user didn't work...will try with verbose now. I'm also downloading a 10.7 dvd to try and recover it if nothing else works.