Asus P6T SE Retail Snow Leopard Installation Guide [FLASHDRIVE] [UPDATED JUN. 28]]

[caxio]

new bios for asus p6t se on asus download

P6T-SE-ASUS-0608

tested and working whit snow leopard

[akhenamenra]

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.

 

 

yeees Marty mcFly back in action thanks doc lol

 

obrigado

 

 

where on the( or near) the equator are you bruv?

 

 

 

 

p6tse is ok if you want to sacrifice dual nvidia cards (sli) other than that its cool if your looking for a

fast osx then i would say come get the p6t se follow the guide and try and get a gpu that is compatable and easy to to "code"

 

me i just bought the pc then was like arrgh man i didnt do my research

 

luckily for me others got the board and decided to live the dream of dual booting windoze and osx im just on the ride hopin to help along the way

 

just with they would make the new mac pro compatable with the new direct x 11 cards ( alas thats the dream)

 

 

get ya feet wet then jump in .................splash

[Bchemist]

fixed done and dusted

 

obrigado

where on the( or near) the equator are you bruv?

 

Roger that...

 

Currently Cebu in the sunny Philippines

 

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

 

Ok I'll take a look at see what I can do.

 

Just so I understand, you took the latest DSDT and did the modification to 16...but your system is natively 18? I'm not quite following what steps you used with which DSDT but if you use your stock AppleLPC settings (18) and use the 2.1 file posted most recently, it should sync your mobo correctly. If you applied a mod to the kext and used the file "as is" then you would indeed see the overclocking. In the first case I think it was technically backwards even though my board temperature fell...but that's unique to my board. My apologies if that wasn't clear the first time around.

 

I did notice that my system runs much better and faster than ever in 32 bit mode...but at first I'd boot into 64 bit and repair any kext extensions. Then I'd reboot with the arch=i386 command. The main reason is because I have apps that crash in 64 bit mode as I said earlier but even when I test 64 bit I'm noticing much smoother performance with this series of DSDT. So maybe that will work for you as well.

[akhenamenra]

Roger that...

 

Currently Cebu in the sunny Philippines

 

 

 

Ok I'll take a look at see what I can do.

 

Just so I understand, you took the latest DSDT and did the modification to 16...but your system is natively 18? I'm not quite following what steps you used with which DSDT but if you use your stock AppleLPC settings (18) and use the 2.1 file posted most recently, it should sync your mobo correctly. If you applied a mod to the kext and used the file "as is" then you would indeed see the overclocking. In the first case I think it was technically backwards even though my board temperature fell...but that's unique to my board. My apologies if that wasn't clear the first time around.

 

I did notice that my system runs much better and faster than ever in 32 bit mode...but at first I'd boot into 64 bit and repair any kext extensions. Then I'd reboot with the arch=i386 command. The main reason is because I have apps that crash in 64 bit mode as I said earlier but even when I test 64 bit I'm noticing much smoother performance with this series of DSDT. So maybe that will work for you as well.

 

 

see i was thinking to do that too arch=i386 but will the loss be with the ram support

 

ie will it only see 4gb instead of the 9gb??

[Bchemist]

see i was thinking to do that too arch=i386 but will the loss be with the ram support

 

ie will it only see 4gb instead of the 9gb??

 

 

It sees all 12 gig on my board in either 32 bit or 64 bit mode. Actually 10.5 can also use up to 32 gig. There was a really good article that explained all of this with bars and graphs and whatnot that made sense out of all of the whole 64 bit hype since OSX and Windows don't use the basic 4 gigs the same way for the kernel. Windows must always share 50% while Mac doesn't. Again, 32 gigs can be used in 32 bit...but after reading it I just put in the "faith" part of my brain so I'd just accept it rather than ponder it like the time spent leading up to that point....plus it would take 2 hours to write out the explanation

 

One really test I did that struck me as ironic was 64 bit geekbench. I ran it in 32 bit and 64 bit mode a couple of weeks ago. Both times the scores were about 11,000 where actually the 64 bit app running in 32 bit mode beat the same 64 bit app in 64 bit mode. You sit there thinking "and then...." where the "just kidding" pops up and you get the "real" 64 bit score. Same thing with heavy apps like anything from Adobe. There's no difference in speed or simultaneous loading, plus the apps are only allowed to see 3 gig at a time themselves.

 

