Bchemist Posted November 27, 2009 Share Posted November 27, 2009 Here is the latest DSDT for the P6T-SE via the Evo compiler. I started out with about 15,000 lines of code and managed to whittle it down to about 50% of its original size. At least half of the code for several of ASUS mobos, especially the X58 chipset is not recognized by OSX and even if the OS can see it, it doesn't know what to do with it. If you do an I/O reg dump you'll notice that you can search for the devices but while detected, the OS cannot understand their purpose. This extra "baggage" while minimal, is still dead weight and might even causes hangs or crashes from time to time. In my initial testing (after nearly 30 total hours of work over the last 40 hours) it's clearly faster than the previous version I posted earlier. Everything is much snappier, it's less stubborn to sleep, and many things that were not defined before in "About this Mac" are now clear as to what they are and are no longer "generic". Code removed: Overclocking related code - profiles, voltages, fans, etc. While we can tweak the bios, once it "hands-off" control to the OS, the OS doesn't literally see what we've done unless we can create a dynamic dsdt file....that is obviously far more advanced and I can imagine 150,000 lines of code if that was the case...unless there's a way to hard-code the DSDT for overclocking preferences. My guess is that it doesn't matter anyway. Moving on... Legacy devices - floppy drive, PS2 mouse, keyboard, built-in speakers and other things that I have no idea what they do, Mac doesn't recognize them, and there's nowhere I could reference them on the web through Google searches. Other devices like SAT1 are not used by OSX so that was a large chunk of code that made for much faster scrolling once it was purged. Renaming - Some devices are not properly labeled by ASUS where OSX would understand that it is on its own system. For example RTC0 I renamed to RTC as well as FIWI to FRWR for example. I changed them and did a find/replace to ensure it was thorough. Also the whole USB panel was changed to UHC1, EHCI, etc. Now OSX even sees one of my USB plugs with name and rating of 480 mbps. Hacks added: DTGP so that other hacks will be recognized (a coding reference I assume so all calls are understood) HPET, RTC, IPIC, and TIMR were corrected for IRQ conflicts that would cause your hard drive to crawl (actually done in the earlier version) Coding for hyperthreading was added or CST fix. Sleep calls were changed so now rebooting, sleeping, and shutting down are consistent and fast. Before it worked but it was iffy and could be stubborn to sleep. Actually I was having a problem with shutdown often before this fix. Native SATA was added. My RAID shows seems much faster. Native USB code was added to improve USB performance and seems to add sleep/shutdown support. Firewire power conservation fix was added Added the SBUS hack for system bus support. Added the PCI ID fix. It clearly sees my Nvidia 9800 GT in the "About this Mac" page in detail. There were other subtle fixes that I did as well. Here's where I must credit Master Chief for his thorough guides and clearly documented dsdt.dsl files. In this case I was able to incorporate several of the MacPro4.1 specific code snippets that he added that would be universal to similar mobos by ASUS. If Master Chief ever reads this and I don't ask the question later, are you a Navy Master Chief, Master Chief? You seem like a Navy SEAL with your attention to detail and I met a couple of Senior and Master Chiefs who were SEALS and also very tech savvy. I hope I'm not hijacking this thread of the OP, tweak41, since he still knows more about this scene than I do. I just learn quickly when I get motivated heh heh. I'm sure this isn't my last update to the file since there's at least 1 thing I see during boot that isn't fixed yet that's bothering me. But compare that to the slower boots with at least 5-10 errors before...night and day difference, ESPECIALLY on reboot. If you have problems with the file, please let me know the specifics (not through PM please since I don't do PM unless there's business involved) on the forum since others may have the same question but are too shy to ask. Credit also to Pere and the crew at Evo. Muchas gracias por el compilador de software increíble! Again, I took out code that made this a more "vanilla" DSDT file to the point of view of OSX since it couldn't care less if you have a "deluxe", a "SE" or whatever. If the software cannot understand it, it will either ignore the "Deluxe" features or use them as a point of hang or crash when it gets confused. I'm positive that this will work with the Rampage II Extreme (and other Rampage series), P6T (all versions), and basically any other X58/1366 chipset that uses the i7 processor that is similar to ASUS/Intel. The differences are in the naming conventions. This will also work for the P5Q and other P5 series. The only thing you'd really need to do is swap CST speedstep data and delete the hyperthreading data. I did a version of this earlier with the P5Q with good results so far. There's still so much to learn on this topic but at least it's a challenge with a straightforward goal. Based on what I've learned so far, it doesn't matter what kext files you add or on what hardware that you install it. It doesn't matter if you do a USB install with USB-EFI or a retail disk boot using a 132 disk and the OS is there on your drive in uncorrupted and squeaky clean fashion. What matters is your DSDT and how your mobo can "speak" to OSX to convince it that it is a "Mac". If you have that, kexts and install methods are secondary. So while DSDT may seem to have a steep learning curve, it's just a matter of messing around with it and turning pattern recognition into comprehension. If you want to be in this for the long haul and not panic every time there's an update or a new addition to your system, this is well worth the investment in time. In my case, mac is ok for utility tasks, but it's too much of an F'n pain in the arse and unreliable to be a lone "pro" system. You'd need 2 or 3, especially if you are a power user and you don't have time to deal with Apple care and the local "Geniuses" (that's an oxymoron if I ever heard one) at the Mac store should something happen to you that you read on the Mac forums that never gets resolved. Ironically most of those people end up on these forums for REAL answers from legends. In my case it took a week of scouring those forums hopelessly for answers to stumble over here. In the end, both Mac and PC suck for their own sets of reasons. But at least there are people out there who know that both has their good points and we live in a practical world, resulting in these forums. I don't mind paying for a Mac every 3-4 years, but when I need 2-3 machines every 2 years, then I tend to get *slightly* irritated and would probably end up changing careers to avoid the constant headaches of problems in addition to obscene hardware costs. End of post-dev rant So hopefully at least a few people get to try this and let me know of your bugs (if any). For me, this is a learning experience and the only way I learn is to find out I'm wrong about something...and I need that brain stimulus Future additions to the file will be to possibly cool down the operating temperature. A definite addition will be the dual video card Nvidia hack. I actually have 2 video cards and 4 23" inch monitors to test this on simultaneously. I just need some sleep and about 6-8 hours to test every aspect of it. Here's the sample code for dual video cards if anyone is curious: Just locate your PCI0 device and add the code, be sure to setup your Nvcap correctly. Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_CID, EisaId ("PNP0A03")) Name (_ADR, Zero) Name (_BBN, Zero) Method (_INI, 0, NotSerialized) { If (CondRefOf (_OSI, Local0)) { Store (0x21, OSTY) } } Device (PEG1) /* Here begins the addons */ { Name (_ADR, 0x00010000) Name (PPS1, Package (0x02) { 0x0B, 0x04 }) Method (_PRW, 0, NotSerialized) { Return (PPS1) } Device (GFX1) { Name (_ADR, Zero) Name (_SUN, 0x0B) Name (_PRW, Package (0x02) { 0x0B, 0x04 }) Method (_DSM, 4, NotSerialized) { Store (Package (0x26) { "@0,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@0,device_type", Buffer (0x08) { "display" }, "@0,name", Buffer (0x0F) { "NVDA,Display-A" }, "@1,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@1,device_type", Buffer (0x08) { "display" }, "@1,name", Buffer (0x0F) { "NVDA,Display-B" }, "@2,#adress-cells", Buffer (0x0B) { "0x01000000" }, "@2,#size-cells", Buffer (0x0B) { "0x00000000" }, "@2,compatible", Buffer (0x13) { "NVDA,sensor-parent" }, "@2,device_type", Buffer (0x0F) { "NVDA,gpu-diode" }, "@2,hwctrl-params-version", Buffer (0x0B) { "0x02000000" }, "@2,hwsensor-params-version", Buffer (0x0B) { "0x02000000" }, "@2,name", Buffer (0x0E) { "sensor-parent" }, "@2,reg", Buffer (0x0B) { "0x02000000" }, "NVCAP", Buffer (0x14) { /* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, /* 0008 */ 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }, "NVPM", Buffer (0x1C) { /* 0000 */ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0010 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0018 */ 0x00, 0x00, 0x00, 0x00 }, "device_type", Buffer (0x0C) { "NVDA,Parent" }, "model", Buffer (0x20) { "NVIDIA Geforce Series (Primary)" }, "rom-revision", Buffer (0x06) { "3169a" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } Device (PEG3) /* On some motherboards, this should be (PEG6), try. */ { Name (_ADR, 0x00030000) Name (PPS1, Package (0x02) { 0x0B, 0x04 }) Method (_PRW, 0, NotSerialized) { Return (PPS1) } Device (GFX3) { Name (_ADR, Zero) Name (_SUN, 0x0C) Name (_PRW, Package (0x02) { 0x0B, 0x04 }) Method (_DSM, 4, NotSerialized) { Store (Package (0x26) { "@0,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@0,device_type", Buffer (0x08) { "display" }, "@0,name", Buffer (0x0F) { "NVDA,Display-A" }, "@1,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@1,device_type", Buffer (0x08) { "display" }, "@1,name", Buffer (0x0F) { "NVDA,Display-B" }, "@2,#adress-cells", Buffer (0x0B) { "0x01000000" }, "@2,#size-cells", Buffer (0x0B) { "0x00000000" }, "@2,compatible", Buffer (0x13) { "NVDA,sensor-parent" }, "@2,device_type", Buffer (0x0F) { "NVDA,gpu-diode" }, "@2,hwctrl-params-version", Buffer (0x0B) { "0x02000000" }, "@2,hwsensor-params-version", Buffer (0x0B) { "0x02000000" }, "@2,name", Buffer (0x0E) { "sensor-parent" }, "@2,reg", Buffer (0x0B) { "0x02000000" }, "NVCAP", Buffer (0x14) { /* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, /* 0008 */ 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }, "NVPM", Buffer (0x1C) { /* 0000 */ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0010 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0018 */ 0x00, 0x00, 0x00, 0x00 }, "device_type", Buffer (0x0C) { "NVDA,Parent" }, "model", Buffer (0x22) { "NVIDIA Geforce Series (Secondary)" }, "rom-revision", Buffer (0x06) { "3169a" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } Again, thanks for testing and please feedback here so we can all figure out what is needed to get that 100% vanilla system! Note: I added the original file posted from tweak41 titled DSDTgeneric.aml. Mine is the dsdt.aml. I included it so you can compare the two and see what was done. I also included the dsdt.dsl file so you can open it with a text editor. dsdt.aml.zip DSDTsegeneric.aml.zip dsdt.zip Link to comment Share on other sites More sharing options...
akhenamenra Posted November 28, 2009 Share Posted November 28, 2009 Here is the latest DSDT for the P6T-SE via the Evo compiler. I started out with about 15,000 lines of code and managed to whittle it down to about 50% of its original size. At least half of the code for several of ASUS mobos, especially the X58 chipset is not recognized by OSX and even if the OS can see it, it doesn't know what to do with it. If you do an I/O reg dump you'll notice that you can search for the devices but while detected, the OS cannot understand their purpose. This extra "baggage" while minimal, is still dead weight and might even causes hangs or crashes from time to time. In my initial testing (after nearly 30 total hours of work over the last 40 hours) it's clearly faster than the previous version I posted earlier. Everything is much snappier, it's less stubborn to sleep, and many things that were not defined before in "About this Mac" are now clear as to what they are and are no longer "generic". Code removed: Overclocking related code - profiles, voltages, fans, etc. While we can tweak the bios, once it "hands-off" control to the OS, the OS doesn't literally see what we've done unless we can create a dynamic dsdt file....that is obviously far more advanced and I can imagine 150,000 lines of code if that was the case...unless there's a way to hard-code the DSDT for overclocking preferences. My guess is that it doesn't matter anyway. Moving on... Legacy devices - floppy drive, PS2 mouse, keyboard, built-in speakers and other things that I have no idea what they do, Mac doesn't recognize them, and there's nowhere I could reference them on the web through Google searches. Other devices like SAT1 are not used by OSX so that was a large chunk of code that made for much faster scrolling once it was purged. Renaming - Some devices are not properly labeled by ASUS where OSX would understand that it is on its own system. For example RTC0 I renamed to RTC as well as FIWI to FRWR for example. I changed them and did a find/replace to ensure it was thorough. Also the whole USB panel was changed to UHC1, EHCI, etc. Now OSX even sees one of my USB plugs with name and rating of 480 mbps. Hacks added: DTGP so that other hacks will be recognized (a coding reference I assume so all calls are understood) HPET, RTC, IPIC, and TIMR were corrected for IRQ conflicts that would cause your hard drive to crawl (actually done in the earlier version) Coding for hyperthreading was added or CST fix. Sleep calls were changed so now rebooting, sleeping, and shutting down are consistent and fast. Before it worked but it was iffy and could be stubborn to sleep. Actually I was having a problem with shutdown often before this fix. Native SATA was added. My RAID shows seems much faster. Native USB code was added to improve USB performance and seems to add sleep/shutdown support. Firewire power conservation fix was added Added the SBUS hack for system bus support. Added the PCI ID fix. It clearly sees my Nvidia 9800 GT in the "About this Mac" page in detail. There were other subtle fixes that I did as well. Here's where I must credit Master Chief for his thorough guides and clearly documented dsdt.dsl files. In this case I was able to incorporate several of the MacPro4.1 specific code snippets that he added that would be universal to similar mobos by ASUS. If Master Chief ever reads this and I don't ask the question later, are you a Navy Master Chief, Master Chief? You seem like a Navy SEAL with your attention to detail and I met a couple of Senior and Master Chiefs who were SEALS and also very tech savvy. I hope I'm not hijacking this thread of the OP, tweak41, since he still knows more about this scene than I do. I just learn quickly when I get motivated heh heh. I'm sure this isn't my last update to the file since there's at least 1 thing I see during boot that isn't fixed yet that's bothering me. But compare that to the slower boots with at least 5-10 errors before...night and day difference, ESPECIALLY on reboot. If you have problems with the file, please let me know the specifics (not through PM please since I don't do PM unless there's business involved) on the forum since others may have the same question but are too shy to ask. Credit also to Pere and the crew at Evo. Muchas gracias por el compilador de software increíble! Again, I took out code that made this a more "vanilla" DSDT file to the point of view of OSX since it couldn't care less if you have a "deluxe", a "SE" or whatever. If the software cannot understand it, it will either ignore the "Deluxe" features or use them as a point of hang or crash when it gets confused. I'm positive that this will work with the Rampage II Extreme (and other Rampage series), P6T (all versions), and basically any other X58/1366 chipset that uses the i7 processor that is similar to ASUS/Intel. The differences are in the naming conventions. This will also work for the P5Q and other P5 series. The only thing you'd really need to do is swap CST speedstep data and delete the hyperthreading data. I did a version of this earlier with the P5Q with good results so far. There's still so much to learn on this topic but at least it's a challenge with a straightforward goal. Based on what I've learned so far, it doesn't matter what kext files you add or on what hardware that you install it. It doesn't matter if you do a USB install with USB-EFI or a retail disk boot using a 132 disk and the OS is there on your drive in uncorrupted and squeaky clean fashion. What matters is your DSDT and how your mobo can "speak" to OSX to convince it that it is a "Mac". If you have that, kexts and install methods are secondary. So while DSDT may seem to have a steep learning curve, it's just a matter of messing around with it and turning pattern recognition into comprehension. If you want to be in this for the long haul and not panic every time there's an update or a new addition to your system, this is well worth the investment in time. In my case, mac is ok for utility tasks, but it's too much of an F'n pain in the arse and unreliable to be a lone "pro" system. You'd need 2 or 3, especially if you are a power user and you don't have time to deal with Apple care and the local "Geniuses" (that's an oxymoron if I ever heard one) at the Mac store should something happen to you that you read on the Mac forums that never gets resolved. Ironically most of those people end up on these forums for REAL answers from legends. In my case it took a week of scouring those forums hopelessly for answers to stumble over here. In the end, both Mac and PC suck for their own sets of reasons. But at least there are people out there who know that both has their good points and we live in a practical world, resulting in these forums. I don't mind paying for a Mac every 3-4 years, but when I need 2-3 machines every 2 years, then I tend to get *slightly* irritated and would probably end up changing careers to avoid the constant headaches of problems in addition to obscene hardware costs. End of post-dev rant So hopefully at least a few people get to try this and let me know of your bugs (if any). For me, this is a learning experience and the only way I learn is to find out I'm wrong about something...and I need that brain stimulus Future additions to the file will be to possibly cool down the operating temperature. A definite addition will be the dual video card Nvidia hack. I actually have 2 video cards and 4 23" inch monitors to test this on simultaneously. I just need some sleep and about 6-8 hours to test every aspect of it. Here's the sample code for dual video cards if anyone is curious: Just locate your PCI0 device and add the code, be sure to setup your Nvcap correctly. Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_CID, EisaId ("PNP0A03")) Name (_ADR, Zero) Name (_BBN, Zero) Method (_INI, 0, NotSerialized) { If (CondRefOf (_OSI, Local0)) { Store (0x21, OSTY) } } Device (PEG1) /* Here begins the addons */ { Name (_ADR, 0x00010000) Name (PPS1, Package (0x02) { 0x0B, 0x04 }) Method (_PRW, 0, NotSerialized) { Return (PPS1) } Device (GFX1) { Name (_ADR, Zero) Name (_SUN, 0x0B) Name (_PRW, Package (0x02) { 0x0B, 0x04 }) Method (_DSM, 4, NotSerialized) { Store (Package (0x26) { "@0,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@0,device_type", Buffer (0x08) { "display" }, "@0,name", Buffer (0x0F) { "NVDA,Display-A" }, "@1,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@1,device_type", Buffer (0x08) { "display" }, "@1,name", Buffer (0x0F) { "NVDA,Display-B" }, "@2,#adress-cells", Buffer (0x0B) { "0x01000000" }, "@2,#size-cells", Buffer (0x0B) { "0x00000000" }, "@2,compatible", Buffer (0x13) { "NVDA,sensor-parent" }, "@2,device_type", Buffer (0x0F) { "NVDA,gpu-diode" }, "@2,hwctrl-params-version", Buffer (0x0B) { "0x02000000" }, "@2,hwsensor-params-version", Buffer (0x0B) { "0x02000000" }, "@2,name", Buffer (0x0E) { "sensor-parent" }, "@2,reg", Buffer (0x0B) { "0x02000000" }, "NVCAP", Buffer (0x14) { /* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, /* 0008 */ 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }, "NVPM", Buffer (0x1C) { /* 0000 */ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0010 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0018 */ 0x00, 0x00, 0x00, 0x00 }, "device_type", Buffer (0x0C) { "NVDA,Parent" }, "model", Buffer (0x20) { "NVIDIA Geforce Series (Primary)" }, "rom-revision", Buffer (0x06) { "3169a" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } Device (PEG3) /* On some motherboards, this should be (PEG6), try. */ { Name (_ADR, 0x00030000) Name (PPS1, Package (0x02) { 0x0B, 0x04 }) Method (_PRW, 0, NotSerialized) { Return (PPS1) } Device (GFX3) { Name (_ADR, Zero) Name (_SUN, 0x0C) Name (_PRW, Package (0x02) { 0x0B, 0x04 }) Method (_DSM, 4, NotSerialized) { Store (Package (0x26) { "@0,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@0,device_type", Buffer (0x08) { "display" }, "@0,name", Buffer (0x0F) { "NVDA,Display-A" }, "@1,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@1,device_type", Buffer (0x08) { "display" }, "@1,name", Buffer (0x0F) { "NVDA,Display-B" }, "@2,#adress-cells", Buffer (0x0B) { "0x01000000" }, "@2,#size-cells", Buffer (0x0B) { "0x00000000" }, "@2,compatible", Buffer (0x13) { "NVDA,sensor-parent" }, "@2,device_type", Buffer (0x0F) { "NVDA,gpu-diode" }, "@2,hwctrl-params-version", Buffer (0x0B) { "0x02000000" }, "@2,hwsensor-params-version", Buffer (0x0B) { "0x02000000" }, "@2,name", Buffer (0x0E) { "sensor-parent" }, "@2,reg", Buffer (0x0B) { "0x02000000" }, "NVCAP", Buffer (0x14) { /* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, /* 0008 */ 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }, "NVPM", Buffer (0x1C) { /* 0000 */ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0010 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0018 */ 0x00, 0x00, 0x00, 0x00 }, "device_type", Buffer (0x0C) { "NVDA,Parent" }, "model", Buffer (0x22) { "NVIDIA Geforce Series (Secondary)" }, "rom-revision", Buffer (0x06) { "3169a" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } Again, thanks for testing and please feedback here so we can all figure out what is needed to get that 100% vanilla system! Note: I added the original file posted from tweak41 titled DSDTgeneric.aml. Mine is the dsdt.aml. I included it so you can compare the two and see what was done. I also included the dsdt.dsl file so you can open it with a text editor. woah overtime or what thanks a lot bro trying it now EDIT yeah seems faster thank you very much for your time b 4 sec to sleep 3 sec to wake to shut down 5 secs edit my time machine isnt working again tho?? Webly Ra Link to comment Share on other sites More sharing options...
_Wolverine_ Posted November 28, 2009 Share Posted November 28, 2009 OMG thanks a lot for your help!!! Ill try your modded dsdt later thansk again Link to comment Share on other sites More sharing options...
fc bayern Posted November 28, 2009 Share Posted November 28, 2009 I've put the modified DSDT.aml Post later some with the rezults Link to comment Share on other sites More sharing options...
andrew79 Posted November 29, 2009 Share Posted November 29, 2009 Here is the latest DSDT for the P6T-SE via the Evo compiler. I started out with about 15,000 lines of code and managed to whittle it down to about 50% of its original size. At least half of the code for several of ASUS mobos, especially the X58 chipset is not recognized by OSX and even if the OS can see it, it doesn't know what to do with it. If you do an I/O reg dump you'll notice that you can search for the devices but while detected, the OS cannot understand their purpose. This extra "baggage" while minimal, is still dead weight and might even causes hangs or crashes from time to time. In my initial testing (after nearly 30 total hours of work over the last 40 hours) it's clearly faster than the previous version I posted earlier. Everything is much snappier, it's less stubborn to sleep, and many things that were not defined before in "About this Mac" are now clear as to what they are and are no longer "generic". Code removed: Overclocking related code - profiles, voltages, fans, etc. While we can tweak the bios, once it "hands-off" control to the OS, the OS doesn't literally see what we've done unless we can create a dynamic dsdt file....that is obviously far more advanced and I can imagine 150,000 lines of code if that was the case...unless there's a way to hard-code the DSDT for overclocking preferences. My guess is that it doesn't matter anyway. Moving on... Legacy devices - floppy drive, PS2 mouse, keyboard, built-in speakers and other things that I have no idea what they do, Mac doesn't recognize them, and there's nowhere I could reference them on the web through Google searches. Other devices like SAT1 are not used by OSX so that was a large chunk of code that made for much faster scrolling once it was purged. Renaming - Some devices are not properly labeled by ASUS where OSX would understand that it is on its own system. For example RTC0 I renamed to RTC as well as FIWI to FRWR for example. I changed them and did a find/replace to ensure it was thorough. Also the whole USB panel was changed to UHC1, EHCI, etc. Now OSX even sees one of my USB plugs with name and rating of 480 mbps. Hacks added: DTGP so that other hacks will be recognized (a coding reference I assume so all calls are understood) HPET, RTC, IPIC, and TIMR were corrected for IRQ conflicts that would cause your hard drive to crawl (actually done in the earlier version) Coding for hyperthreading was added or CST fix. Sleep calls were changed so now rebooting, sleeping, and shutting down are consistent and fast. Before it worked but it was iffy and could be stubborn to sleep. Actually I was having a problem with shutdown often before this fix. Native SATA was added. My RAID shows seems much faster. Native USB code was added to improve USB performance and seems to add sleep/shutdown support. Firewire power conservation fix was added Added the SBUS hack for system bus support. Added the PCI ID fix. It clearly sees my Nvidia 9800 GT in the "About this Mac" page in detail. There were other subtle fixes that I did as well. Here's where I must credit Master Chief for his thorough guides and clearly documented dsdt.dsl files. In this case I was able to incorporate several of the MacPro4.1 specific code snippets that he added that would be universal to similar mobos by ASUS. If Master Chief ever reads this and I don't ask the question later, are you a Navy Master Chief, Master Chief? You seem like a Navy SEAL with your attention to detail and I met a couple of Senior and Master Chiefs who were SEALS and also very tech savvy. I hope I'm not hijacking this thread of the OP, tweak41, since he still knows more about this scene than I do. I just learn quickly when I get motivated heh heh. I'm sure this isn't my last update to the file since there's at least 1 thing I see during boot that isn't fixed yet that's bothering me. But compare that to the slower boots with at least 5-10 errors before...night and day difference, ESPECIALLY on reboot. If you have problems with the file, please let me know the specifics (not through PM please since I don't do PM unless there's business involved) on the forum since others may have the same question but are too shy to ask. Credit also to Pere and the crew at Evo. Muchas gracias por el compilador de software increíble! Again, I took out code that made this a more "vanilla" DSDT file to the point of view of OSX since it couldn't care less if you have a "deluxe", a "SE" or whatever. If the software cannot understand it, it will either ignore the "Deluxe" features or use them as a point of hang or crash when it gets confused. I'm positive that this will work with the Rampage II Extreme (and other Rampage series), P6T (all versions), and basically any other X58/1366 chipset that uses the i7 processor that is similar to ASUS/Intel. The differences are in the naming conventions. This will also work for the P5Q and other P5 series. The only thing you'd really need to do is swap CST speedstep data and delete the hyperthreading data. I did a version of this earlier with the P5Q with good results so far. There's still so much to learn on this topic but at least it's a challenge with a straightforward goal. Based on what I've learned so far, it doesn't matter what kext files you add or on what hardware that you install it. It doesn't matter if you do a USB install with USB-EFI or a retail disk boot using a 132 disk and the OS is there on your drive in uncorrupted and squeaky clean fashion. What matters is your DSDT and how your mobo can "speak" to OSX to convince it that it is a "Mac". If you have that, kexts and install methods are secondary. So while DSDT may seem to have a steep learning curve, it's just a matter of messing around with it and turning pattern recognition into comprehension. If you want to be in this for the long haul and not panic every time there's an update or a new addition to your system, this is well worth the investment in time. In my case, mac is ok for utility tasks, but it's too much of an F'n pain in the arse and unreliable to be a lone "pro" system. You'd need 2 or 3, especially if you are a power user and you don't have time to deal with Apple care and the local "Geniuses" (that's an oxymoron if I ever heard one) at the Mac store should something happen to you that you read on the Mac forums that never gets resolved. Ironically most of those people end up on these forums for REAL answers from legends. In my case it took a week of scouring those forums hopelessly for answers to stumble over here. In the end, both Mac and PC suck for their own sets of reasons. But at least there are people out there who know that both has their good points and we live in a practical world, resulting in these forums. I don't mind paying for a Mac every 3-4 years, but when I need 2-3 machines every 2 years, then I tend to get *slightly* irritated and would probably end up changing careers to avoid the constant headaches of problems in addition to obscene hardware costs. End of post-dev rant So hopefully at least a few people get to try this and let me know of your bugs (if any). For me, this is a learning experience and the only way I learn is to find out I'm wrong about something...and I need that brain stimulus Future additions to the file will be to possibly cool down the operating temperature. A definite addition will be the dual video card Nvidia hack. I actually have 2 video cards and 4 23" inch monitors to test this on simultaneously. I just need some sleep and about 6-8 hours to test every aspect of it. Here's the sample code for dual video cards if anyone is curious: Just locate your PCI0 device and add the code, be sure to setup your Nvcap correctly. Device (PCI0) { Name (_HID, EisaId ("PNP0A03")) Name (_CID, EisaId ("PNP0A03")) Name (_ADR, Zero) Name (_BBN, Zero) Method (_INI, 0, NotSerialized) { If (CondRefOf (_OSI, Local0)) { Store (0x21, OSTY) } } Device (PEG1) /* Here begins the addons */ { Name (_ADR, 0x00010000) Name (PPS1, Package (0x02) { 0x0B, 0x04 }) Method (_PRW, 0, NotSerialized) { Return (PPS1) } Device (GFX1) { Name (_ADR, Zero) Name (_SUN, 0x0B) Name (_PRW, Package (0x02) { 0x0B, 0x04 }) Method (_DSM, 4, NotSerialized) { Store (Package (0x26) { "@0,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@0,device_type", Buffer (0x08) { "display" }, "@0,name", Buffer (0x0F) { "NVDA,Display-A" }, "@1,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@1,device_type", Buffer (0x08) { "display" }, "@1,name", Buffer (0x0F) { "NVDA,Display-B" }, "@2,#adress-cells", Buffer (0x0B) { "0x01000000" }, "@2,#size-cells", Buffer (0x0B) { "0x00000000" }, "@2,compatible", Buffer (0x13) { "NVDA,sensor-parent" }, "@2,device_type", Buffer (0x0F) { "NVDA,gpu-diode" }, "@2,hwctrl-params-version", Buffer (0x0B) { "0x02000000" }, "@2,hwsensor-params-version", Buffer (0x0B) { "0x02000000" }, "@2,name", Buffer (0x0E) { "sensor-parent" }, "@2,reg", Buffer (0x0B) { "0x02000000" }, "NVCAP", Buffer (0x14) { /* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, /* 0008 */ 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }, "NVPM", Buffer (0x1C) { /* 0000 */ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0010 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0018 */ 0x00, 0x00, 0x00, 0x00 }, "device_type", Buffer (0x0C) { "NVDA,Parent" }, "model", Buffer (0x20) { "NVIDIA Geforce Series (Primary)" }, "rom-revision", Buffer (0x06) { "3169a" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } Device (PEG3) /* On some motherboards, this should be (PEG6), try. */ { Name (_ADR, 0x00030000) Name (PPS1, Package (0x02) { 0x0B, 0x04 }) Method (_PRW, 0, NotSerialized) { Return (PPS1) } Device (GFX3) { Name (_ADR, Zero) Name (_SUN, 0x0C) Name (_PRW, Package (0x02) { 0x0B, 0x04 }) Method (_DSM, 4, NotSerialized) { Store (Package (0x26) { "@0,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@0,device_type", Buffer (0x08) { "display" }, "@0,name", Buffer (0x0F) { "NVDA,Display-A" }, "@1,compatible", Buffer (0x0B) { "NVDA,NVMac" }, "@1,device_type", Buffer (0x08) { "display" }, "@1,name", Buffer (0x0F) { "NVDA,Display-B" }, "@2,#adress-cells", Buffer (0x0B) { "0x01000000" }, "@2,#size-cells", Buffer (0x0B) { "0x00000000" }, "@2,compatible", Buffer (0x13) { "NVDA,sensor-parent" }, "@2,device_type", Buffer (0x0F) { "NVDA,gpu-diode" }, "@2,hwctrl-params-version", Buffer (0x0B) { "0x02000000" }, "@2,hwsensor-params-version", Buffer (0x0B) { "0x02000000" }, "@2,name", Buffer (0x0E) { "sensor-parent" }, "@2,reg", Buffer (0x0B) { "0x02000000" }, "NVCAP", Buffer (0x14) { /* 0000 */ 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x00, /* 0008 */ 0x0C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x07, /* 0010 */ 0x00, 0x00, 0x00, 0x00 }, "NVPM", Buffer (0x1C) { /* 0000 */ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0008 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0010 */ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, /* 0018 */ 0x00, 0x00, 0x00, 0x00 }, "device_type", Buffer (0x0C) { "NVDA,Parent" }, "model", Buffer (0x22) { "NVIDIA Geforce Series (Secondary)" }, "rom-revision", Buffer (0x06) { "3169a" } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } } Again, thanks for testing and please feedback here so we can all figure out what is needed to get that 100% vanilla system! Note: I added the original file posted from tweak41 titled DSDTgeneric.aml. Mine is the dsdt.aml. I included it so you can compare the two and see what was done. I also included the dsdt.dsl file so you can open it with a text editor. congratulations for your work! and of course congratulations to tweak41:) I' ve been using your dsdt.aml for the last 12 hours. (My mobo is asus p6t se). So far no problems. Faster sleep, faster shutdowns, everything seems just fine. Great! Link to comment Share on other sites More sharing options...
fc bayern Posted November 29, 2009 Share Posted November 29, 2009 So far so good, the modifed DSDT.aml Thanks on Your good will God bless all of You , sharing Your stuff with the world (specially for tweak41, starting this topic) Link to comment Share on other sites More sharing options...
rockyourworld2012 Posted November 30, 2009 Share Posted November 30, 2009 Hello fellow P6T SE users. The goal of this guide is simple---get you up and running with a vanilla (no modifications to the system components essential to OS X like the kernel) installation. It's relatively simple, but can be a bit time consuming for a first time user. First and foremost I literally cannot take credit for anything you find in this guide. All information, patches, and other important stuff came from other users and other places which I will attempt to document to the best of my ability. If anyone sees an error with the information provided please do not hesitate to inform me and I will do my best to correct it as soon as I can. So, having said that let's get on our way! Preparation You're going to need a few things for this installation. They are: OS X Snow Leopard 10.6 Installation DVD 8GB Flash Drive (or larger) P6T SE based Intel Core i7 System with 0504 or 0603 BIOS HERE A functioning OS X environment THIS ESSENTIALS PACKAGE Getting Started Note: If you've gone into your BIOS and disabled Hyper Threading and additional cores, you can go back in and enable them. The included DSDT.aml file is already patched for 4 cores + HT. Because the installation is going to be restored to a flash drive, the first thing you need to do is format the flash drive. Open up Disk Utility and format it using the GUID partition scheme and HFS+ file system (this is selected by default usually). Make sure to give it a name (preferably a short one that's easy to type as you'll be using it later). See screenshots below: After you've formatted your flash drive you'll need to restore the Snow Leopard DVD to it. Insert your Snow Leopard DVD and open up Disk Utility. Here you'll select Mac OS X Install DVD from the list and click the Restore tab. Then click and drag "Mac OS X Install DVD" to the source text box and your formatted flash drive volume (here it's called Installer) to the destination text box. Uncheck Erase Destination then click Restore. This process takes a while so if you've got something else to do, you might as well do it. It took about an hour for my MacBook to do. Booting the flash drive By now you should have your Snow Leopard DVD restored to your flash drive. The next step is to make it bootable. That's where the attached essentials come in handy. Open the folder and run "2_Boot Prep." This script installs Chameleon 2 RC3 to the drive, generates the kext cache with all of your essential kexts, and places it, com.apple.Boot.plist, smbios.plist, and DSDT.aml in the necessary places on your flash drive. Once that's finished you're ready to boot the Snow Leopard installation! Make sure that you drag a copy of the P6T SE Essentials folder to the thumb drive before removing from your Mac. You'll need to copy this folder to your new Snow Leopard installation in a half hour. Note: If you use one of the newer ATI Radeon HD4xxx cards you may want to replace the boot file on the thumb drive with the EFI 10v3 boot file included in the essential folder. MAKE SURE TO RENAME IT TO "boot" BEFORE REPLACING THE EXISTING boot FILE. Installation I strongly encourage you to set your OS X drive as the first in the boot list in your BIOS. It makes things a lot easier. If you've already installed OS X on any machine you'll be familiar with the setup. Apple makes it easy anyway. Ideally you should completely power down your computer. This guide assumes that you're installing to a SATA hard drive and that you've configured it as either AHCI or RAID in your BIOS (yes, you can use RAID but not a drive or drives in an array). Turn your computer on and press the F8 key until you get a message about BBS popup. This will let you select your boot device. You want to choose the thumb drive that you prepared in the earlier steps. You should now see the Chameleon boot loader screen. Select your thumb drive (here it's Installer) and type -v and press enter. Now you'll see a wall of text and if something goes wrong it can help us pinpoint the problem. If everything goes smoothly you'll see the first of several installation screens for OS X. Make sure that you use Disk Utility to format your destination HD as HFS+ and use the GUID partition scheme! Select any languages you may want, printer drivers, etc and install. It should take about 30 minutes. The Fun Part So you should have OS X installed now. You're not quite finished though. When you reach the screen that asks you to reboot, do so. However you will need to make sure that you boot from your flash drive again. The retail installation does not have the necessary kexts or proper boot loader to allow you to boot straight into OS X. Using the F8 trick, boot to your flash drive but this time select your Snow Leopard installation. I recommend using the -v flag again in case there is an error or kernel panic. Knowing this information will help us troubleshoot if something goes wrong. The initial boot may take a bit longer than you'll normally see. Within a few minutes (it shouldn't take more than 5) you'll be welcomed with the introductory video. If everything worked correctly you'll also get sound! Continue setting up your user account and filling in the necessary information. Once you have reached the desktop you'll want to copy over the P6T SE Essentials folder to the desktop. Right now you have a choice to make regarding how your computer boots from now on. They are: Boot from system partition Boot from EFI partition Boot from external medium (i.e. USB, CF, SD, etc) System Partition If you would like to install the Chameleon RC3 boot loader to the system partition (the main one that you see active when running your computer), open the Essentials folder and run "3_Loader." Follow the on screen prompts, making sure to type "N" when asked if you want to install to the EFI Partition. EFI Partition If you would like to install the Chameleon RC3 boot loader to the EFI partition (something used on real macs, but not hackintoshes), open the Essentials folder and run "3_Loader." Follow the on screen prompts, making sure to type "Y" when asked if you want to install to the EFI Partition. Boot from external medium (i.e. USB, CF, SD, etc) This is the method I prefer because of the way my system is setup. Since I have a RAID0 array that I run Windows from, I can't conveniently dual boot operating systems if my boot loader is run from a hard drive. I simply can't run it on my array, and I get errors trying to do so from the OS X hard drive. Since I had a spare CF card lying around I decided to install the boot loader to that. Doing so allowed me to set Windows as my default OS and still easily boot to OS X when I need to. Step 1) Format your boot medium GUID Partition Scheme. Format it as HFS+. Step 2) Run "External Medium Booter" from the P6T SE Essentials folder. Step 3) Configure your BIOS to boot this medium first. The P6T SE BIOS can boot from pretty much any external medium. After you've prepared your system to boot, you're done! Enjoy OS X. Use this patch to make your About This Mac transform: http://www.insanelymac.com/forum/index.php?showtopic=98775 Credits This guide was my starting point. The files in the attachment have been customized from those originally in his post for a P6T SE specific install. Link: http://www.insanelymac.com/forum/index.php?showtopic=183751 Other useful forum links: http://lb.redirectingat.com/?id=292X457&am...Fview%3Ddetails Credits for the ICH10R support: http://digitaldj.net/2009/09/03/ich10r-in-...d-snow-leopard/ Feel free to update using Software Update. The 10.6.1 Update works perfectly. tweak41 i have a compaq presario f730us with athlon 64x2 cpu and 1gb ram. i'm trying to boot a retail install of snow leopard 10.6. i get a kernel panic about com.apple.driver.AppleACPIPlatform. i'm using voodoo kernel 9.6.0 and netbookbootmaker. i've uploaded a copy of the screen. what to do? Link to comment Share on other sites More sharing options...
Bchemist Posted November 30, 2009 Share Posted November 30, 2009 woah overtime or what thanks a lot bro trying it now EDIT yeah seems faster thank you very much for your time b 4 sec to sleep 3 sec to wake to shut down 5 secs edit my time machine isnt working again tho?? Webly Ra Is the time machine icon at the top toolbar and can you select options or is it inaccessible? What are you using for your time machine? In my case I'm using a terabyte drive to backup my SSD and 3 striped RAID disks but it's plugged into the SATA port. If you are using an external drive that may need a separate fix but I have something in mind. Also did you just notice that it wasn't working now or did it suddenly stop? To test a fix I'll need you to find your network card in the registry using the I/O tool or some other similar tool. The Evo Soft compiler I use uses the registry tool in its own interface. It should show something like "Realtek RTL8111/8168 PCI-E Gigabit". Post it here and I'll patch it should you be having a problem due to that. OR...I just thought of something in my case, and it's how I boot into 32 bit mode due to problems with Final Cut "breaking" in 64 bit after a random number of uses and then the crashes stop if I boot in 32 bit mode. Sometimes it would work in 64 bit but it's annoying to have to reboot if it won't so I just stick to 32. I don't notice any performance difference at all between 32 and 64, and Final Cut is as heavy duty as it gets. Actually I cannot tell any performance issues in general. I7 running properly with Snow Leopard should be too fast to notice any difference with the current software on the market if all of their drivers are current and they have no I/O conflicts in the hardware. So just for fun, try booting in 32 bit by adding arch=i386 to your boot file or by manually typing it at the bootloader and see if that works should you still be having problems as you read this. Option 2, but I have no idea if this would make a difference in 64 bit mode or even booting in 32 bit mode is to "Get Info" on the time machine icon in the applications folder and check "open in 32 bit". I think you can do that now if in 64 bit mode. If not, when booting in 32 bit mode it should be automatic. I'll try one fix that I know of and I'll upload it here asap...hopefully 10 minutes. The change will be in the P0P6 device code if you are curious to see what was done. EDIT - I added the fix and it should be more compatible there. I deleted similar code from the P0P9 file with 0 warnings and obviously 0 errors (or it wouldn't compile. Later I'm going to get rid of some more code that I've discovered to be clutter. The dual graphics card fix will be next...since I think I just figured out how to make it read any card instead of just card specific...or at least let's hope it's possible. dsdt.aml.zip Link to comment Share on other sites More sharing options...
Bchemist Posted November 30, 2009 Share Posted November 30, 2009 It seems that MacPro4.1 prefers that we mount our PCI related items on P0P4,6, and 7. While they can work on others like 8 and 9, OSX is probably in "WTF" mode. So to make it more compatible not only will I have to mount the dual graphic card on one of those 3, I should probably move the system bus info as well. I'm not sure exactly what I'm looking at, but on P0P8 it appears to be where the JMicron code is located. I left it alone but this time I think I'm going to trash it. For those of you using JMicron drives and whatnot, don't add the update I'm going to attach to this post....but then again, it might work anyway with a JMicron kext...well that's what the kexts should be for anyway considering there's no audio code in the dsdt file but we have audio nonetheless due to our kext files. I actually did find a couple of audio hacks but until I see a good reason to use them, I'll leave it out for now. Perhaps when I get the itch to upgrade to 10.6.2....but until I find the patch that identifies the i7 and doesn't screw up sleep, I'll leave it alone...that is unless anybody else has the patch, please feel free to post in on the forum while tweak41 is away EDIT: Attached is the latest DSDT file. I code remains the same as the first version with respect to the specific "Time Machine" fix made to the previous file. In other words I went back to the generic code vs. the more specific Realtek code. From what I understand, however, moving the LAN to the more compatible P0P6 device should cure any ills seen by it being on the 9 slot as before. Getting rid of the JMicron device code on the legacy slots should theoretically speed things up just a tiny bit also. When doing this, I gutted another 1000 lines of code from port 8 that was the JMicron drives. So from the original 15,000 lines of code we now have a more streamlined 7000. I'm sure I could clean it up more, but if it ain't broke, don't fix it...plus I'm not feeling that ambitious/reckless at the moment. As a bonus I was able to add the cooler CPU hack that supposedly drops the CPU temperature. I don't have a working thermal app so I can't really tell if it helped or not. Either way this is more involved and if you don't know how to make this change to your AppleLPC.kext, I'd recommend not doing it until you do know how. In the hack it says that you'll need to check the device-id of the LPCB/SBRG. You'll be looking for a string of 16 3a 00 00. If yours matches, you'll need to change your AppleLPC.kext file. Inside the .plist you'll be changing the IOName to pci8086,3a16 FROM pci8086,3a18, repair permissions, (don't ask me to write this out...do a search on how to do modify and repair kext since it's been written 100 times on this forum alone...at least) If your value is 18 3a 00 00 you neither need the hack to your dsdt nor a hack to your AppleLPC.kext. I'll make two versions. A modded and unmodded version. You'll need to rename the unmodded version to dsdt.aml...I hope that should be obvious I actually tested this for about 2 hours and loaded up my system with several heavy programs...actually heavier that I thought to run earlier before I thought of adding the temperature fix. Over the last two hours, the temperature of my system has ran at a range of 5-8C cooler per core. I don't notice any audio skipping as is a common side effect, but I had already removed the IRQ values as recommended as a post fix. In other words the post fix mod is the same as the mod to speed up hard drive access times and prevent IRQ conflicts. Maybe I simply didn't notice before, but the graphics card seems to have every last feature installed. Enough for now...have fun with this since more or less everything should work 100%...at least it does for me. C-state seems to work, speedstep, and obviously sleep is working for those who gave feedback, internet, sound...maybe input mic also but I haven't tested it. Any audio I've done is through a Motu preamp or Midi so audio isn't really necessary for me, but it's nice to be able to have it if you are just doing minimal things obviously and it seems to work fully. Does anything NOT work now? (Assuming the Time Machine problem is fixed for the one case) 64 bit mode isn't perfect but Mac isn't supposed to boot in 64 bit mode anyway due to the instability of certain large 32 bit apps. Again, with fast hard drives and our i7 monster CPU I can't see how anyone can tell the difference if their system is setup properly. I really can't think of anything. I need to do more research before I work on the dual card system...maybe a few more days before I take a whack at that. If I do any more fixes it will just be in rearranging any remaining non-optimal device configurations as to get them on the ports where they belong instead of "plug and play" like before. dsdt.aml.zip dsdtnoheatfix.aml.zip Link to comment Share on other sites More sharing options...
akhenamenra Posted November 30, 2009 Share Posted November 30, 2009 Is the time machine icon at the top toolbar and can you select options or is it inaccessible? What are you using for your time machine? In my case I'm using a terabyte drive to backup my SSD and 3 striped RAID disks but it's plugged into the SATA port. If you are using an external drive that may need a separate fix but I have something in mind. Also did you just notice that it wasn't working now or did it suddenly stop? To test a fix I'll need you to find your network card in the registry using the I/O tool or some other similar tool. The Evo Soft compiler I use uses the registry tool in its own interface. It should show something like "Realtek RTL8111/8168 PCI-E Gigabit". Post it here and I'll patch it should you be having a problem due to that. OR...I just thought of something in my case, and it's how I boot into 32 bit mode due to problems with Final Cut "breaking" in 64 bit after a random number of uses and then the crashes stop if I boot in 32 bit mode. Sometimes it would work in 64 bit but it's annoying to have to reboot if it won't so I just stick to 32. I don't notice any performance difference at all between 32 and 64, and Final Cut is as heavy duty as it gets. Actually I cannot tell any performance issues in general. I7 running properly with Snow Leopard should be too fast to notice any difference with the current software on the market if all of their drivers are current and they have no I/O conflicts in the hardware. So just for fun, try booting in 32 bit by adding arch=i386 to your boot file or by manually typing it at the bootloader and see if that works should you still be having problems as you read this. Option 2, but I have no idea if this would make a difference in 64 bit mode or even booting in 32 bit mode is to "Get Info" on the time machine icon in the applications folder and check "open in 32 bit". I think you can do that now if in 64 bit mode. If not, when booting in 32 bit mode it should be automatic. I'll try one fix that I know of and I'll upload it here asap...hopefully 10 minutes. The change will be in the P0P6 device code if you are curious to see what was done. EDIT - I added the fix and it should be more compatible there. I deleted similar code from the P0P9 file with 0 warnings and obviously 0 errors (or it wouldn't compile. Later I'm going to get rid of some more code that I've discovered to be clutter. The dual graphics card fix will be next...since I think I just figured out how to make it read any card instead of just card specific...or at least let's hope it's possible. bro man feeling the love ill try it when i get off the job like cheers b Link to comment Share on other sites More sharing options...
fc bayern Posted November 30, 2009 Share Posted November 30, 2009 Tried dsdtnoheatfix.aml For me, no P2S keyboard after restart, so I restore the previous one from You, which worked perfectly for me(i see no reason for the latest one- no cpu cold down with the new one, the same cpu temperature on iddle and system boot) Think this will give You some clue Link to comment Share on other sites More sharing options...
e1ement Posted November 30, 2009 Share Posted November 30, 2009 I don't know whether it is the modified EVOenabler.kext or Bchemist's DSDT.aml, but for the case that it is Bchemist's DSDT.aml: GOD DAMN I F****** LOVE YOU!!! My Snow Leopard USB-Drive finally boots up. e1ement Link to comment Share on other sites More sharing options...
akhenamenra Posted November 30, 2009 Share Posted November 30, 2009 bro man feeling the love ill try it when i get off the job like cheers b tried it it fixed the time machine but the internet then broke lol (the latest dsdt) i think it has conflicts on the ethernet port made a back up the reverted back to the ole settings lol thanks for your input tho ( i tried resetting the network) deleting the network plist and the preferences but to no avail... even re booting with the custome ionetwork.kext and my original .kext once again tho thanks for your help bruv oops forgot to say the temperature isnt working ere either b EDIT reverted back to your old DST the one after i posted the tools to use to make the DSDT and i sorted the time machine bit of a cheeky one nd you can tell me to f off but do you think you could redo your latest dsdt without the time machine fix ? bit much i know thanks in advance b Link to comment Share on other sites More sharing options...
Bchemist Posted December 1, 2009 Share Posted December 1, 2009 Tried dsdtnoheatfix.amlFor me, no P2S keyboard after restart, so I restore the previous one from You, which worked perfectly for me(i see no reason for the latest one- no cpu cold down with the new one, the same cpu temperature on iddle and system boot) Think this will give You some clue Did you check the AppleLPC.kext and see if it matched your I/O reg dump or use the I/O tool to check to see if the ID matched and then make the necessary modifications, if any? I'm assuming you did but I have to ask just so it's clear in my mind. The reason is that everything that I read that I use to apply these fixes is ambiguous if not completely topsy turvy where True can equal False....if you see what I mean. In fact, I'm going to test the backwards version where I leave the AppleLPC.kext unmodified and hardcode the LPC ID into the DSDT to reflect the AppleLPC.kext. I'll test it and post it later. Either way if you tried both of those versions and find that the previous version works better, by all means, stay with that one. Even though we have the same mobo and I'm trying to code this for a "vanilla" system, the more hacks I make to the Vanilla DSDT, the more chances of conflicts, problems, and whatnot. Thanks for the input Link to comment Share on other sites More sharing options...
tweak41 Posted December 1, 2009 Author Share Posted December 1, 2009 Bchemist, What kexts are you running in addition to these modified DSDT files? I've been playing with the various ones you've uploaded and noticed no difference in performance between yours and the one I've been playing with over the past month and a half...Keep in mind that the one in the guide is really old and I've made several changes to the one I'm using now. According to Temperature Monitor OS X runs at least an average of 10ºC hotter than in Windows 7 or the program is inaccurate? I'm also using FakeSMC 2.5... I'll be damned if that AppleLPC kext trick didn't fix my CPU temp issue. They were 45ºC at idle, and now I'm down to 33ºC at idle. Fantastic. That leads me to my next question... Jesus H., who are you? I just read through all your posts and my god man, you're like some DSDT genius overnight. Anyway, cool. Where the hell did you figure this out? Link to comment Share on other sites More sharing options...
Bchemist Posted December 1, 2009 Share Posted December 1, 2009 tried it it fixed the time machine but the internet then broke lol (the latest dsdt) i think it has conflicts on the ethernet port made a back up the reverted back to the ole settings lol thanks for your input tho ( i tried resetting the network) deleting the network plist and the preferences but to no avail... even re booting with the custome ionetwork.kext and my original .kext once again tho thanks for your help bruv oops forgot to say the temperature isnt working ere either b EDIT reverted back to your old DST the one after i posted the tools to use to make the DSDT and i sorted the time machine bit of a cheeky one nd you can tell me to f off but do you think you could redo your latest dsdt without the time machine fix ? bit much i know thanks in advance b No problem...I'm sure the demanding posters who ask that I reinvent the wheel are sure to follow but so far this is a reasonable request Like I said, this is a learning experience for me in that it will shed light on how we might have the same mobo but are sometimes minor IRQ changes that ASUS will make without explicitly pointing that out. When I get some free time later to get to my P6T-SE I'll work on a few variations and see if any of them will work. It won't take too long since it's just cut or copy and paste at this point. What you can do that would shed some light on conflicts is to see if you can find the I/O reg tool or download one of the DSDTSE compliers from EVO and you can extract your I/O using their viewer. Look for P0P2 thru P0P9....note that's 0 and not O. Let me know which are shown as "active" and "registered" in the upper right corner of the tool (you'll know when you see it if you don't have the tool already). I don't know whether it is the modified EVOenabler.kext or Bchemist's DSDT.aml, but for the case that it is Bchemist's DSDT.aml: GOD DAMN I F****** LOVE YOU!!! My Snow Leopard USB-Drive finally boots up. e1ement Link to comment Share on other sites More sharing options...
fc bayern Posted December 1, 2009 Share Posted December 1, 2009 Yaeh, what kext do You use to speedstep You cpu, if You use any Pls post(I'm not sure but i think that is 64bit, here on p6t deluxe v1, it ain't working) For example , when batching a photos with Capture NX in 32bit, the cpu would overlocked itself and You could hear the noiser sound of the cpu fan for the time cpu overclocked, but in 64 bit, that's not the case.Is this normal or 'm I missing something. I use nullcpupowermanagment.kext and fakesmsistat(to show cpu temperature in istat) Link to comment Share on other sites More sharing options...
akhenamenra Posted December 1, 2009 Share Posted December 1, 2009 No problem...I'm sure the demanding posters who ask that I reinvent the wheel are sure to follow but so far this is a reasonable request Like I said, this is a learning experience for me in that it will shed light on how we might have the same mobo but are sometimes minor IRQ changes that ASUS will make without explicitly pointing that out. When I get some free time later to get to my P6T-SE I'll work on a few variations and see if any of them will work. It won't take too long since it's just cut or copy and paste at this point. What you can do that would shed some light on conflicts is to see if you can find the I/O reg tool or download one of the DSDTSE compliers from EVO and you can extract your I/O using their viewer. Look for P0P2 thru P0P9....note that's 0 and not O. Let me know which are shown as "active" and "registered" in the upper right corner of the tool (you'll know when you see it if you don't have the tool already). thanks guru first and last im gonna re read and see if i can contribute some more .. Link to comment Share on other sites More sharing options...
Bchemist Posted December 1, 2009 Share Posted December 1, 2009 Yaeh, what kext do You use to speedstep You cpu, if You use anyPls post(I'm not sure but i think that is 64bit, here on p6t deluxe v1, it ain't working) For example , when batching a photos with Capture NX in 32bit, the cpu would overlocked itself and You could hear the noiser sound of the cpu fan for the time cpu overclocked, but in 64 bit, that's not the case.Is this normal or 'm I missing something. I use nullcpupowermanagment.kext and fakesmsistat(to show cpu temperature in istat) I have both all C states enabled and also native speedstep on the bios. In addition, I use a speedstep kext that I've used since I first got the mobo but I have no idea whether or not it is helping. I've become aware of the heating problems only over the last couple of weeks and also realized that not only do my systems heat up the place fairly quickly (plus I live near the equator so it's hot year-round so any additional heat is noticed quickly even with full air-conditioning), but this is now an acutely discussed problem with fairly clear solutions that seem to be available. I suppose I could start testing with or without the kext to see, but my system seems to be much better since the first DSDT that I released (I guess that's the 2.0 with the previous on this thread being 1.0 since most of the useless code was still there) but that's if I had time to be curious to find out for myself. It's much more productive to solve your problem since you actually need a solution while if I create problems, then nagging would start around the house from the girlfriend What's happening in your case doesn't sound normal. I indeed discovered my initial suspicion that there was a good chance that I interpreted the hack backwards. At least I'm ready for that now after all of the other times I've hosed my system because I wasn't ready for a double meaning. I'm lucky to have extensive experience in research and technical writing so hopefully I'll be able to make things more clear than what you are used to reading. That's probably the only thing that the forums are lacking in general since there's no shortage of brilliance in the programming and hacking department, explaining it all is the flipside where it's obvious that anyone looking to write a book would do very well if they did so did it on this topic. Hmmm....I may have an idea for a new blog Enough of that heh heh back to your problem. *****UPDATE NOTICE TO ALL - CPU TEMPERATURE IS FIXED******* I left the previous version up so those who didn't download it can compare what I did in the code. Here's the latest dsdt....this is the official 2.1 where I did the cooler temperature hack properly. Soooo...if you modded your AppleLPC.kext you'll need to put it back to its stock form for this version to work, i.e. the "16" will now be "18" in the code of the dsdt file to match the native kext. I verified this with the I/O registry tool where if you search LPC you'll see that the AppleLPC.kext is registered and active. I did notice also that my CPU temperatures were even lower by 2C where only one core is above 50C at 52C. So maybe this will fix everything. If possible, download the DSDTSE compiler and use it to check your registry I/O if you haven't done so already. If there are any other conflicts it should say so here. I'm using the nullcpu.kext also as well as netkas fakesmc 2.5 in addition to the minimum standard kexts. I do not use disabler however. I modded the platformUUID to reflect my boot drive as well. Overall with the modded DSDT I'd assume that several things that needed a kext before may not need one now or the DSDT could be modded as in the case of the AppleLPC.kext to make the mobo sync with the OS instead of relying on plug and play. ****EDIT - Hours later in my own testing, it seems that either method will work, i.e. if you mod the AppleLPC.kext and the DSDT or just the DSDT to match the kext. This really makes my instincts fire in the direction that as long as you can get some form of device ID, you can hack the DSDT with said ID to make it match the kext that you are trying to get to work. EvOSpeedStep.kext.zip dsdt.aml.zip Link to comment Share on other sites More sharing options...
Bchemist Posted December 1, 2009 Share Posted December 1, 2009 Bchemist, What kexts are you running in addition to these modified DSDT files? I've been playing with the various ones you've uploaded and noticed no difference in performance between yours and the one I've been playing with over the past month and a half...Keep in mind that the one in the guide is really old and I've made several changes to the one I'm using now. According to Temperature Monitor OS X runs at least an average of 10�C hotter than in Windows 7 or the program is inaccurate? I'm also using FakeSMC 2.5... I'll be damned if that AppleLPC kext trick didn't fix my CPU temp issue. They were 45�C at idle, and now I'm down to 33�C at idle. Fantastic. That leads me to my next question... Jesus H., who are you? I just read through all your posts and my god man, you're like some DSDT genius overnight. Anyway, cool. Where the hell did you figure this out? The only kexts are, other than the Evospeedstep, fakesmc2.5, AppleRTC (haven't looked into this...supposedly stops a kernel panic but I downloaded it from a p6t (non SE) guide), platformUUID, Ioahblockstorage, and IOnetworking. Hahaha I often wonder that myself (who am I) when I decide that I want to figure something out since I'll work 4 hours at a time without moving and usually that will be just to pee or something...and this will literally go on for 30-40 hours straight. But really it's just a combination of OCD, curiosity, and proving to myself that I can get this to work without having to deal with the local Mac store (nincompoops....don't get me started) since I live in an area where there's plenty of tech but if people think it's expensive in the States, it's double that cost here. But at least software can be bought without the same problems. Bottom line is that while I wear "many hats" in what I do, what I am not is a programmer....where I had fun with my Commodore 64 as a kid, knew how to code in Basic at age 8 but then my mother decided to buy a piano instead of upgrade my computer....still a *very* sore issue to this day....resulting in barely passing FORTRAN in college. Years later I was using Mac and PC for various things and found myself wanting to throw the mac out of the window for being too slow. That's when I started doing aggressive things to see if I could speed it up and a couple of months ago I asked the question, "I wonder if I can figure out how to make Mac run on PC...they ARE both Intel after all" and found that there was already a robust community. I stumbled around for awhile, made a few thousand mistakes since the first mobos I worked with was the Rampage II Extreme (where there's minimal info or how-to's) and AMD based laptops, and innovated a few things that I haven't seen done yet...like installing a distro without a DSDT, then booting up again in the distro with a USB attached to restore a DSDT file to the root drive of the boot drive without overwriting any of the files. This was the easy method I discovered rather than loading up Windows and then having to use Macdrive to plant the DSDT only to delete Windows and waste tons of time on both processes. But I'd get hyper-focused, then distracted on something else, then back to this again. But recently I got fixated on the DSDT and finally got the nerve to dive into the compiler and decided to just start messing around until pattern recognition began to take hold...kinda like when I'd tutor organic chemistry in college where you take a D- student the morning before their final exam covering 2 semesters and 12 hours later they are ready to ace the test and cannot believe they spent a year completely lost. In short, I'm just someone who is of average intelligence, minimal formal computer education or coding experience, but who is highly motivated to be perfect at whatever I'm doing. So I'm not a rogue Apple programmer if that's what you are wondering...and actually I was wondering how the hell I've been able to get so much done so fast where anything that is still left unsolved is just a matter of days or a week if I have the time (not sure on my sked hehe) But in reaching any possible future goals, I'm sure to make mistakes since what we are doing is very ambitious. I hope everyone realizes that while my file might be perfect in some configurations, there are other times I'll make mistakes. In fact, everybody has probably seen tons of mistakes from gurus who know things so well that they forget that everybody else isn't that well read, plus they think faster than they type, hence the "fix" can often be worse than the cure, especially if the instructions are ambiguous at best. But kinda like you said, albeit in a different way earlier, I'm just standing on the shoulders of giants. I can't say that I'll be around this scene as much as some people, but I did promise myself that I'd give back at least as much as I've gained from this when I was ready to do so. It would be nice if it's in dividends. Right now things are looking promising in that a Mac-ready DSDT is possible for any Asus Intel mobo. What I'd really want to tackle just to test this hypothesis is a 1156 chipset DSDT. I've already been able to get the P5Q DSDT fixed with the same mods as I've done here with the only difference being that I had to remove HD audio from the DSDT or the voodooHD kexts wouldn't work. I'm fairly certain that they would work if I used the stock HD files and just used their ID's to hack the mobo just like is needed with the AppleLPC fix. Somewhere I'm sure this has been done already, but it's almost easier to just redo it for our board since SL presents an entirely different set of hurdles. Bottom line is I'm really nobody in this field of R&D...but thanks for the props Link to comment Share on other sites More sharing options...
fc bayern Posted December 1, 2009 Share Posted December 1, 2009 Bchemist THANKS for Your promt REPLY I'll be trying this after 4pm(jobe off) and post back the results I love this topic, MAKE OUR PC a real true MACINTOSH THANKS EVERYBODY SHARING THEIR KNOWLEDGE WITH US(rest of the world), NORMAL PC consumers Link to comment Share on other sites More sharing options...
Bchemist Posted December 1, 2009 Share Posted December 1, 2009 Here is LAN aka Time Machine fix version 2.1. I'm starting to get a good handle on the machine language addresses in that I was able to match the device ID of the built in ethernet of what I saw in the I/O to the IONetworkfamily.kext of the vanilla extensions. I then hardcoded the machine address in the DSDT just like what was done in the latest version of the AppleLPC.kext temperature fix. Sure enough the LAN is now identified as "ethernet" in the I/O in addition to several other indications that OSX fully understands it instead of just a "good enough" aka plug and play. So just like Windows it seems that OSX has a fairly robust plug and play system where it can handle a large number of 3rd party devices. To be able to use "only" Mac is not good for public image so they've wisely allowed OSX to see a limited number of 3rd party devices that use generic or vanilla drivers. Realtek is one of those devices. But unless additional coding is done on the 3rd party side, the devices won't give full functionality even though they'll work in most cases. It's like my WD external drive on a HP laptop I have that has Vista. Vista can use it even though the official drivers weren't installed at first. But to get all of the features of the hardware, you needed the drivers. Apparently WD is infamous for this in the past, i.e. partial plug and play functionality. Usually it works, but for a few people it will not for whatever reason. Most likely it's due to an address conflict somewhere. If time machine works for some systems but not others, it's likely due to a scenario such as this. HOPEFULLY this will fix it and verify this hypothesis of OSX. If not, I'm sure there's other solutions. dsdt.aml.zip Link to comment Share on other sites More sharing options...
deggertsen Posted December 1, 2009 Share Posted December 1, 2009 Alright, I'm trying to make sense of all the posts since 10.6.2 was released. I'm looking to upgrade now but obviously I want to make sure the update will go smoothly. What is the conclusion after all the above on the best and easiest way to update after following the guide in the first post of this topic? It would be nice if the update instructions were appended to the original post for those of us that don't want to spend the time reading through several pages of posts... Excuse my laziness but I'm also somewhat of a newbie to all of this so simplifying things down to one step by step post is very helpful. Thanks! Link to comment Share on other sites More sharing options...
fc bayern Posted December 1, 2009 Share Posted December 1, 2009 Bchemist I use Your latest DSDT.aml ver. 2.0, no cpu cooling down Also i changed the info.plist in AppleLTC from default 18 to my(ASUS) 16, and get bach the cpu overclocking itself again like earlier.With the DSDT.aml, no proper speddstep, had to change AppleLTC. Tnanks for the tip. Bchemist Here my dsdt and my I/o dump If You will , modifed them for me Thanks from_fc_bayern.zip Link to comment Share on other sites More sharing options...
gateway69 Posted December 1, 2009 Share Posted December 1, 2009 I'm looking to take the plunge and build my own OSx86 box, i'm trying to find the right hardware combination my cpu will be the core i7 975, would you guys recommend the P6T SE? I will also probably be going for a Nvidia G 260 or higher.. thoughts? Link to comment Share on other sites More sharing options...
Recommended Posts