DSDT - Vanilla Speedstep - Generic Scope (_PR)

[mm67]

With the Scope (_PR) I'm using - operationally it also makes absolutly no difference to me if I use DropSSDt=y or =N

 

D

 

mm67 - this is dump is from MSI P45 Neo??

 

MSI P43 Neo, I guess they are pretty much the same

[FKA]

MSI P43 Neo, I guess they are pretty much the same

 

at £79 for a P45 Neo 3 I'm very tempted ... it's a well spec'ed MB

http://www.vipergaming.co.uk/msi-p45-neo-3...oard-p-458.html

[mm67]

at £79 for a P45 Neo 3 I'm very tempted ... it's a well spec'ed MB

http://www.vipergaming.co.uk/msi-p45-neo-3...oard-p-458.html

 

Yes, that would be a good choice if you just wanted to upgrade your motherboard. I just managed to convince one guy to buy a MSI P55-GD80 instead of a Gigabyte P55 board, he seems to be happy about it.

[FKA]

Yes, that would be a good choice if you just wanted to upgrade your motherboard. I just managed to convince one guy to buy a MSI P55-GD80 instead of a Gigabyte P55 board, he seems to be happy about it.

 

I've actually bricked the 5v rail for the headers on my GB board - not essential but could do with replacing.

I'm not prepared to go i7 untill we get DDR4 - i wait!

 

D.

[mm67]

I've actually bricked the 5v rail for my headers on my GB board - not essential but could do with replacing.

I'm not prepared to go i7 untill we get DDR4 - i wait!

 

D.

 

In that case MSI P45 board would be a good and cheap replacement.

[Aargh-a-Knot]

i can't get pstatechanger to display my pstates. Do I have to use kext helper or something to install voodoopstate? Or can i just place in E/E? I put it in E/E and its not working... but i dont want ot isntall it with kext helper, cause i dont know how ot get rid of it later that way lol.

 