Some power users have also said that 32 bit is still faster. There must be a bottleneck somewhere that prevents regular macs from booting in 64 bit. Either way just test it and see which you think is faster and more stable.

[akhenamenra]

It sees all 12 gig on my board in either 32 bit or 64 bit mode. Actually 10.5 can also use up to 32 gig. There was a really good article that explained all of this with bars and graphs and whatnot that made sense out of all of the whole 64 bit hype since OSX and Windows don't use the basic 4 gigs the same way for the kernel. Windows must always share 50% while Mac doesn't. Again, 32 gigs can be used in 32 bit...but after reading it I just put in the "faith" part of my brain so I'd just accept it rather than ponder it like the time spent leading up to that point....plus it would take 2 hours to write out the explanation

 

One really test I did that struck me as ironic was 64 bit geekbench. I ran it in 32 bit and 64 bit mode a couple of weeks ago. Both times the scores were about 11,000 where actually the 64 bit app running in 32 bit mode beat the same 64 bit app in 64 bit mode. You sit there thinking "and then...." where the "just kidding" pops up and you get the "real" 64 bit score. Same thing with heavy apps like anything from Adobe. There's no difference in speed or simultaneous loading, plus the apps are only allowed to see 3 gig at a time themselves.

 

Some power users have also said that 32 bit is still faster. There must be a bottleneck somewhere that prevents regular macs from booting in 64 bit. Either way just test it and see which you think is faster and more stable.

 

 

oh ..... interesting

 

does the same apply to the ramblings of the opencl would that be supported on the same basis ie better in 32 bit mode then 64??

[tweak41]

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.

 

Ok. I'm using all but IONetworking. Why do you use it? The LAN is detected natively...not sure you even need a DSDT patch, but I could be wrong. In addition to yours, I'm also using AHCIPortInjector, AppleHDA, EvOreboot (OpenHaltRestart alternative), JMicronATA, and SleepEnabler.

 

Does your sound work without a the AppleHDA kext?

 

Are you able to test whether or not speed stepping is occurring in OS X? I know you can in Windows with a few utilities, but I'm unaware of anything effective at measuring real-time clock speeds. If you know of something, please tell. I have been running without the EVOSpeedStepping kext.

 

I'm shocked you're able to get away with so few kexts. Have you really managed to patch that stuff via DSDT? I guess I'll give it a shot and see. Will be back soon (hopefully) with an edit and thoughts.

 

**UPDATE**

 

Temps are back up to mid 40ºC after loading your latest DSDT and undoing the AppleLPC modification. I'm going to revert back and see if that fixes the issue. If not then maybe I had returned my CPU to stock settings before testing for some odd reason.

 

I managed to chop out a couple of unnecessary kexts in the process, so that was nice. My system seems to be fully functional in 64-bit with 7 kexts and your DSDT. Very nice. Now to see about these speed stepping and heat issues...

 

NOTE: Solution below.

[Bchemist]

Ok. I'm using all but IONetworking. Why do you use it? The LAN is detected natively...not sure you even need a DSDT patch, but I could be wrong. In addition to yours, I'm also using AHCIPortInjector, AppleHDA, EvOreboot (OpenHaltRestart alternative), JMicronATA, and SleepEnabler.

 

Does your sound work without a the AppleHDA kext?

 

Are you able to test whether or not speed stepping is occurring in OS X? I know you can in Windows with a few utilities, but I'm unaware of anything effective at measuring real-time clock speeds. If you know of something, please tell. I have been running without the EVOSpeedStepping kext.

 

I'm shocked you're able to get away with so few kexts. Have you really managed to patch that stuff via DSDT? I guess I'll give it a shot and see. Will be back soon (hopefully) with an edit and thoughts. I have a feeling my system will panic if the JMicron kext is missing.

 

IONetworking is left over from long ago and I've never removed it from the bundle. The hack that I've added to the DSDT would indeed be more than enough so I'll test later without it. I'm not using SleepEnabler but I'm not using 10.6.2 yet...just 10.6.1. Also I haven't removed the audio kexts due to the "if it ain't broke don't fix it" point of view. I already have the audio fix ready to add should I decide to remove the kexts (or if they stop working). I know that in the P5Q, for example, adding an HD audio hack causes a conflict with the voodoo kext so one or the other needs to go.

 

