DSDT - Vanilla Speedstep - Generic Scope (_PR)

[Beerkex'd]

Beer person, lol

(I don't know what I was thinking when I chose that name).

 

Yeah there are various totally legit and useful sites that the admins don't like you linking to for whatever reason. i h a c k i n t o s h . c o m and the Chameleon website are two others.

 

lspci for OSX is here:

http://www.x86dev.org/forum/

[keeza]

Beer and this forum, what more does a man need!

 

Thanks for that, got it figured out now. I suspected that was the case but didn't know for sure.

 

Thought I would give my feedback on my setup so far for anyone contemplating going the vanilla speedstep route.

 

Disclaimer: This is based on my findings using my setup (and my limited knowledge) so each individuals experience may be different.

 

Prior to Speedstepping and no disabler kext my temps were up around 55-61 degrees (CPUi) at idle which is way to high IMO. My core voltage for Q9550 I set in BIOS to 1.3v (default). With disabler kext installed temps were around mid 30's which I believe should be my target temps at idle.

 

Adding PStates to my DSDT brought my temps down about 5 degrees (about 55 degrees) but still way to hot at idle. But I was able to get speedstepping working (with a lot of help).

 

Now I would like to get CStates running to see if it has an impact on my temps. I have a compiled dsdt with CStates (no errors this time kdawg ) Im presently looking into what changes I need to make to my dsdt to get AppleLPC loaded and running, which I understand needs to do so in order for CStates to work. I've attached my dsdt and the LSPCI output for guidance as to where to look and change in my dsdt. Any tips on where I should look and change would be appreciated. I will post feedback.

 

Some issues so far:

1)

I have had one lockup so far. Prior to locking up the mouse would start to stutter slightly, then the screen would garbled and black out. I suspect this has to do with my temps. I also run a stock CPU fan so I may need to look at another CPU cooler.

2)

I have 6 PStates. Under the "Status" tab of CPUi I am able to see all my voltages step, but my 6.5 multiplier doesn't show whereas all the other multiplier values step to there specified voltage. The voltage value for my 6.5 multiplier still steps but under the "6" multiplier. Make sense?

3)

Temps are too high. I have tried reducing the core voltage down to 1.25v and changing my PState values accordingly. This has brought the temps down a little but has reduced my Geekbench score dramatically. (7200 prior to speedstepping to 5300 with speedstepping at 1.25v).

4)

With my core voltage reduced to 1.25v I still get some slight mouse stutter. I've ran a dvd and that seems to be fine, temps hovering around 48 degrees.

 

My conclusion:

Speedstepping on my system at this point is working. Temps are too high and I have taken a performance hit. I get some slight mouse stuttering after about 15 minutes after booting and have had one lockup. I want to get CStates enabled to see the effect that has.

 

So I have currently loaded a dsdt with PStates and without CStates, installed VoodooPower mini along with disabler and my temps are howering around 35 degrees at a core voltage of 1.3v. My Geekbench is 6115. (still down but respectable). I wonder if I removed PStates what my Geekbench would be? I'll try it later. System seems very stable.

 

Maybe speedstepping is not worth the hassle with the increased temps and performance hit?

 

I still would like to get it running though as I think that eventually vanilla speedstepping will be a viable alternative to kexts and disabler.

 

i've attached my LSPCI output and my P and C State dsdt, feel free to take a look. Remember though that CStates on my system is not working yet and I am currently using a dsdt with only PStates.

 

 

Hope this may help anyone or confirm what others have found.

 

EDIT:

Removing PStates from my dsdt seemed to make no difference to my temps at idle - Bios Vcore set to auto.

Getting_There_.zip

