Jump to content

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

* * * * * 3 votes

  • Please log in to reply
290 replies to this topic

#81
piarullir

piarullir

    InsanelyMac Protégé

  • Members
  • Pip
  • 24 posts
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?

#82
mikeraffone

mikeraffone

    InsanelyMac Protégé

  • Members
  • Pip
  • 22 posts
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 by mikeraffone, 15 March 2012 - 11:26 PM.


#83
LatinMcG

LatinMcG

    Insanely digesting DSDT

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 2,509 posts
  • Gender:Male
  • Location:Tampa, Florida
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

#84
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,278 posts
  • Gender:Male

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.

#85
LatinMcG

LatinMcG

    Insanely digesting DSDT

  • Members
  • PipPipPipPipPipPipPipPipPipPipPip
  • 2,509 posts
  • Gender:Male
  • Location:Tampa, Florida
my 1520 has ricoh card reader i believe.. so it might be viable

#86
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,278 posts
  • Gender:Male

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

#87
kelobb

kelobb

    InsanelyMac Protégé

  • Members
  • Pip
  • 33 posts
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

#88
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,278 posts
  • Gender:Male

Any Ideas

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

#89
kelobb

kelobb

    InsanelyMac Protégé

  • Members
  • Pip
  • 33 posts
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?

#90
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,278 posts
  • Gender:Male

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

#91
kelobb

kelobb

    InsanelyMac Protégé

  • Members
  • Pip
  • 33 posts
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,

#92
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,278 posts
  • Gender:Male

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.

#93
kelobb

kelobb

    InsanelyMac Protégé

  • Members
  • Pip
  • 33 posts
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".

#94
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,278 posts
  • Gender:Male

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

#95
kelobb

kelobb

    InsanelyMac Protégé

  • Members
  • Pip
  • 33 posts
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

#96
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,278 posts
  • Gender:Male
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.

#97
kelobb

kelobb

    InsanelyMac Protégé

  • Members
  • Pip
  • 33 posts
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?

#98
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,278 posts
  • Gender:Male
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)
%


#99
kelobb

kelobb

    InsanelyMac Protégé

  • Members
  • Pip
  • 33 posts
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?

#100
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,278 posts
  • Gender:Male
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.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy