250 replies to this topic

[bcc9]

BWR, on 08 November 2012 - 09:57 AM, said:

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   486.13K   2 downloads

[bcc9]

BWR, on 14 November 2012 - 10:16 AM, said:

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]

BWR, on 29 November 2012 - 05:24 AM, said:

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]

mikeraffone, on 09 December 2012 - 03:42 AM, said:

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.insanelym...-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..

Attached Files

•  ioreg.txt   27.45K   1 downloads

[bcc9]

rameshb_v, on 12 December 2012 - 06:14 PM, said:

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]

bcc9, on 13 December 2012 - 10:55 PM, said:

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]

rameshb_v, on 15 December 2012 - 06:53 AM, said:

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]

bcc9, on 15 December 2012 - 06:40 PM, said:

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]

rameshb_v, on 16 December 2012 - 12:31 AM, said:

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]

bcc9, on 16 December 2012 - 03:41 AM, said:

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.

Attached Files

•  ioreg.txt   55.36K   0 downloads

[bcc9]

rameshb_v, on 17 December 2012 - 06:33 AM, said:

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]

bcc9, on 18 December 2012 - 06:57 AM, said:

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]

rameshb_v, on 18 December 2012 - 03:54 PM, said:

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.

rameshb_v, on 18 December 2012 - 03:54 PM, said:

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.insanelym...00#entry1734100