[Beerkex'd]

00:1f.0 ISA bridge [0601]: Intel Corporation Unknown device [8086:3a16]

This is your LPC device.

 

As you can see, the address of your LPC device is 00:1F.0, so that's what you need to look for in the DSDT.

 

In other words, find something that is listed as Device (XXXX) at ADDR 0x001F0000.

 

You can use the patch from my DSDT (ID 3a16 to 3a18 - someone reading this with a different ID should use one closer to theirs, look up the supported IDs inside AppleLPC.kext), just change the "LPCB" in it to whatever is the name of your LPC Device. Or do the opposite and rename all instances to LPCB. it shouldn't make any difference. Visit zhell's thread first (see link above) if you are unsure which part of the DSDT code is "the patch" and which parts aren't, it's explained in more detail there.

 

However I think you may have a major problem on your hands because I've never seen everything listed as "Unknown Device" like that before. I think you need to fix that but I don't have the faintest idea how or where.

[keeza]

00:1f.0 ISA bridge [0601]: Intel Corporation Unknown device [8086:3a16]

This is your LPC device.

 

As you can see, the address of your LPC device is 00:1F.0, so that's what you need to look for in the DSDT.

 

In other words, find something that is listed as Device (XXXX) at ADDR 0x001F0000.

 

You can use the patch from my DSDT (ID 3a16 to 3a18 - someone reading this with a different ID should use one closer to theirs, look up the supported IDs inside AppleLPC.kext), just change the "LPCB" in it to whatever is the name of your LPC Device. Or do the opposite and rename all instances to LPCB. it shouldn't make any difference. Visit zhell's thread first (see link above) if you are unsure which part of the DSDT code is "the patch" and which parts aren't, it's explained in more detail there.

 

However I think you may have a major problem on your hands because I've never seen everything listed as "Unknown Device" like that before. I think you need to fix that but I don't have the faintest idea how or where.

 

 

The process is not clear at this point.

 

Is this patch an "edit" or an "addition" to the dsdt?

 

I've attached three files, one is the LSPCI file (errors fixed)

The second is the portion of my dsdt which fits the address shown in red.

The third shows the contents of my APPLELPC file.

 

So if I understand right PX40 is my LPC device.

 

So I need to add this to my dsdt??:

 

Device (PX40)

{

Name (_ADR, 0x001F0000)

Method (_DSM, 4, NotSerialized)

{

Store (Package (0x02)

{

"device-id",

Buffer (0x04)

{

0x16, 0x3A, 0x00, 0x00

}

}, Local0)

DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))

Return (Local0)

}

}

)

 

Or do I REPLACE my existing PX40 entry in my dsdt with the above?

And what do I need to edit in APPLELPC??? Just change the 3a18 to 3a16??

 

Sorry about all the questions but this has got me baffled.

Dont want to stuff this up.

KEEZ_LPC.zip