I had the same issue with pstatechanger not working, even though I was putting voodoopstate in the correct place, ie S/L/E (that'a a hint ) What I found to get it to work is to use Kext Utility to repair permissions and rebuild the mkext and do a restart after adding the kext. Before, I was just restarting assuming OSX would rebuild the mkext, but this was not enough. Of course, you can do this stuff from the terminal if that floats your boat, but I like the ease of Kext Utility. To get rid of it when you are done, just send it to the trash and restart, and the mkext will be rebuilt.

[Duvel300]

Hi Guys, Just a quick note on my findings with regards to the 'SSDT' (Gigabyte boards). On most Gigabyte boards all SSDT's are dynamicly loaded except one, this one does the actual loading. Which means that you always will see at least one SSDT in your ACPI table (IORegistry Explorer). Of couse assuming you have "DropSSDT=no". The BIOS will only include a offset for the SSDT in the RSDT when the EIST function is enabled in the BIOS. So an easy way to make sure no SSDT is loaded without using the DropSSDT option is to make sure you disable EIST, again I am talking about Gigabyte boards (35 and 45 series, probably other boards like MSI implement a similiar feature). However disabling EIST means that your DSDT have to provide ALL the information nessecary to get speedstep working properly. Some DSDT's I have seen use an external reference to PDC0 - PDC4 which is used by the PNOT method in the DSDT, these variables will not be initialized properly if the original SSDT is not loaded (PDC's are initialized by the _PDC method for each proc.), although not really important for what we are trying to achieve but still nice to have the proper values in there.

[Master Chief]

Hi Guys, Just a quick note on my findings with regards to the 'SSDT' (Gigabyte boards). On most Gigabyte boards all SSDT's are dynamicly loaded except one, this one does the actual loading. Which means that you always will see at least one SSDT in your ACPI table (IORegistry Explorer). Of couse assuming you have "DropSSDT=no". The BIOS will only include a offset for the SSDT in the RSDT when the EIST function is enabled in the BIOS. So an easy way to make sure no SSDT is loaded without using the DropSSDT option is to make sure you disable EIST, again I am talking about Gigabyte boards (35 and 45 series, probably other boards like MSI implement a similiar feature). However disabling EIST means that your DSDT have to provide ALL the information nessecary to get speedstep working properly. Some DSDT's I have seen use an external reference to PDC0 - PDC4 which is used by the PNOT method in the DSDT, these variables will not be initialized properly if the original SSDT is not loaded (PDC's are initialized by the _PDC method for each proc.), although not really important for what we are trying to achieve but still nice to have the proper values in there.

I sure hope that people have disabled EIST in their BIOS. I mean the Intel SpeedStep Technology will keep interfering with the Apple kext until you disable it. Mac's don't have support for native Intel SpeedStep Technology and thus they have to use kexts. No kext no SpeedStep. Unlike hacks.

 

And since we are trying to make it work the Apple way... I would say: "time to disable it in the BIOS" But... then people will run into issues when they boot into Windows / Linux. Hmm. Time for a boot loader hack maybe (disabling EIST)?

[msm5]

I sure hope that people have disabled EIST in their BIOS.

 

Does this apply to other BIOS options related to p and c states? For example, the Gigabyte BIOS gives the option to enable/disable C1E and thermal monitoring (changes core voltage and frequency based on heat) as well. Should these be disabled and do the kexts also control these functions?

 

Thanks.

[Duvel300]

I sure hope that people have disabled EIST in their BIOS. I mean the Intel SpeedStep Technology will keep interfering with the Apple kext until you disable it. Mac's don't have support for native Intel SpeedStep Technology and thus they have to use kexts. No kext no SpeedStep. Unlike hacks.

 

And since we are trying to make it work the Apple way... I would say: "time to disable it in the BIOS" But... then people will run into issues when they boot into Windows / Linux. Hmm. Time for a boot loader hack maybe (disabling EIST)?

 

 

Hi Master Chief,

 

First of all thanks for all your hard work, your DSDT work was a real 'eye-opener' for me. But back to speed stepping. Having EIST enabled or disabled in the BIOS and using "DropSSDT=YES" will actually not make any difference. The Intel Speed Step Technology is software driven, Windows got it's own drivers to deal with this and are integrated with Windows other PM features. So stepping is not regulated by hardware. Enabling EIST will merely provide the OS with the layer need to control the 'stepping process'. This layer is usually provided through the SSDT (PM_REF etc). Enabling/Disabling EIST and the C states will just update the CFGD to indicate if EIST is enabled, which C stated are supported how many cpus/cores etc. which the OS can query.

[Master Chief]

Hi Master Chief,

 

First of all thanks for all your hard work, your DSDT work was a real 'eye-opener' for me. But back to speed stepping. Having EIST enabled or disabled in the BIOS and using "DropSSDT=YES" will actually not make any difference...

Thank you. Very kind of you.

 

And disabling EIST in the BIOS has one major advantage over DropSSDT=YES being that Chameleon won't have to unload all tables... after they first have been loaded. The RSDT table won't have to be update by Chameleon and ACPI won't have to be re-initialize again. Sounds like a much cleaner boot process to me. Am I missing something?

 

Disabling EIST is the BIOS is unfortunately not a good solution for everyone, but for people (like me) who do not use anything but OS X on their hack, this is the first step towards a much cleaner boot process.

 

Edit: DropSSDT=YES might not be required, at least not for everyone as mm67 demonstrated, but it is (a bit) cleaner. Forcing you to do the right things – like you said – or power states might not work properly. Which to me is a plus.

 

The Intel Speed Step Technology is software driven, Windows got it's own drivers to deal with this and are integrated with Windows other PM features. So stepping is not regulated by hardware. Enabling EIST will merely provide the OS with the layer need to control the 'stepping process'. This layer is usually provided through the SSDT (PM_REF etc). Enabling/Disabling EIST and the C states will just update the CFGD to indicate if EIST is enabled, which C stated are supported how many cpus/cores etc. which the OS can query.

Intel's SpeedStep Technology is a software initiated process yes. Did I state otherwise? Let me check... I did not. Wait. Are you perhaps put on the wrong foot by my use of: "Native"? I use that when I refer to BIOS / ACPI code. Will try to be more specific next time. Thanks!

 

Edit: I should be sleeping by now, but I just realized something: If I am not loading my IST tables anymore, since I removed all Load statements, then why is the Intel SpeedStep Technology still functional? I mean I can even comment out my _PSS object. No PerformanceArray in IORegistryExplorer showing up and it is still functional. Just no voltage changes. So what is controlling it? BTW: It stops functioning after I disable it in the BIOS.

 

Does this apply to other BIOS options related to p and c states? For example, the Gigabyte BIOS gives the option to enable/disable C1E and thermal monitoring (changes core voltage and frequency based on heat) as well. Should these be disabled and do the kexts also control these functions?

 

Thanks.

No. Intel SpeedStep Technology only. Let's do one thing at a time.

 

Now. Disabling EIST in the BIOS will have direct consequences on P and C-States. Same for features like thermal control – when implemented – so please be careful. Especially when you OC your CPU. We really don't want anyone here to toast a CPU. I did once and that was embarrassing enough.

 

And the Apple kext appears to support thermal monitoring, but what if it isn't working (for your board / CPU)? Better safe than sorry right

 

Edit: I forgot to mention that I also disabled C1E support in the BIOS. Everything fine here. It can be done so to speak.

[blackosx]

This is a great thread because it's like being on a journey of discovery. Thanks guys and good research

 

Following what has just been discussed, I thought I would also try disabling EIST in BIOS and removing DropSSDT=Y from my com.apple.Boot.plist and yes, the SSDT tables don't appear in IORegistryExplorer and the RSDT doesn't contain offsets for them either (obviously).

 

The stepping shown in VoodooMonitor seems to be more active now? (maybe not?)

 

I have also tried disabling C1E in BIOS with no adverse affects. I then went on to disable C2/C2E and C4/C4E State Support in BIOS also. Here's pictures of my before and after BIOS settings.

 

However, I am thinking I need C2 & C4 enabled to allow deep sleep of the CPU and to save energy when sleeping. Please can someone confirm? I left the CPU Thermal Monitor 2 enabled as I guess thats sensible.

[sk1nhead]

The stepping shown in VoodooMonitor seems to be more active now? (maybe not?)

 

I have also tried disabling C1E in BIOS with no adverse affects. I then went on to disable C2/C2E and C4/C4E State Support in BIOS also. Here's pictures of my before and after BIOS settings.

 

However, I am thinking I need C2 & C4 enabled to allow deep sleep of the CPU and to save energy when sleeping. Please can someone confirm? I left the CPU Thermal Monitor 2 enabled as I guess thats sensible.

 

same here, tried disabling C1E and and EIST but the voltage and multiplier is jumpy..

 

also is this normal below? core 0 and 1 is different from 2 and 3 - took me about 10 tries to capture it but good thing i got it? SCARY! i'm reverting back before i break something..

 

here are the choices in my bios that i changed

 

CPU Enhanced Halt (C1E): [disable]

CPU EIST Function: [disable]

[mm67]

same here, tried disabling C1E and and EIST but the voltage and multiplier is jumpy..

 

also is this normal below? core 0 and 1 is different from 2 and 3 - took me about 10 tries to capture it but good thing i got it? SCARY! i'm reverting back before i break something..

 

here are the choices in my bios that i changed

 

CPU Enhanced Halt (C1E): [disable]

CPU EIST Function: [disable]

 

That is totally normal, if you had an i7 then you might see all cores having different multis/voltages.

[Aargh-a-Knot]

I mean what if Aargh-a-Knot is right, and people here are indeed still using 'something' from (one of) their SSDT tables? That would be news to me and thus I have to find it out. Annoying maybe, but true.

 

Well, let's see if I can both annoy you and not annoy you in one fell swoop...

 

Now using DropSSDT=Y, I can see my frequency changing along with multiplier and voltage.

 

I mean, WTF? I am certain that before, voodoomonitor was showing the multiplier and voltage changing, but the frequency remaining static. Now, it all changes.

 

So, I guess you don't need to rack you brain on that one.

 

 

On another note, turning off EIST in the BIOS and setting DropSSDT=N, Speedstepping still works as normal. However I noticed that voodoomonitor reports the voltage in the P-States tab as the same for each step. As soon as I turn EIST back on, it shows different voltages for each P-State.

 

EIST ON:

 

EIST OFF:

 

However, in the Status tab, the voltage is indeed changing with each P-State.

 

Purely cosmetic, I'm guessing?

[sw170]

With EIST off my CPU temperatures are about 5-6C higher (mprime)

±40C - EIST on

±46C - EIST off

[Master Chief]

Well, let's see if I can both annoy you and not annoy you in one fell swoop...

 

Now using DropSSDT=Y, I can see my frequency changing along with multiplier and voltage.

 

I mean, WTF? I am certain that before, voodoomonitor was showing the multiplier and voltage changing, but the frequency remaining static. Now, it all changes.

 

So, I guess you don't need to rack you brain on that one.

Another day another step forward. Good for you. Thank you for the confirmation.

 

On another note, turning off EIST in the BIOS and setting DropSSDT=N, Speedstepping still works as normal. However I noticed that voodoomonitor reports the voltage in the P-States tab as the same for each step. As soon as I turn EIST back on, it shows different voltages for each P-State.

 

EIST ON: see post # 1140

EIST OFF: see post # 1140

 

However, in the Status tab, the voltage is indeed changing with each P-State.

 

Purely cosmetic, I'm guessing?

Not here. Different versions of VoodooMonitor maybe? I am using: "Version 1.0.7 (1.0.7d1)".

 

With EIST off my CPU temperatures are about 5-6C higher (mprime)

±40C - EIST on

±46C - EIST off

This must be an indicator that your DSDT isn't fully patched i.e. that you still have some work to do.

 

same here, tried disabling C1E and and EIST but the voltage and multiplier is jumpy..

 

also is this normal below? core 0 and 1 is different from 2 and 3 - took me about 10 tries to capture it but good thing i got it? SCARY! i'm reverting back before i break something..

You've never seen this before have you? Like mm67 said; this is normal behaviour (behavior for the Americana's). A good thing only so to speak.

 

The stepping shown in VoodooMonitor seems to be more active now? (maybe not?)

I have the same – yet to be proven – feeling here.

 

However, I am thinking I need C2 & C4 enabled to allow deep sleep of the CPU and to save energy when sleeping. Please can someone confirm? I left the CPU Thermal Monitor 2 enabled as I guess thats sensible.

No. I don't think so. But more importantly: Did it even work? Do you have C State LED's on your motherboard?

[sw170]

This must be an indicator that your DSDT isn't fully patched i.e. that you still have some work to do.

 

my mistake, temps are actually the same with or without EIST. Turned off all C1,2,4 states in bios and still the same results

added DropSSDT=Y - no change

 

So now Chief: Do I need DropSSDT=Y or not ? (sorry if I missed something, and asking silly questions..)

 

ah, and no sign of any SSDT in IORegistryExplorer with or without DropSSDT=Y

 

Thanks a million

Regards

s

[mitch_de]

Would be very helpful if some dsdt hero explain in an short summary

in which practical cases = by which problem DropSSDT=Y is needed (please NOT only tell "if xyz shown / not shown in IOregistry"!).

Is it only needed if users also copied+modded SSDT parts into dsdt ? (i believe i have that not).

[Master Chief]

...

 

So now Chief: Do I need DropSSDT=Y or not ? (sorry if I missed something, and asking silly questions..)

 

ah, and no sign of any SSDT in IORegistryExplorer with or without DropSSDT=Y..

No. You don't need this option when you disable EIST in the BIOS. Which acts as a master switch.

 

 

Would be very helpful if some dsdt hero explain in an short summary

in which practical cases = by which problem DropSSDT=Y is needed (please NOT only tell "if xyz shown / not shown in IOregistry"!).

Is it only needed if users also copied+modded SSDT parts into dsdt ? (i believe i have that not).

You may need DropSSDT=Yes when you run into problems with the factory SSDT's. And people with EIST enabled in the BIOS might want to use it too, simply because it is cleaner. It is however not required.

[FKA]

That is totally normal, if you had an i7 then you might see all cores having different multis/voltages.

Thanks for clearing this up -

I've only ever seen my multi's change over all cores - voltage does vary -

[Master Chief]

Thanks for clearing this up -

I've only ever seen my multi's change over all cores - voltage does vary -

Too bad for you. Is EIST disabled in your BIOS? If not give it a try.

 

Note: I still think that we should see all cores work independently, just like with a 'normal' Intel Core 2 Duo. It might however be a technical (design) limitation in the Apple kext, but it should work like this. I'll forward this 'issue' to Intel. Done!

[kdawg]

Too bad for you. Is EIST disabled in your BIOS? If not give it a try.

 

Note: I still think that we should see all cores work independently, just like with a 'normal' Intel Core 2 Duo. It might however be a technical (design) limitation in the Apple kext, but it should work like this. I'll forward this 'issue' to Intel. Done!

Just to chime in my cores seem to work independently as pairs. Very seldom do they drift apart but they do, for very brief periods.

 

    Scope (_PR)
   {
       Name (PSS, Package (0x03)
       {
           Package (0x06) { Zero, Zero, 10, 10, 0x00000822, Zero },
           Package (0x06) { Zero, Zero, 10, 10, 0x0000071E, One },
           Package (0x06) { Zero, Zero, 10, 10, 0x0000061A, 2 }
       })
       Name (PSD, Package (0x05)
       {
           0x05,Zero,Zero,0xFC,0x04
       })
       Name (CST, Package (0x04)
       {
           0x03,
           Package (0x04){ResourceTemplate (){Register (FFixedHW,0x01,0x02,0x0000000000000000,0x00,)},One,One,0x03E8}, 
           Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000414,    ,)},0x02,One,0x01F4}, 
           Package (0x04){ResourceTemplate (){Register (SystemIO,0x08,0x00,0x0000000000000415,    ,)},0x03,0x55,0xFA}
       })
       Processor (CPU0, 0x00, 0x00000410, 0x06)
       {
           Alias (PSS, _PSS)
           Alias (PSD, _PSD)
           Alias (CST, _CST)
       }

       Processor (CPU1, 0x01, 0x00000410, 0x06)
       {
           Alias (PSS, _PSS)
           Alias (PSD, _PSD)
           Alias (CST, _CST)
       }

       Processor (CPU2, 0x02, 0x00000410, 0x06)
       {
           Alias (PSS, _PSS)
           Alias (PSD, _PSD)
           Alias (CST, _CST)
       }

       Processor (CPU3, 0x03, 0x00000410, 0x06)
       {
           Alias (PSS, _PSS)
           Alias (PSD, _PSD)
           Alias (CST, _CST)
       }
   }

[Andrew180]

Hi, my cpu is Q8400. I edited my DSDT with three p-states according to output from PStateChanger. I can't see AppleLPC in ioreg. But when i run lspci i get: "Cannot find any working access method. (1)" So i don't know what to do next.

[mm67]

Hi, my cpu is Q8400. I edited my DSDT with three p-states according to output from PStateChanger. I can't see AppleLPC in ioreg. But when i run lspci i get: "Cannot find any working access method. (1)" So i don't know what to do next.

 

You boot with 32-bit kernel or get a newer lspci package that works with 64-bit kernel, sounds like that is your problem