In I/O reg it shows states if C and I've seen it show a status of "2" or "1". Otherwise I just have been watching the CPU usage via different monitoring and it would seem that it's working but there's indeed no real way to verify it. The fact that my system isn't pumping out heat like a toaster anymore is definitely a sure anecdotal sign that something positive is happening now that wasn't happening with the EvoSpeedstepping kext.

 

I've never used JMicron kexts since the beginning. I've even removed the JMicron code in the new series of DSDT and it has been fine so far. So as far as patching with the DSDT if I decide to test later, one by one, I'd remove the networking kexts then add the HD audio patch while removing the kexts, and finally the EvoSpeedstep. So that should bring me down to 6 (or 7..not at that system) kexts. I'd like to believe that the native SATA might make the port injector kext obsolete, but that' another test for another day.

 

A bit later I'll post my version of that 100% patched-for-kext-removal DSDT for those who want to take it to the next level.

 

It should allow you to end up with using only:

 

NullCpu (maybe we don't even need this with AppleLPC?)

PlatformUUID (maybe this can be DSDT hardcoded also?)

fakesmc2.5

OHR (or Evoreboot) (this is also a question mark since so many of the hacks add sleep/reboot support)

 

So could it be possible to only need fakesmc 2.5 with maybe 1-2 more kexts? It seems that we're getting closer where everything would be truly update-proof.

 

 

****Edit****

 

I've been wondering about that also in that maybe there's a version of our board that needs the AppleLPC to be modded in addition to the mod to the DSDT as well as a version that only needs the mod of the DSDT. I also wonder if booting in 64 bit might be the cause of some heat issues.

[tweak41]

A bit later I'll post my version of that 100% patched-for-kext-removal DSDT for those who want to take it to the next level.

 

It should allow you to end up with using only:

 

NullCpu (maybe we don't even need this with AppleLPC?)

PlatformUUID (maybe this can be DSDT hardcoded also?)

fakesmc2.5

OHR (or Evoreboot) (this is also a question mark since so many of the hacks add sleep/reboot support)

 

So could it be possible to only need fakesmc 2.5 with maybe 1-2 more kexts? It seems that we're getting closer where everything would be truly update-proof.

 

 

****Edit****

 

I've been wondering about that also in that maybe there's a version of our board that needs the AppleLPC to be modded in addition to the mod to the DSDT as well as a version that only needs the mod of the DSDT. I also wonder if booting in 64 bit might be the cause of some heat issues.

 

I don't use NullCPU. You can throw it out. The one problem I'm having that's keeping my system from being exactly the way I want it is timed sleep. I can't set sleep for 20 minutes, walk away, and come back to a sleeping machine. Why, I don't know.

 

You can actually get rid of the PlatformUUID kext too and add the UUID to your boot.plist file. So really the only two kexts you'd need are EvOReboot and fakesmc. I tried without EvOReboot and my computer wouldn't restart properly, it would just hang.

 

If there's a way to patch in audio to eliminate a kext, well then, sign me up!

 

Something else I can't figure out is why SleepEnabler is needed. It sleeps fine if I manually put it to sleep, but sleeping on its own isn't ever accomplished with or without SleepEnabler.

 

And if you've got a chance I'd love an opportunity to read anything that may help me learn this stuff too.

 

**EDIT**

 

Bah, it makes no difference for temps whether I patch the AppleLPC kext or not. I must have turned off the overclock when I tested it yesterday. Odd though, because the temps I was getting were on par with my Windows temps WITH the overclock...

 

Ugh, if I forgot to turn on speed stepping after my RAM upgrade this afternoon, I'll be ticked. BRB.

.

..

...

....

.....

......

 

Speed Stepping was enabled, BUT----------> I forgot to re-enable C-STATE. THIS IS ESSENTIAL.

 

Whoops.

 

Temps are back in the mid-30ºC where they belong. Yay!

 

One last thing. I'm 99.9% sure the speed stepping thing is working properly because running an mprime torture test on my machine (as a stability test for overclocking--which I'm sure you're aware of) yields almost identical results when monitoring temps with prime95 on Windows. Although we don't have a good utility to measure clock speeds, this temperature seems to be pretty clear evidence that it is indeed working.

 

Now if only I could get the sleep thing worked out.

[thehackerdude]

Great stuff going on here!

 

I have a few problems. I'm using Bchemist's recent DSDT, system will boot properly but network will not work without NullCPU and IOnetworking. Same with temperature fix, without NullCPU I end at 58C idle. But, when using NullCPU, I'm running at around 50C while under Windows it idles at a little under 40. I don't overclock if it make any difference.

 

Currently using NullCPU, IOnetworking, fakesmc2.5, platformuuid, evoreboot, and evospeedstep

 

Sucker boots and shutdown a lot faster. I'm pretty sure it accesses HD faster as well.

[tweak41]

Great stuff going on here!

 

I have a few problems. I'm using Bchemist's recent DSDT, system will boot properly but network will not work without NullCPU and IOnetworking. Same with temperature fix, without NullCPU I end at 58C idle. But, when using NullCPU, I'm running at around 50C while under Windows it idles at a little under 40. I don't overclock if it make any difference.

 

Currently using NullCPU, IOnetworking, fakesmc2.5, platformuuid, evoreboot, and evospeedstep

 

Sucker boots and shutdown a lot faster. I'm pretty sure it accesses HD faster as well.

 

C-STATE is enabled in your BIOS too? It's under CPU Settings on the third tab in your BIOS (sorry I'm terrible with specific names unless it's right in front of me).

 

I find it odd your networking doesn't work...You on 10.6.1 or 10.6.2?

 

My kexts:

AppleHDA

EvOreboot

EvOSpeedStep

fakesmc

IOAHCIBlockStorageInjector

JMicronATA

PlatformUUID

SleepEnabler

 

I strongly recommend PCI_EFI 10v5 if you aren't already using it.

 

-----

 

In regard to the whole EvOSpeedStepping kext, I still wonder if it's necessary. I get the same temperature results regardless which leads me to believe that maybe it's working fine without the kext. I would think OS X supports this natively because of the Nehalem based Mac Pros.

[thehackerdude]

C-STATE is enabled in your BIOS too? It's under CPU Settings on the third tab in your BIOS (sorry I'm terrible with specific names unless it's right in front of me).

 

I find it odd your networking doesn't work...You on 10.6.1 or 10.6.2?

 

My kexts:

AppleHDA

EvOreboot

EvOSpeedStep

fakesmc

IOAHCIBlockStorageInjector

JMicronATA

PlatformUUID

SleepEnabler

 

I strongly recommend PCI_EFI 10v5 if you aren't already using it.

 

-----

 

In regard to the whole EvOSpeedStepping kext, I still wonder if it's necessary. I get the same temperature results regardless which leads me to believe that maybe it's working fine without the kext. I would think OS X supports this natively because of the Nehalem based Mac Pros.

 

I'm 10.6.1

 

Enabled C-State and no change in temps. I'm hovering 47C.

Yes, using PC_EFI10v5

 

I'll do some more testing tomorrow.

 

EDIT: Temps are lower, but I still have network problems without IOnetworking.

[andrew79]

Using Bchemist 's first dsdt.aml file here. Everything just perfect. 10.6.2 runs smoothly, stable and fast system. I had my bios ubdated to the latest version (ASUS P6T SE 0608). My extra folder contains

AppleHDA.kext

fakesmc.kext (latest netkas version)

HDAEnabler.kext

IOAHCIBlockStorageInjector.kext

JMicronATA.kext

NullCPUPowerManagement.kext

OpenHaltRestart.kext

SleepEnabler.kext

UUID.kext

 

No problems with time machine. Also my cpu temperature is fine 40c idle, and 47c running normal applications and virtual machine. This is not very hot if you consider that a core 2 duo imac runs at these temperatures too.

Sound works too.

I have attached my extra folder in case anyone needs my "kexts compilation"

 

My boot method: Usb stick containing chameleon and all extra kexts etc

This is very useful to me, because if anything goes wrong i can just modify my kexts on the stick using a mac mini that i own. Snow leopard installation remains "clean".

 

Ohhh almost forgot! If you have troubles with scheduled sleep i bet it is your sata dvd rom or printer! Mine did not went to sleep. Changed my printer and plugged an IDE dvd rom and sleep works just fine!

 

my kexts

[_Wolverine_]

guys i need your help

i dont know if speedstep is working

i added the evospeedstep kext and my cpu temp are 44-41 idle

my sleep dont work, it actually work but my radeon 4870 does not work after wake up

 

im using the latest dsdt from bchemist and evospeedstep fakesmc OHR and UUID kexts

 

btw after i removed the nullcpu my hds are showing as removable how can i change this?

 

and can you post your geekbench score and specs?

im getting 8300

i7 920 (not OC)

3gb corsait 1066

radeon 4870

snowleo 10.6.2

[Bchemist]

I just had a chance to skim what was written (lots of interesting findings that are along the same lines of what we are gunning to finish that I'll reply to in a bit for sure) while I've been busy with other things but I think I might have a breakthrough.

 

If universal, then everyone will L-O-V-E this one.

 

This was definitely a case of pattern recognition going back and forth, looking at similar fixes, realizing I was looking at hex code and vice versa for decimal....then I nailed it all at once by just splicing a few different previous hacks from the ever-popular Gigabyte P45 chipset in addition to some generic instructions. On the first attempt...viola...DSDT audio hard-coded to native AppleHD audio! Our built-in audio is now using the vanilla Apple 885 codec instead of the patched 1200 series.

 

I now have 4 built-in outputs, a built-in mic, and a built-in line in natively! I'm not sure if the additional audio kexts gave this functionality before but I don't really care if it means no more audio update headaches

 

We'll call this *3.0* (since obviously making audio unnecessary is a VERY big deal and eliminates another two kexts!) and hopefully it will be solid across the board. I'm nearly ready to make the move to 10.6.2, but I want to see if this fix holds. This should bring the count down to just 5 or less needed kexts? As always, feedback is appreciated.

 

 

Well if this wasn't the epic failure to end all. After clearing my caches I lost audio also since that was the reason. I then verified the strings, created a batch of 1200 strings (even worse) and then dug through the native AppleHDA files to discover that there is no 888/1200 codec! So while this may or not give any benefit (maybe during an update?), at least there is a fix waiting should Apple ever decide to adopt our codec. I left the code as-is in case anyone wants to see it or use it for a different mobo that is compatible.

dsdt.aml.zip

[_Wolverine_]

ill check it in a few minutes

can you check my other post? =P

 

didnt work

tryed with -f too but no help

[Bchemist]

ill check it in a few minutes

can you check my other post? =P

 

didnt work

tryed with -f too but no help

 

 

It may be an issue with your video card since I've seen of similar problems before...unfortunately I have no experience with ATI cards so I can't offer much help.

 

If you are using my latest dsdt file from what I'm reading is that the Evospeedstep doesn't offer any additional benefit on top of the hardcoding to sync up with the AppleLPC.kext and you enable C states and native speedstep in bios.

 

I'm still using the OHR but others are reporting better results using the Evoreboot so you might want to give that a try.

 

I posted that I was using the nullcpu....I forgot that I did indeed trash that 2 weeks ago following a rollback from a crappy 10.6.2 install. If you are having problems with 10.6.2

 

Try adding the following:

 

IOAHCIBlockStorageInjector

 

10.5 EFI boot file

 

If you have those installed and it's still not working add:

 

IOATAfamily.kext

 

If you are still having problems then maybe someone with an ATI card will have insight.

[thehackerdude]

I just had a chance to skim what was written (lots of interesting findings that are along the same lines of what we are gunning to finish that I'll reply to in a bit for sure) while I've been busy with other things but I think I might have a breakthrough.

 

If universal, then everyone will L-O-V-E this one.

 

This was definitely a case of pattern recognition going back and forth, looking at similar fixes, realizing I was looking at hex code and vice versa for decimal....then I nailed it all at once by just splicing a few different previous hacks from the ever-popular Gigabyte P45 chipset in addition to some generic instructions. On the first attempt...viola...DSDT audio hard-coded to native AppleHD audio! Our built-in audio is now using the vanilla Apple 885 codec instead of the patched 1200 series.

 

I now have 4 built-in outputs, a built-in mic, and a built-in line in natively! I'm not sure if the additional audio kexts gave this functionality before but I don't really care if it means no more audio update headaches

 

We'll call this *3.0* (since obviously making audio unnecessary is a VERY big deal and eliminates another two kexts!) and hopefully it will be solid across the board. I'm nearly ready to make the move to 10.6.2, but I want to see if this fix holds. This should bring the count down to just 5 or less needed kexts? As always, feedback is appreciated.

 

Tested it, can't really check if audio works as I use an external sound card. One thing I noticed is the this version breaks my network. I'll test this version without the IOnetworking and see if that works.

 

Also, every so often, reboot will hang at "REALTEK: setactivationlevel:0" seems also consistent as when I reset after it hangs on that, the network doesn't work on the next boot.

 

I'm going to also drop NullCPU and see if temps stay down where they are supposed to be.

 

EDIT: Back to where I started. Bchemist's newest DSDT (3.0) definitely shoots my networking in the foot. But, I was able to ditch the NullCPU kext and keep the lower temps. When I reverted back to his DSDT 2.1, I verified that NullCPU was required to keep lower temps and networking will only work when NullCPU and IOnetworking kexts are present.

 

I'd like to try to ditch IOnetworking if I can but if it's not going to happen, let me know now so I can stop wasting my time.

[e1ement]

I'm using the latest DSDT.aml and sound shows up in System Profiler but not in Preferences > Sound.

 

 

 

 

e1ement

[Bchemist]

I don't use NullCPU. You can throw it out. The one problem I'm having that's keeping my system from being exactly the way I want it is timed sleep. I can't set sleep for 20 minutes, walk away, and come back to a sleeping machine. Why, I don't know.

 

You can actually get rid of the PlatformUUID kext too and add the UUID to your boot.plist file. So really the only two kexts you'd need are EvOReboot and fakesmc. I tried without EvOReboot and my computer wouldn't restart properly, it would just hang.

 

If there's a way to patch in audio to eliminate a kext, well then, sign me up!

 

Something else I can't figure out is why SleepEnabler is needed. It sleeps fine if I manually put it to sleep, but sleeping on its own isn't ever accomplished with or without SleepEnabler.

 

And if you've got a chance I'd love an opportunity to read anything that may help me learn this stuff too.

 

**EDIT**

 

Bah, it makes no difference for temps whether I patch the AppleLPC kext or not. I must have turned off the overclock when I tested it yesterday. Odd though, because the temps I was getting were on par with my Windows temps WITH the overclock...

 

Ugh, if I forgot to turn on speed stepping after my RAM upgrade this afternoon, I'll be ticked. BRB.

.

..

...

....

.....

......

 

Speed Stepping was enabled, BUT----------> I forgot to re-enable C-STATE. THIS IS ESSENTIAL.

 

Whoops.

 

Temps are back in the mid-30ºC where they belong. Yay!

 

One last thing. I'm 99.9% sure the speed stepping thing is working properly because running an mprime torture test on my machine (as a stability test for overclocking--which I'm sure you're aware of) yields almost identical results when monitoring temps with prime95 on Windows. Although we don't have a good utility to measure clock speeds, this temperature seems to be pretty clear evidence that it is indeed working.

 

Now if only I could get the sleep thing worked out.

 

I've read quite a bit of what is posted by Master Chief on C-states, Speedstep and sleep but it's more on the MacPro3,1. They have far worse problems with sleep on the P5 series. But if you haven't been at least stopped in once on those threads you are missing out.

 

I agree to dump the speedstep but it seems to be inert sitting on an external EFI boot. I mentioned it on another post but I wasn't using the NullCPU kext after I don't remember deleting it....but apparently I did somewhere around the time I rolled back to 10.6.1. Ironically it seems that some people still benefit from it. But it seems to be related to peripherals with all things considered equal.

 

Tested it, can't really check if audio works as I use an external sound card. One thing I noticed is the this version breaks my network. I'll test this version without the IOnetworking and see if that works.

 

Also, every so often, reboot will hang at "REALTEK: setactivationlevel:0" seems also consistent as when I reset after it hangs on that, the network doesn't work on the next boot.

 

I'm going to also drop NullCPU and see if temps stay down where they are supposed to be.

 

EDIT: Back to where I started. Bchemist's newest DSDT (3.0) definitely shoots my networking in the foot. But, I was able to ditch the NullCPU kext and keep the lower temps. When I reverted back to his DSDT 2.1, I verified that NullCPU was required to keep lower temps and networking will only work when NullCPU and IOnetworking kexts are present.

 

I'd like to try to ditch IOnetworking if I can but if it's not going to happen, let me know now so I can stop wasting my time.

 

 

If you have an external card you would indeed be wasting your time. The hard-coding I did was to use the system as vanilla as possible so the DSDT would be picking and choosing which kexts it would use, in this case, the stock LAN and the default vanilla HD extension that is most compatible with our onboard sound. In other words, it's going directly to the vanilla Realtek and AppleHDA kernel extensions in S/L/E so your system would be "all or nothing" for said kexts.

 

I'm going to upload my plist files as they may make a difference in this, since all things should be considered equal within reason.

[Bchemist]

It had not occurred to me until now that my smbios and boot plist files might make a difference in this, so I'm adding them to see if that helps any conflicts.

 

Also, I'm booting into 32 bit mode using arch=i386. I noticed that when I boot into 64 bit mode my system heats up immediately as it begins to reindex everything. This will go on for 5-10 minutes and I have a 230 read/200 write SSD and a striped RAID....so most hard drives regular hard drives may take at least twice as long. So this might be what some are seeing. If you try booting into 32 bit mode the indexing takes maybe a minute at most (after coming out of 64 bit for the first reboot) but then it settles down to normal.

 

My method of booting is an external EFI using netkas 10.5. My mouse and keyboard are USB and the EFI boot USB is set to hard drive mode in the bios. Graphics card is Nvidia 9800 GT.

 

My OS is currently 10.6.1

 

Kexts:

 

FakeSMC 2.5

OHR

PlatformUUID (modded to my boot drive)

IOAHCIBlockStorage

AppleRTC (only purpose is to prevent kernel panic and likely unnecessary)

 

What seems to be the common themes:

 

EvoReboot is sounding like a better alternative to OHR

 

At least two systems with ATI cards have not worked with the DSDT. I have no access to an ATI card so I'm stuck as to test it. It might be something simple, however, like using Graphics Enabler set to Yes in the boot plist.

 

Enable your speedstep and C states in bios for maximum cooling.

 

So if your system is set up similar to this, these DSDT will have a good chance at working like a dream come true. As we know, however, even something that may seem insignificant can hose a system as per the highs and lows with the feedback.

 

As it stands, DSDT doesn't seem to be very flexible once it is compiled for OSX unless we are using something that is natively compatible. In my case I'm trying to see if it's possible to add a wireless LAN that can revert back to the stock LAN without having to change the DSDT. I think that this would only be possible if both are hard coded. If there is a way to do IF THEN statements to detect vanilla networking, I'll do my best to incorporate it in a future version.

 

So give each version a try, but with more hacks come more risks of it not matching exactly. I am considering setting up a website or blog to create and test DSDT files and post solutions since it's difficult to wade through info.

 

So to summarize version 3 (since the first major release aka 1.0): Roll back...revert back to the earlier file.

 

Hard coded to detect the vanilla Realtek LAN (eliminating the IONetworking kext externally)

Hard coded to run the legacy vanilla 885 HD kext extension (eliminated 1-2 HD external kexts) What seems to work in the case of changing the code in the DSDT to match the AppleLPC doesn't draw a parallel here.

 

Hard coded to trick the AppleLPC kext into thinking your system matches its pci8086,18 compatibility option. (dropped temperatures and eliminated the need for speedstep or nullCPU)

com.apple.Boot.plist.zip

smbios.plist.zip

[Bchemist]

I'm using the latest DSDT.aml and sound shows up in System Profiler but not in Preferences > Sound.

 

 

 

 

e1ement

 

 

Do you have HD audio fully enabled in bios? Also do you have Plug and Play OS enabled? I just realized that those could be possible thinks to check in addition to seeing if your boot and smbios plists might cause a conflict.

[thehackerdude]

It had not occurred to me until now that my smbios and boot plist files might make a difference in this, so I'm adding them to see if that helps any conflicts.

 

Also, I'm booting into 32 bit mode using arch=i386. I noticed that when I boot into 64 bit mode my system heats up immediately as it begins to reindex everything. This will go on for 5-10 minutes and I have a 230 read/200 write SSD and a striped RAID....so most hard drives regular hard drives may take at least twice as long. So this might be what some are seeing. If you try booting into 32 bit mode the indexing takes maybe a minute at most (after coming out of 64 bit for the first reboot) but then it settles down to normal.

 

My method of booting is an external EFI using netkas 10.5. My mouse and keyboard are USB and the EFI boot USB is set to hard drive mode in the bios. Graphics card is Nvidia 9800 GT.

 

My OS is currently 10.6.1

 

Kexts:

 

FakeSMC 2.5

OHR

PlatformUUID (modded to my boot drive)

IOAHCIBlockStorage

AppleRTC (only purpose is to prevent kernel panic and likely unnecessary)

 

What seems to be the common themes:

 

EvoReboot is sounding like a better alternative to OHR

 

At least two systems with ATI cards have not worked with the DSDT. I have no access to an ATI card so I'm stuck as to test it. It might be something simple, however, like using Graphics Enabler set to Yes in the boot plist.

 

Enable your speedstep and C states in bios for maximum cooling.

 

So if your system is set up similar to this, these DSDT will have a good chance at working like a dream come true. As we know, however, even something that may seem insignificant can hose a system as per the highs and lows with the feedback.

 

As it stands, DSDT doesn't seem to be very flexible once it is compiled for OSX unless we are using something that is natively compatible. In my case I'm trying to see if it's possible to add a wireless LAN that can revert back to the stock LAN without having to change the DSDT. I think that this would only be possible if both are hard coded. If there is a way to do IF THEN statements to detect vanilla networking, I'll do my best to incorporate it in a future version.

 

So give each version a try, but with more hacks come more risks of it not matching exactly. I am considering setting up a website or blog to create and test DSDT files and post solutions since it's difficult to wade through info.

 

So to summarize version 3 (since the first major release aka 1.0):

 

Hard coded to detect the vanilla Realtek LAN (eliminating the IONetworking kext externally)

Hard coded to run the legacy vanilla 885 HD kext extension (eliminated 1-2 HD external kexts)

Hard coded to trick the AppleLPC kext into thinking your system matches its pci8086,18 compatibility option. (dropped temperatures and eliminated the need for speedstep or nullCPU)

 

Would your memory configs in your SMBIOS work on my system or do I have to Config it for my Mem?

 

Is there anything I ought to change in the SMBIOS?

 

Nevermind, Just built my own.

[andrew79]

Bchemist i used your latest dsdt.aml v3. First i removed HDenabler and AppleHDA kexts from my extra folder, but after restart...no sound:( System profiler recognizes the onboard card but no inputs or outputs are available in sytem preferences/sound. I have no other external card connected at the time.

 

I have plug and play os enabled in bios. I also tried with your smbios.plist but no difference...

 

Anyway you have done so much so far that i think all of us should thank you A LOT :censored2:

[Bchemist]

Would your memory configs in your SMBIOS work on my system or do I have to Config it for my Mem?

 

Is there anything I ought to change in the SMBIOS?

 

Actually it doesn't match my memory either but it it shows it as a MacPro4,1 would need to see it. Smbios is just a method of trigger that allows OSX to fit itself to what it expects to be the hardware. I used to think it was purely cosmetic as so many have said, but if I deleted something from a smbios file, the system would crash, not boot, or most commonly, boot without everything enabled. So the key concept is that specific keys are included in the smbios that are close enough. Even if you have less RAM for example, OSX will overcompensate and just fill in the gaps as long as you list that you have more. If you have more RAM than what's listed here, OSX is already fully enabled so that it will easily be able to recognize it. In this case it lists 6 or 8 gigs of RAM but the system "guesses" and writes in generic values for the remaining RAM to equal 12 gig that's fully functional to all apps that would require it.