[Beerkex'd]

If Device (PX40) is at the address shown by LSPCI then that is your LPC device.

 

You have to decide whether you want to patch it in the DSDT or in AppleLPC.kext. .You can change the device ID in the kext or in the DSDT. If you do one, don't do the other.

 

The whole point of patching it in the DSDT is that it allows you to load the kext as it is. This is a Good Thing because, if/when Apple decides to update AppleLPC.kext your modification will still be in effect and the kext will load.

 

If you're unsure, read all this, more than once..

http://www.insanelymac.com/forum/index.php?showtopic=168014

And look at Device (LPCB) in my DSDT, posted earlier. If you pay attention you will see that the patch is an addition, not a change to existing data.

 

You need to insert the DTGP method somewhere (look at my DSDT and others), and then, in your PX40 device, the device ID patching code with the proper device ID inserted in it (compare the example code with the code in my DSDT) - it needs to be inserted right before the first LPC subdevice.

 

You've got it backwards in your posted code example - you have to put the device ID that you want your LPC device to have, not the device ID it already has...! Otherwise what's the point. Go back and read fassl's guide again.

[keeza]

If Device (PX40) is at the address shown by LSPCI then that is your LPC device.

 

You have to decide whether you want to patch it in the DSDT or in AppleLPC.kext. .You can change the device ID in the kext or in the DSDT. If you do one, don't do the other.

 

The whole point of patching it in the DSDT is that it allows you to load the kext as it is. This is a Good Thing because, if/when Apple decides to update AppleLPC.kext your modification will still be in effect.

 

If you're unsure, read all this, more than once if necessary:

http://www.insanelymac.com/forum/index.php?showtopic=168014

And look at Device (LPCB) in my DSDT, posted earlier. If you pay attention you will see that the patch is an addition, not a change to existing data.

 

You need to insert the DTGP method somewhere (look at my DSDT and others), and then, in your PX40 device, the device ID patching code with the proper device ID inserted in it (compare the example code with the code in my DSDT) - it needs to be inserted right before the first LPC subdevice.

 

You've got it backwards in your posted code example - you have to put the device ID that you want your LPC device to have, not the device ID it already has...! Otherwise what's the point. Go back and read fassl's guide again.

 

Yes you were right, I had it backwards. Looks like it loads!

Thankyou.

[Dr. Hurt]

I had some free time so I played with this for a while and here's my experience so far.

 

I removed nullcpupm

I added macpro3,1 CST to my DSDT

Created a legacy LPC kext

Added SSDT (on 2 tables were dumped on my system) to DSDT.

 

Results:

AppleLPC loads

No errors whatsoever

P states recognised in cpu-i

Speedstep working (no voltage drop though according to cpu-i)

Shutdown working without open halt restart

Sleep working without sleep enabler.

CPU idle at 30C (vs 50C before adding CST to DSDT)

 

PROBLEM: Sound stuttering when cpu usage is low. I think it's because Speed step keeps on switching too frequently. Loading the CPU fixes the issue but CPU temps rise.

 

Tried to fix issue as follows:

Disabled speedstep and C1E in BIOS, CPU idles at 36C, speedstep stops, sound still stutters.

Removed SSDT from DSDT, and surprisingly speed step still works but I still have the same sound issue.

 

PLEASE HELP!!!

 

Here are my DSDT and SSDT tables:

DSDT_SSDT.zip

[d00d]

PROBLEM: Sound stuttering when cpu usage is low. I think it's because Speed step keeps on switching too frequently. Loading the CPU fixes the issue but CPU temps rise.

Try removing the IRQs from your RTC, TMR and PIC devices.

This works for me on a GA-EX58 with AppleIntelCPUPowerManagementClient, AppleIntelCPUPowerManagement, AppleHPET and AppleLPC.

 

Update:

The IRQ doesn't need to be removed from RTC to fix the stuttering audio issue.

[Dr. Hurt]

Try removing the IRQs from your RTC, TMR and PIC devices.

This works for me on a GA-EX58 with AppleIntelCPUPowerManagementClient, AppleIntelCPUPowerManagement, AppleHPET and AppleLPC.

 

WOW... That actually worked!!

Thanks.

 

Now I have vanilla speedstep and all I had to do was add a Mac Pro 3,1 CST to my DSDT, delete my 2 IRQs, and create a legacy LPC kext.

 

It even works without SSDT.

[yeehaa]

WOW... That actually worked!!

Thanks.

 

Now I have vanilla speedstep and all I had to do was add a Mac Pro 3,1 CST to my DSDT, delete my 2 IRQs, and create a legacy LPC kext.

 

It even works without SSDT.

 

now you could try removing the CST also from dsdt try it, may work.

[Dr. Hurt]

now you could try removing the CST also from dsdt try it, may work.

 

Nope, already tried it.

Gives me evaluation error at startup.

And without legacyLPC (but with CST), I get no error but no speedstep and very high CPU temp.

 

I guess I shouldn't press my luck. I now have a very stable SL install.

[Master Chief]

I got an e-mail from Intel, they received my CPU for investigation. A day later a second one came in stating "2 cores disabled by instructions" and "we cannot comment on the matter due to patent technology".

 

I get a free replacement @9550. Word!

 

WTF! Are they telling me that OS X includes technology to disable our CPUs?

 

Nope, already tried it.

Gives me evaluation error at startup.

And without legacyLPC (but with CST), I get no error but no speedstep and very high CPU temp.

 

I guess I shouldn't press my luck. I now have a very stable SL install.

 

And you have no BIOS settings related to C-States? If yes enable them

[Dr. Hurt]

I got an e-mail from Intel, they received my CPU for investigation. A day later a second one came in stating "2 cores disabled by instructions" and "we cannot comment on the matter due to patent technology".

 

I get a free replacement @9550. Word!

 

WTF! Are they telling me that OS X includes technology to disable our CPUs?

 

 

 

And you have no BIOS settings related to C-States? If yes enable them

 

That sounds scary!!

Did you actually tell them that you're using it with OS X?

 

As for C-states in the BIOS, I only have one option C1E and its already enabled.

[Master Chief]

That sounds scary!!

Did you actually tell them that you're using it with OS X?

Yes I did, but this is not limited to OS X as you can "kill" CPU's in any OS.

 

As for C-states in the BIOS, I only have one option C1E and its already enabled.

Same for me. We either need to accept the CST related errors, or add that custom CST object to our DSDT.

 

Yes you were right, I had it backwards. Looks like it loads!

Thankyou.

How did you get this: "CStateOverride boolean True"? Also note the lack of: "CSTinfo Number 0xsomething".

 

Do have C-State settings in your BIOS?

 

Can you please attach your dsdt.dsl and a dump from IORegistryExplorer?

 

Thanks!

[yeehaa]

How did you get this: "CStateOverride boolean True"? Also note the lack of: "CSTinfo Number 0xsomething".

 

Do have C-State settings in your BIOS?

 

Can you please attach your dsdt.dsl and a dump from IORegistryExplorer?

 

Thanks!

 

you get that if you use a corresponding mac version from ACPI_SMC. i dont know how it works, but if you try with different models in there that have a valid SPx then I think it overrides the stepping value from DSDT and uses the values from the plist.

[Master Chief]

you get that if you use a corresponding mac version from ACPI_SMC. i dont know how it works, but if you try with different models in there that have a valid SPx then I think it overrides the stepping value from DSDT and uses the values from the plist.

It must be me because you use MacPro3,1 and it works. I use it and err.. no dice. But this is most likely the cause of me not using some sort of SMBIOS injection.

[keeza]

How did you get this: "CStateOverride boolean True"? Also note the lack of: "CSTinfo Number 0xsomething".

 

Do have C-State settings in your BIOS?

 

Can you please attach your dsdt.dsl and a dump from IORegistryExplorer?

 

Thanks!

 

Not sure about the Boolean message, wanted to look into that.

 

At this point I don't have a stable system. I had another lock-up whilst Carbon Copying to a backup partition - I was unable to reboot but have fixed that now.

 

I have 4 theories as to why my system is unstable:

 

1) My graphics card has incorrect device id (PCIO instead of GFX????)

