As I already said, your video card is not listed because it is not part of the motherboard (If your board had integrated video there would be code for it in the DSDT). There is code for your PCI bridge and -slots and that's where you place the code for the video card (and other devices like Audio and LAN) if you want to inject it via DSDT. I wouldn't worry about it though, unless you have a really special case there is no benefit or advantage to injecting your video card via DSDT, you might as well use NVEnabler.kext, Device Properties string, or GraphicsEnabler = Yes in /Extra/com.apple.Boot.plist if you're using Chameleon 2.0.
I extracted my DSDT.dsl file on windows XP and i repaired warnings with help of "DSDT Fixes" box. I have now no error, and i'd like to inject some DSDT Hacks for my CPU....but my hardware is not listed (Video card, Lan Ethernet....etc).
The only "pluggable" hardware devices that are listed in your DSDT are the serial port, floppy drive controller, SATA controller, JMicron controller, PS2 keyboard and mouse ports and the USB ports. Then the LPC bridge and its various subdevices (HPET, real time clock etc etc) and the PCI bridge and the PCI slots. LAN and sound don't have any dedicated code in your DSDT, just like mine. You will have to add it yourself.
The only difference I can see between the DSDTs you posted is that one of them has the HPET IRQ fix. But you shouldn't need this since you're using a Disabler.kext which is most likely blocking AppleIntelCPUPowerManagement.kext from loading.
I've created my DSDT.aml with fixes and Hacks, and i'm gonna post it to you with my Everest's report too.
The Everest .html report is handy if you need a quick overview but that's not what I meant - I made some screenshots for you, this is how to dump all your ACPI tables using Everest:
Everest_right_click.png 303.74KB 198 downloads Everest_ACPI_Dumper.png 334.06KB 221 downloads
You should dump and save all available tables, you may need them later. Save them with .aml extension instead of .bin and they'll open right up with DSDTSE.
Neither can I. Download and install LSPCI on your hackintosh to get all the locations for your PCI devices:
For my LAN, i've put skge.kext into S/L/E but it doesn't work, and in my DSDT.aml file, i can't find any suggestion about 88E8056 and 88E8001 code.
http://www.osx86.es/?p=620 - then post the output here and I'll show you how to read it.
I don't know why skge.kext isn't working for you. When booting with -v do you see any error messages about it, or any messages at all?
It should be working - in your second post http://www.insanelym...p...t&p=1465068 you can clearly see the driver loading and the 8001 establishing a connection.
If, for example, I booted into OS X for the first time with the 88E8056 disabled in the BIOS (or no patched AppleYukon2.kext loaded) and skge.kext for the 88E8001 loaded, the 8001 would then become EN0.
I don't know what does it mean : "I have the 88E8056 set as EN0 (primary LAN) in OS X)". How can you set that in OS X ?
The way I've set up everything, the 88E8056 is EN0 and recognized by OS X as 'built-in', which is very important for compatibility. Lots of software for OS X requires the presence of a built-in network adapter, all Macs have one. It could probably be the 88E8001 just as well though but I prefer the 88E8056 as it can run with near-vanilla drivers.
That depends on what changes you make to the DSDT and the hardware you have. If you post a report from LSPCI I can be more specific.
Then when you have a valide DSTD.aml, wich ,kext in /E can you remove ?
For example with HDEF audio patched in DSDT you could get rid of HDAEnabler.kext (your motherboard doesn't have HD audio though). With the code I use for the 88E8056 I don't need UUID.kext/PlatformUUID.kext or any of the other tricks to get a valid PlatformUUID (google or search IM for "UUID error 35"). If your motherboard has ICH9/10/R you can change its device ID in the DSDT so that OS X thinks it's an Intel ESB2 SATA controller (as used in MacPro1,1) then you don't need any patched kexts for it.
Some people modify the USB controller code so that it works better with unmodified drivers (this thread also has info on the ESB2 trick):
You can use the same trick (Device ID patching) to load OS X drivers for the motherboard LPC Bridge, which you probably will need to do if you want to work on getting vanilla CPU state switching working:
You can remove code for devices that you don't use to (possibly) free up resources, such as the serial port and the floppy drive controller. Most ASUS DSDTs have a ton of code that works with Windows-only ASUS motherboard utilities ("AI Life" or whatever) but all that code is useless in OS X and it's safe to rip it all out.
You can do tons of stuff with DSDT patching and there's lots of information around if you want to know more.
Some reading material:
And this totally amazing post here: http://www.insanelym...howtopic=211705
From looking at your DSDT it's clearly very "ASUS", so if you want to put in an effort you can get going with Master Chief's DSDTs right away. I keep repeating this because it's true. You should get going, many of the fixes he's made can be applied to your DSDT with little to no modification.
Here is the link again: http://www.insanelym...p...t&p=1280888