2) My Cstates don't have a memory allocation (see my post #258)

3) I have incorrectly added my LPC device in my dsdt (PX40 is my LPC device-see attched LSPCI text)

4) My PState values have been incorectly calculated.

 

Further to number 4 my PState values were calculated from CPUi and P-State calculator.

The formula that CPUi uses to calculate voltage appears to be:

700 + VID x 16 (multiply before addition). This site Link states a different calculation 800 + VID x 12.5 (for Core2 CPU's) but the results are very similar with either calculation.

In P-State calculator you enter a Core Voltage value under CPU Characteristics. If you reduce (or increase) this core voltage the result will be an increase or decrease the power required for the P-State, see example below (second value):

 

0x00000B0F, // 2831 Mhz in hex

0x00017318, // Power required for this PState

0x000000A0,

0x0000000A,

0x00004826,

0x00004826 // FID=8.5, VID=38

 

So I believe that its hard to get these values wrong if using PState calculator (unless the accuracy of the Calculator itself is in question). So while its possible to have varying Core Voltage settings in P-State calculator (under CPU characteristics) this setting has an affect on the P-Sate value it generates, i.e. if you decrease the Core Voltage this will increase the power requirement for the P-State and vice versa.

 

What is in question though, as I don't know the answer (i intend to try it out) is the BIOS settings.

If I have set say 1.3v as my core voltage under CPU characteristics in P-State Calculator should my VCore voltage in BIOS be set to the same (and not set to Auto?) Could the interaction between BIOS under Auto settings and P-State settings in my dsdt under OSX result in the high voltages and be a reason for my instability? Or is it something in my setup?

 

All I am is a humble architect and not a programmer or coder. I have only been using OSX for about a year and my main working machine is currently an imac. when my hack is stable I intend to port everything across to my "G5".

 

In honesty I was ready to drop the C-State P-State additions as it was causing me too much grief (and I don't want to be a pain -- the ---- to anyone.

 

But hey, I built my hack into a G5 case, spent numerous hours getting to this point and enjoyed the ride but I think I've come as far as I can with my present knowledge.

 

I've attached appropriate files if anyone cares to check them for me. It would be appreciated.

 

P.S.

Could my instability be caused by being on 10.5.8???

Should I use fakesmc instead of decrypt?

 

 

I get a free replacement @9550. Word!

 

WTF! Are they telling me that OS X includes technology to disable our CPUs?

 

Congrats on pulling that off! Awesome prcessor especially for overclocking.

 

I didn't know that disabling algorithms existed for processors!

Keez_CState.zip

[keeza]

you get that if you use a corresponding mac version from ACPI_SMC. i dont know how it works, but if you try with different models in there that have a valid SPx then I think it overrides the stepping value from DSDT and uses the values from the plist.

 

Can you confirm the correct procedure for editing the model id in ACPI as referenced above - I suspect I may have done this incorrectly.

I renamed the first instance of MacPro4,1 under <key>CStateDemotionDict</key> to Macpro3,1 and then I renamed every other instance of Macpro4,1 to MacPro3,1 in that kext.

 

System Profiler says I have MacPro2,1.

 

I don't use smbios.plist

 

Maybe that explains my Boolean=True?

 

EDIT:

 

 

This is interesting,

 

I have attached a pic of a comparison made between two separate dumps from Everest, one with C1 enabled in BIOS, the other with C1 & C3 enabled in BIOS. Notice the different values generated. Everything else was identical.

 

C3 dump is the one I'm presently using.

 

Is there a reason why I should use one instead of the other?

[yeehaa]

It must be me because you use MacPro3,1 and it works. I use it and err.. no dice. But this is most likely the cause of me not using some sort of SMBIOS injection.

 

In my case that Boolean thing came up when I used MacBookPro 4,1 or Macbook 3,1. not sure. right now i am using MacPro3,1 and this injection does not result in that Cstate override.

 

Further to number 4 my PState values were calculated from CPUi and P-State calculator.

The formula that CPUi uses to calculate voltage appears to be:

700 + VID x 16 (multiply before addition). This site Link states a different calculation 800 + VID x 12.5 (for Core2 CPU's) but the results are very similar with either calculation.

In P-State calculator you enter a Core Voltage value under CPU Characteristics. If you reduce (or increase) this core voltage the result will be an increase or decrease the power required for the P-State, see example below (second value):

All I am is a humble architect and not a programmer or coder. I have only been using OSX for about a year and my main working machine is currently an imac. when my hack is stable I intend to port everything across to my "G5".

 

In honesty I was ready to drop the C-State P-State additions as it was causing me too much grief (and I don't want to be a pain -- the ---- to anyone.

 

But hey, I built my hack into a G5 case, spent numerous hours getting to this point and enjoyed the ride but I think I've come as far as I can with my present knowledge.

 

I've attached appropriate files if anyone cares to check them for me. It would be appreciated.

 

P.S.

Could my instability be caused by being on 10.5.8???

Should I use fakesmc instead of decrypt?

 

you can get the pstates off your ssdt and edit like this: Get the lowest and highest values from SSDT and interpolate the values in between. I had 3 states in my ssdt tables and now i have 9. and switching is working perfectly. if you are stuck on calculating them by yourself scroll back and you will come across a posting by superhai detailing the process a bit

 

About being a coder, am sure most of the people on this forum are not programmers either. almost all of them do this as a hobby or something. so moot point

 

you should definitely switch to fakesmc (IMO)

 

Can you confirm the correct procedure for editing the model id in ACPI as referenced above - I suspect I may have done this incorrectly.

I renamed the first instance of MacPro4,1 under <key>CStateDemotionDict</key> to Macpro3,1 and then I renamed every other instance of Macpro4,1 to MacPro3,1 in that kext.

 

System Profiler says I have MacPro2,1.

 

I don't use smbios.plist

 

Maybe that explains my Boolean=True?

 

EDIT:

 

 

This is interesting,

 

I have attached a pic of a comparison made between two separate dumps from Everest, one with C1 enabled in BIOS, the other with C1 & C3 enabled in BIOS. Notice the different values generated. Everything else was identical.

 

C3 dump is the one I'm presently using.

 

Is there a reason why I should use one instead of the other?

 

>I have not edited ACPI_SMC info.plist. i have working pstate and no cst errors after i added just my first SSDT table to dsdt. (the first table being CpuPm which points to all the CST and IST tables from within itself)

 

>so what do you use for SMBios injection?

 

>you should be using C3 dump. because the c1 dump does not have the memory addresses to the other cstates.

[Jag Lally]

Hi,

 

I just got my Speedstep to work using AppleIntelCPUPowerManagement thanks to the posting by Master Chief DSDT for P5K PRO. I was stuck and going out of my mind to make it work. It was working with PM Disabler kext. It turns out I was missing the very basics.

 

Asus P5K Pro motherboard doesn't have a SSDT table to dump and I kept getting very confused about how to convert the ubuntu dumped SSDT lines (....CPU1PM..., ....CPU2PM...) from dmesg into DSDT method ubuntu acpi dump. The penny dropped when I looked at Master Chief's DSDT file and realised that I just needed these two in the structure and nothing else. I kept seeing other posting with all sorts of tags like CPU1IST, CPU0CST and wondering what to do in my case.

 

Secondly I needed p state values for my processor E6750. Using the calculator in the first post, and the p states showing in CPU-I, I got the following (not sure if they are 100% correct but they work with very limited testing)

Name (_PSS, Package (0x03)
		{
Package (0x06) { 0x00000A68, 0x000157C0, 0x0000000A, 0x0000000A, 0x0000082A, 0x0000082A },
Package (0x06) { 2331, 46352, 10, 10, 0x71A, 0x71A }, // 7
Package (0x06) { 1998, 37600, 10, 10, 0x616, 0x616 }, // 6
		})

 

 

Thirdly, I was totally lost on the _CST method.

 

Finally I needed to make sure my model was correctly set as MacPro3,1 in smbios.plist, DropSSDT=Yes in Boot.plist. Then it worked.....

 

Anyway, thanks to Master Chief's posting I was able to use the information from his DSDT file to get my working. I'm attaching mine just incase it proves useful to someone. It was dumped using ubuntu, errors fixed and then fixed for ALC883, Nvidia 8600 GT 512mb, Time machine fix for Marvell Yukon 88E8056 and other fixes. I'm using BIOS 1303.

 

I haven't fully tested but it seems to be working apart from

oKitWaitQuiet timeout waiting to write kernel symbols

error. But I'm not going to bother to try to fix this as I'll be trying Snow Leopard as soon as the DVD arrives in the post.

 

A big thankyou to Master Chief

 

update New dsl file uploaded. The old one had control characters in it. This one also includes a sata change to make it appear as ESB2 as well.

 

Jag

AsusP5KPro.zip

[spanakorizo]

man the .dsl has 63 errors to compile

you -f this?

[Master Chief]

I still don't get why you use such old Chameleon on leopard, why not use latest RC3?...

Because Chameleon has serious compatibility issues with certain drives, one being my 1TB SAMSUNG HD103SJ. And Chameleon v2 RC3 won't even boot from a USB stick, when this drive is connected to any of the SATA ports. Please note that I installed Snow Leopard from the very same USB stick to the very same HD (new/blank at that time) so this must be related to some of Chameleons' partition reading code.

 

A bug was filed on: May 06, 2009, 01:21:50 PM see also forum.voodooprojects.org/index.php/topic,310.0.html but that bug is still not fixed!

 

man the .dsl has 63 errors to compile

you -f this?

The: "^ Invalid character (0x0D), expecting ASL keyword or name" error occurs when people copy/paste the dsdt and/or save it in the wrong format.

 

@Jag: Thank you, and great to see that you managed to get it going. However, please attach a dsdt.dsl that can be compiled without errors

[mm67]

Does this mean that speedstep is working ?

 

[keeza]

In my case that Boolean thing came up when I used MacBookPro 4,1 or Macbook 3,1. not sure. right now i am using MacPro3,1 and this injection does not result in that Cstate override.

 

 

 

you can get the pstates off your ssdt and edit like this: Get the lowest and highest values from SSDT and interpolate the values in between. I had 3 states in my ssdt tables and now i have 9. and switching is working perfectly. if you are stuck on calculating them by yourself scroll back and you will come across a posting by superhai detailing the process a bit

 

About being a coder, am sure most of the people on this forum are not programmers either. almost all of them do this as a hobby or something. so moot point

 

you should definitely switch to fakesmc (IMO)

 

 

 

>I have not edited ACPI_SMC info.plist. i have working pstate and no cst errors after i added just my first SSDT table to dsdt. (the first table being CpuPm which points to all the CST and IST tables from within itself)

 

>so what do you use for SMBios injection?

 

>you should be using C3 dump. because the c1 dump does not have the memory addresses to the other cstates.

 

FakeSMC has been installed and appears to work fine on 10.5.8 (Leopard version).

 

P-States are working for me but temps are too high hence the need for C-States.

 

I think the ACPI_SMC edits I have made holds the key as to why C-States are recognised but not loading.

Should I perhaps forget about editing acpi_smcinfo.plist file and focus on looking at my smbios injection? I'm thinking that somehow an incompatible MacPro model is being injected and not allowing C-States to load, which you suggested could be the reason for the Boolean message in a post above.

 

For smbios injection I have currently applesmbiosefi kext although I'm trying my system now without it and using a smbios.plist instead. I'm looking now for a template file so that I can create my own.

 

Is creating a smbios.plist the correct way to change your model ID? I want to try different model ID's to see if they hold the key to unlocking this mystery.

 

Working C-States is within my grasp.....

[mm67]

Just noticed that fixing the speedstep also had a nice side effect. Now I can use my usb keyboard and mouse to wake up from sleep. This never worked before on my EP45-UD3.