DSDT - Vanilla Speedstep - Generic Scope (_PR)

[Master Chief]

Hey, thanks for replying,

 

I still don't understand somethings though,

 

About p-states calculator ? All it does is convert from specific values I set to hex values for the PSS table,

How do i know what power in [mW] or voltages to enter in the first place ? multiplier and speed is easy, though I'm not sure if there are more than just 6,7,8,9 ?

You can easily verify all this with help of CPU-i (P-States) which works for me here.

 

About c-states in cpu-i ? where do i see that ? I can see only speed, multiplier and voltage, am I missing a column ?

No, and like I said; it should drop power. That's a pretty clear indicator.

 

About deep sleep ? I tried Smartsleep prefPane (deep sleep widget has a bug in SL) which sets these values of hibernation mode, then I put my hackintosh to sleep, before sleep it gave me the gray screen of deep sleep, and went to sleep, but when I powered it up, it just booted normally, not from the sleep image, then I checked and saw that there was a saved sleep image on disk, I don't understand, how does Chameleon (I'm using RC1) knows if there is a sleep image or not ? and how to boot ? or maybe OS X needs to tell the bios it is not a regular boot ?

I can't answer all your questions here, since they are unrelated to the matter at hand. But about that bug; Why don't you e-mail Matthieu Beaumel – the author of this widget – and tell him about the bug

[William Parker]

As appears you do have a clear insight into this issue of pstate values for fractional multiplers as used in the Q9550. But since I do not quite understand coding like you, I will appreciate if you explain how to obtain values for the pstate entries in DSDT for the 8.5, 7.5, and 6.5 multipliers which I am unable to obtain from the p-states calculator app.Another thing I notice is that the calculator does not take vcore values I specify, instead snapping onto values built in. I plan on sticking to values presented by the CPU-i tool p-states tab. As of now I have 3 stepping states integrated into the DSDT which are working as indicated by CPU-i tool. It sure is a relief to see the temps go back to normal - 12 degrees c. lower, sure bring on a sigh of relief. Initially I had problems getting AppleIntelCPU... To load. I enabled all EIST related items in BIOS & it worked. I have no errors of any kind in my logs, at least none related to Cpu or stepping like _cst & the like.Any ideas?

Seems like bit 14 (0x4000/16384) is set for all fractional multipliers i.e. add a 4 in front of the values supplied by the P-States Calculator (0x4720 is working here for 7.5).

 

Update: I checked the source code of CPU-i and that appears to be correct. Have a look:

#define FID(ctl) (((ctl) & 0xff00) >> 8)
#define VID(ctl) ((ctl) & 0x00ff)
   
columnIdentifier = [NSString stringWithFormat:@"x %d%s", fid & 0x1F, fid & 0x40 ? ".5" : ".0" ];
   
PStatesArray[i].Multiplier =  (fid & 0x0f) + (fid & 0x1F, fid & 0x40 ? 0.5 : 0.0);

But the error checking is... well there is none so I don't know what the API returns.

[cyberface]

.....

Once you have SSDT tables they are appended to your DSDT using this method here.

.....

 

Link does't work

[yonika]

You can easily verify all this with help of CPU-i (P-States) which works for me here.

 

 

No, and like I said; it should drop power. That's a pretty clear indicator.

 

 

I can't answer all your questions here, since they are unrelated to the matter at hand. But about that bug; Why don't you e-mail Matthieu Beaumel – the author of this widget – and tell him about the bug

 

Well, Just to make sure i'm not hallucinating, I attached 2 screen shots of my CPU-i application,

 

I can't see any power indicator, and there is no help for cpu-i, maybe i'm using the wrong app ?

 

10x,

Jonathan

[xopher]

Anyone here with a Q8400? I'm trying to figure out the right p-states for it.

 

I have three active, and working now, the ones I got from CPU-i (post) but I believe it should support more than that. So if anyone has a Q8400 working with all the supported p-states, let me know!

 

Thanks for the guide(s) guys!

 

Edit: The frequency, mW, and Control of the first (p-state 0) and last p-state (2), were in the _PSS I extracted. Would this suggest that they are the min and max values? [2000mhz and 2667mhz]

 

The third one I added from the CPU-i output [2333mhz], but I changed P to something in between that of states 0 and 2. Is there a way of calculating this?

[Superhai]

About p-states calculator ? All it does is convert from specific values I set to hex values for the PSS table,

How do i know what power in [mW] or voltages to enter in the first place ? multiplier and speed is easy, though I'm not sure if there are more than just 6,7,8,9 ?

 

I can tell you a bit about P-states and how you can create them. This tutorial require terminal, so if it scares you look away now.

 

We start by running Reggie SE from terminal:

 

reggie_se -r -i0 -a 0x198 -B 64

 

Which should give you something like this (if it doesn't try to add -D Yonah after)

 

Address 0x00000198 0x0927092706000721 |0 0 0 0|1 0 0 1|0 0 1 0|0 1 1 1|0 0 0 0|1 0 0 1|0 0 1 0|0 1 1 1|0 0 0 0|0 1 1 0|0 0 0 0|0 0 0 0|0 0 0 0|0 1 1 1|0 0 1 0|0 0 0 1|

 

This is the IA32_PERF_STATUS MSR.

 

I will break it down for you the most important parts:

 

0x0927092706000721

This is the current hardware "P-state", as I see you have mentioned elsewhere here it is part FID (0x07) and VID (0x021) I will tell a bit about calculations of those later.

0x0927092706000721

This part is a couple of flags. I will not go in details here (ask if interested, in short if some are set they tell you that you are in a EST transistion or there is a THERM event.

0x0927092706000721

This is the lowest bus ratio (multiplier) supported by the CPU. It is almost always 0x06 (if it is 0x00 it is pre-core type cpu and is reserved)

0x0927092706000721

This is max hardware "P-state"

0x0927092706000721

And this is system boot hardware "P-state", this is usually the same as max on desktop/server cpus and the minimum supported on mobile cpus.

 

Hardware "P-state"

As you may know this already it resolve to a frequency and voltage id. It is a 16 bit value, and has changed somewhat from technology changes at Intel. We use the above current "p-state" as an example.

 

The first 6 bits (0 to 5) is the VID value and here it is 0x27. There are a bit of myths about these ID's as Intel refuse to publish these to the public, but only to chosen fews among the BIOS devs. They do however correlate to the hardware VID's as published in the processor datasheets. And to make this clear once and for all, the VID stepping for Core class (Core 2 Duo, Core Solo/Duo, Atom etc.) are 12.5 mV. Only the Pentium M class CPU uses 16.0 mV. On this CPU here I used in the example a E6600 dekstop CPU the EST VID table starts at 825.0 mV, on mobile and newer core cpu's the table starts at 712.5 mV. Pentium M class CPU's has a table that starts at 700.0 mV. Netburst uses a bit akward table and i7 have a finer graded one. If you need more info I can take it later. In this case the cpu runs at 1237.5 mV. The next 2 bits are reserved.

 

Bits from position 8 to 12 is the bus ratio. In this case 0x7 means a bus ratio of 7. Most of you know that the cpu frequency is the product of bus ratio and bus frequency, I have a 266 MHz bus frequency so it is running at ~1866 MHz now. The next bit (13) is the non-integer-bus-ratio or half-multiplier bit, setting it will "add" half bus frequncy to the final running CPU frequency or in other words add half a multiplier so you could use 7.5x. The next bit (14) is the Dynamic FSB or SLFM mode bit (support is found in IA32_EXT_CONFIG MSR) and is usually used to get frequencies below the normal 6x multiplier (usually to get the CPU down to 600MHz or 800MHz).

 

So as you see you now know enough to find max hw "p-state". So how to find the lowest? FID is easy as you know the multiplier, and you can find out if your cpu supports SLFM - you add its bit to it. VID is a bit tricky, you can check the intel datasheets, but it is not always clear. If you have a laptop it is usually booted in the lowest "p-state" and you can therefore use it. For desktops it is more a guess, but if you are lucky your m/b producer have added a low p-state to your _PSS already. In other cases you will need to try and test. To make intermediate p-states, you just find some values that are between max and min. Commonly is to use one extra which is somewhat in the middle, or one p-state for each full multiplier, but you are really free to experiment. Also using lower vid values are possible (i.e. undervolt), but on higher fids it might cause issues, so try and test is the mantra.

 

If you want to set a specific hardware "P-state" you use MSR 0x199. You may use reggie_se to do this, an example:

 

reggie_se -w 0x0927 -i0 -a 0x199 -B 64

 

This will set it to the max P-state as you see from above, you can try other values, but be aware that setting values with too high fid and too low vid could cause a freeze of your system. You cannot set a value higher than max. (-i0 is CPU0, -i1 is CPU1, -ia could be used for all CPU's) For IDA (Intel Dynamic Acceleration) it will engage automatically and needs bit 32 set to 1 to disengage.

 

To find Power output for the _PSS value you should check the cpu datasheet, you need some basic electrical background to know what to look for, and usually is of minor interest as most boards are designed to provide enough juice to the CPU. Using after-market CPU upgrades on laptops might be another issue. But laptops usually have defined _PSS, so use the values there, and to create something in between just calculate.

 

Is this helpful for you?

[yeehaa]

@cyberface: from google cache

http://74.125.95.132/search?q=cache:J1jCp7...lient=firefox-a

 

 

@Master Chief: can you please help me with integrating my ssdt into dsdt?

I have my pstates in dsdt already and working. now decided to transfer all the ssdt tables so that i have working cstates too. but then i get this error "operation region" referring to the ssdt table address (you solved this in post #71). Being a newbie have no idea how to solve this. i am attaching all my tables here. please have a look when u can!

 

ACPIDump: acpi dump from Ubuntu. contains the facp table and all the 6 ssdt tables.

ACPIDump.zip

 

mine.dsl: my dsdt with various fixes and additions. i have inserted all the ssdt tables and it gives me 8 errors (in 4 locations) where it refers to the IST and CST from SSDT. (one thing i dont understand here is, i dont see an IST1 or CST1 memory reference anywhere! another thing is NPSS. that too is missing)

mine.dsl.zip

 

thanks in advance

 

@Super hai: patiently waiting for your voodoopower and voodoobattery for Snowleopard 64!

[Brett Whinnen]

Hmm all I get is:

 

bash-3.2# reggie_se -r -i0 -a 0x198 -B 64

WARNING: Could not determine processor information.

WARNING: Could not determine memory controller information.

WARNING: Could not determine Operating System information.

ERROR: unknown processor type

 

bash-3.2# reggie_se -r -i0 -a 0x198 -B 64 -D Yonah

WARNING: Could not determine processor information.

WARNING: Could not determine memory controller information.

WARNING: Could not determine Operating System information.

. 4.7.1 (260)

CPU0 - Yonah (MANUALLY SELECTED)

ERROR: unable to read register

 

So I guess it is having issues recognizing the T9300 properly. Coolbook (32 and 64bit) shows the pstate transitioning working as does MSR Tools (32bit). IO Reg explorer shows all the Penryn bits loaded...

 

 

@cyberface: from google cache

http://74.125.95.132/search?q=cache:J1jCp7...lient=firefox-a

 

 

@Master Chief: can you please help me with integrating my ssdt into dsdt?

I have my pstates in dsdt already and working. now decided to transfer all the ssdt tables so that i have working cstates too. but then i get this error "operation region" referring to the ssdt table address (you solved this in post #71). Being a newbie have no idea how to solve this. i am attaching all my tables here. please have a look when u can!

 

ACPIDump: acpi dump from Ubuntu. contains the facp table and all the 6 ssdt tables.

ACPIDump.zip

 

mine.dsl: my dsdt with various fixes and additions. i have inserted all the ssdt tables and it gives me 8 errors (in 4 locations) where it refers to the IST and CST from SSDT. (one thing i dont understand here is, i dont see an IST1 or CST1 memory reference anywhere! another thing is NPSS. that too is missing)

mine.dsl.zip

 

thanks in advance

 

@Super hai: patiently waiting for your voodoopower and voodoobattery for Snowleopard 64!

 

You can get away with defining NPSS as external.

 

External (NPSS, IntObj)

 

Just do it under which ever CPU is needing it. This seems to work fine. The sad thing is I don't know where it is defined *sigh* I have my DSDT and 6 SSDT tables dumped and cannot find any reference to it.

 

Errors:

 

1 - 8. SSDT unknown reference, you need to get the SSDT table from SSDT0 and insert this into your DSDT before your _SB statement where your Processor definitions are e.g. before your block:

 

Name (CFGD, 0x053969F1)

Name (\PDC0, 0x80000000)

Name (\PDC1, 0x80000000)

Name (\PDC2, 0x80000000)

Name (\PDC3, 0x80000000)

Name (\SDTL, Zero)

 

The code would look similar to:

 

 

Scope (\)

{

Name (SSDT, Package (0x0C)

{

"CPU0IST ",

0xDFE72CB4,

0x02C8,

"CPU1IST ",

0xDFE72F7C,

0xC4,

"CPU0CST ",

0xDFE7264A,

0x05E5,

"CPU1CST ",

0xDFE72C2F,

0x85

})

Name (CFGD, 0x013369F7)

Name (PDC0, 0x80000000)

Name (PDC1, 0x80000000)

Name (SDTL, Zero)

}

 

Which is from my DSDT.dsl.

 

Hope that helps.

 

Does anyone have a copy of a Voodoo kernel I could use to load with kprintf=1 that would work with SL, or would I need to go back to Leo for this?

 

Cheers

Brett

[yonika]

I can tell you a bit about P-states and how you can create them. This tutorial require terminal, so if it scares you look away now.

...They do however correlate to the hardware VID's as published in the processor datasheets. And to make this clear once and for all, the VID stepping for Core class (Core 2 Duo, Core Solo/Duo, Atom etc.) are 12.5 mV.....

 

....To find Power output for the _PSS value you should check the cpu datasheet, you need some basic electrical background to know what to look for, and usually is of minor interest as most boards are designed to provide enough juice to the CPU. ....

 

Is this helpful for you?

 

10x man for the great explanation, I knew some of the details but was not aware to each and every bit in the register.

Well, I am an electrical engineer so I will look into intel's data sheets.

 

The thing that scared me the most was the power in mW in each p-state, I don't really want just to experiment with that, I will look in the data sheet and see if something there's helpful.

 

There's just one thing I haven't figured out yet, Master Chief said something about seeing the power value in CPU-i drop to 0.5 and go up to 1.0 if I have c-states working, I just could not find anywhere on CPU-i this information.

 

Where the heck to I see this info ??? and if not that info, how can I see if c-states are changing ?

 

10x again,

Jonathan.

 

P.S - does manual throttling in CPU-i work for anyone ?

[xopher]

There's just one thing I haven't figured out yet, Master Chief said something about seeing the power value in CPU-i drop to 0.5 and go up to 1.0 if I have c-states working, I just could not find anywhere on CPU-i this information.

 

Where the heck to I see this info ???

 

http://www.insanelymac.com/forum/index.php...st&id=56616

 

The voltage value is what MasterChief is referring to. It should drop to the value designated in your _PSS when Speedstep changes multiplier when eg. idle. If it falls to 0.5 you should have C-states working, because it reduces the power consumption even further.

[Superhai]

@Super hai: patiently waiting for your voodoopower and voodoobattery for Snowleopard 64!

 

VoodooBattery have been available for at least 6 months, VoodooPower needs some rewrite as I need to find another way to get to IOCPU as kpi.private needs now applesigned kexts.

 

ERROR: unable to read register

So I guess it is having issues recognizing the T9300 properly.

It should still be able to read the register, maybe some temporary blocking somewhere.

[xopher]

VoodooBattery have been available for at least 6 months, VoodooPower needs some rewrite as I need to find another way to get to IOCPU as kpi.private needs now applesigned kexts.

 

Hi! Just out of curiosity, could you describe how VoodooPower.kext works/will work? Just a short description or a link to a page/post/thread will suffice.

 

I just got DSDT speedstep working, and the real question is actually where VoodooPower gets its p-states from :-)

 

Thanks!

 

PS. Still looking for more p-states for Q8400, if anyone has them configured, please let me know.

PPS. Could you see the working p-states in eg. windows, where the speedstepping works as designed?

[Superhai]

The thing that scared me the most was the power in mW in each p-state, I don't really want just to experiment with that, I will look in the data sheet and see if something there's helpful.

It is only used for comparing if the power from power source is enough for that p-state, most cases it is ignored.

[xopher]

It is only used for comparing if the power from power source is enough for that p-state, most cases it is ignored.

 

So what would happen if you'd insert Zero instead of [insert mW], nothing? - if the PSU can pull it off that is?

[WinstonAce]

Hello

I've use this method (Thanks FormerlyKnownAs) for enabling speedstep on my system

I found out that I didn't need any cst tables,

only used the cpupm table and two cpuist tables (core 2 duo) and entered my p-states into spss/npss

and it work just fine.

Is there any benefit to adding the cst tables?

why does it work without them if they are needed?

 

Attached the dsdt.dsl with the modification I used.

 

p.s. (a little bit off topic) is there a way to fix shutdown/restart through dsdt without using kext (like openhaltrestart)?

 

Thanks to all

dsdt.dsl.zip

[Master Chief]

I can tell you a bit about P-states and how you can create them. This tutorial require terminal, so if it scares you look away now.

 

We start by running Reggie SE from terminal:

 

reggie_se -r -i0 -a 0x198 -B 64

 

Which should give you something like this (if it doesn't try to add -D Yonah after)

 

...

Mine always returns: 0x061a472006004720 And for all cores. Even when CPU-i and what's that name MSRTool both are showing P-State throttling. Setting a P-State also doesn't work – nothing really changes.

[yonika]

http://www.insanelymac.com/forum/index.php...st&id=56616

 

The voltage value is what MasterChief is referring to. It should drop to the value designated in your _PSS when Speedstep changes multiplier when eg. idle. If it falls to 0.5 you should have C-states working, because it reduces the power consumption even further.

 

10x,

 

Well, power and voltage are two really different things, that's why I did not understand that.

do you know how much time I have to wait for it to drop ? I guess it just happens when the cpu is really really idle

because it takes more time to change c-states.

 

Jonathan

[yeehaa]

 

You can get away with defining NPSS as external.

 

External (NPSS, IntObj)

 

Errors:

 

1 - 8. SSDT unknown reference, you need to get the SSDT table from SSDT0 and insert this into your DSDT before your _SB statement where your Processor definitions are e.g. before your block:

 

Name (CFGD, 0x053969F1)

Name (\PDC0, 0x80000000)

Name (\PDC1, 0x80000000)

Name (\PDC2, 0x80000000)

Name (\PDC3, 0x80000000)

Name (\SDTL, Zero)

 

Hope that helps.

 

Thanks for the help.

I also couldnt find any NPSS definitions either. still dont know where it is!

 

Yes. adding that address location table will remove the compile errors. but they are again referencing the hard coded memory addresses for the table rather than taking the values i copied over to the DSDT from my ACPI dump. Master Chief has some experience in this particular area. that was why i posted the question here.

Does anybody know how to do this? I mean, how to point to the CST, IST tables in the DSDT rather than referencing to the address location?

 

VoodooBattery have been available for at least 6 months, VoodooPower needs some rewrite as I need to find another way to get to IOCPU as kpi.private needs now applesigned kexts.

I meant these kexts for SL 64 bit. I did try your experimental voodoobattery, but it failed to load in 64 bit mode and then saw a reference on your forum mentioning that it is a known issue.

[Superhai]

I meant these kexts for SL 64 bit. I did try your experimental voodoobattery, but it failed to load in 64 bit mode and then saw a reference on your forum mentioning that it is a known issue.

Some did report issues, but it should work. I recompiled it recently with the SDK of final Snow Leopard.

[Brett Whinnen]

Thanks for the help.

I also couldnt find any NPSS definitions either. still dont know where it is!

 

Yes. adding that address location table will remove the compile errors. but they are again referencing the hard coded memory addresses for the table rather than taking the values i copied over to the DSDT from my ACPI dump. Master Chief has some experience in this particular area. that was why i posted the question here.

Does anybody know how to do this? I mean, how to point to the CST, IST tables in the DSDT rather than referencing to the address location?

 

 

I meant these kexts for SL 64 bit. I did try your experimental voodoobattery, but it failed to load in 64 bit mode and then saw a reference on your forum mentioning that it is a known issue.

 

Gotcha. There is a post in this thread that details how to do that with the Voodoo Kernel and using the kprintf=1 kernel flag. This will print out the locations it is looking for each of the IST and CST tables. You can then substitute these values in the SSDT definition in your DSDT instead of the in-built ones.

 

I'm thinking I'll have to resurrect my Leopard install to do this though

 

As to the SL 64bit compiled kexts I have the Voodoo Battery one if you want it, don't have Voodoo Power as I don't use it.

 

Cheers

Brett

 

 

It should still be able to read the register, maybe some temporary blocking somewhere.

 

Well that is strange. I get the same results in both 32bit and 64bit modes...

 

Wonder what is causing it. I also wonder if it is why the OS reports back Unknown as the CPU type...

[Dr. Hurt]

I have just found out that speed step is working fine without me doing anything - No errors, no nothing. I'm using a fully vanilla 32-bit 10.6.1 system (specs below). DSDT.aml and some kexts in the /Extra folder (in the pics below). I have neither dumped nor merged SSDTs. This only happens when I have nullCPUPM in /Extra folder. If I remove NullCPUPM, I get no speed step and higher CPU temps.

Is this normal?

1.tiff

2.tiff

3.tiff

DSDT.aml.zip

[Master Chief]

@Master Chief: can you please help me with integrating my ssdt into dsdt?

 

I have my pstates in dsdt already and working. now decided to transfer all the ssdt tables so that i have working cstates too. but then i get this error "operation region" referring to the ssdt table address (you solved this in post #71). Being a newbie have no idea how to solve this. i am attaching all my tables here. please have a look when u can!

 

...

 

mine.dsl: my dsdt with various fixes and additions. i have inserted all the ssdt tables and it gives me 8 errors (in 4 locations) where it refers to the IST and CST from SSDT. (one thing i dont understand here is, i dont see an IST1 or CST1 memory reference anywhere! another thing is NPSS. that too is missing)

mine.dsl.zip

 

thanks in advance

I had a quick look at your files and looking at it; you have C-State support built in. The first question is: Did you enable it in the BIOS? I ask this because the latencies in the FACP are not good (see post #46) i.e. these values are in fact preventing it from entering C2/3. You might want to do another ACPIdump but this time with the BIOS settings enabled for it.

 

Also, you should be able to boot without CST related errors. And this without any CST related modification in your DSDT. And when this is not the case, then we simply have to figure out how to make it work.

 

P-State related modifications like frequencies and what not can be done by only adding a _PSS object to the first Processor declaration. The rest of the files will use it, and when not, then they are not loading. Which would be another problem to solve, but one that can be solved already.

 

p.s. You couldn't find NPSS simply because it does not exist. In fact your _PSS object represents the actually NPSS

 

I have just found out that speed step is working fine without me doing anything - No errors, no nothing. I'm using a fully vanilla 32-bit 10.6.1 system (specs below). DSDT.aml and some kexts in the /Extra folder (in the pics below). I have neither dumped nor merged SSDTs.

Yup me too (see post #65) but p-states are easy, unlike c-states.

 

This only happens when I have nullCPUPM in /Extra folder. If I remove NullCPUPM, I get no speed step and higher CPU temps. Is this normal?

I can't really answer this because I don't use any disabler since... I can't even remember when. However, a higher temperature appears to be normal (might be due to another kext however).

 

 

10x,

 

Well, power and voltage are two really different things, that's why I did not understand that.

do you know how much time I have to wait for it to drop ? I guess it just happens when the cpu is really really idle

because it takes more time to change c-states.

 

Jonathan

I was talking about the average power consumption, in milliwatts, of the processor when in the corresponding C State, as in 1000mW for C2 and 500mW for C3. Now back to the correlation between the two, because what does it take to lower the power usage of the CPU? Right, a reduced voltage and thus enter CPU-i

[yeehaa]

Some did report issues, but it should work. I recompiled it recently with the SDK of final Snow Leopard.

OK..am dumb! i was still checking your "experimental" webpage and the "release info" from the forum. found the new kext. will try it out now. thanks!

 

Gotcha. There is a post in this thread that details how to do that with the Voodoo Kernel and using the kprintf=1 kernel flag. This will print out the locations it is looking for each of the IST and CST tables. You can then substitute these values in the SSDT definition in your DSDT instead of the in-built ones.

my cstate address locations are alright. i was hoping to supply the dumped data directly instead of the OS looking for it during boot time. I dumped those address locations mentioned in my ssdt table once again just to be sure!

 

I got the voodoobattery now. thanks again.

 

 

I had a quick look at your files and looking at it; you have C-State support built in. The first question is: Did you enable it in the BIOS? I ask this because the latencies in the FACP are not good (see post #46) i.e. these values are in fact preventing it from entering C2/3. You might want to do another ACPIdump but this time with the BIOS settings enabled for it.

 

Also, you should be able to boot without CST related errors. And this without any CST related modification in your DSDT. And when this is not the case, then we simply have to figure out how to make it work.

 

P-State related modifications like frequencies and what not can be done by only adding a _PSS object to the first Processor declaration. The rest of the files will use it, and when not, then they are not loading. Which would be another problem to solve, but one that can be solved already.

 

p.s. You couldn't find NPSS simply because it does not exist. In fact your _PSS object represents the actually NPSS

 

i do not have an option for that in my bios. i have an hp notebook and the bios is very limited. the latency values are what got me worried and that's why i decided to try this dsdt method. any idea as to how to change that? if that is possible?

now after i added the cst method and pss tables into my dsdt i do not have that cst errors anymore.

 

the pstates are working fine and now i added two more (total 5 now) and they are also showing up in my ioreg. (another question: the pstate and cst related info are showing up only in the CPU0 branch and not in the CPU1. any idea why? is this normal? screenshot attached. the shot is after i added all my ssdt tables and using dropssdt option) i booted into 32 bit mode and checked using CPU-i. both cores are switching states fine.

 

NPSS was missing and i used PSS just to be on the safe side. never knew that NPSS was non-existant. thanks for the info.

[Brett Whinnen]

i do not have an option for that in my bios. i have an hp notebook and the bios is very limited. the latency values are what got me worried and that's why i decided to try this dsdt method. any idea as to how to change that? if that is possible?

now after i added the cst method and pss tables into my dsdt i do not have that cst errors anymore.

 

the pstates are working fine and now i added two more (total 5 now) and they are also showing up in my ioreg. (another question: the pstate and cst related info are showing up only in the CPU0 branch and not in the CPU1. any idea why? is this normal? screenshot attached. the shot is after i added all my ssdt tables and using dropssdt option) i booted into 32 bit mode and checked using CPU-i. both cores are switching states fine.

 

NPSS was missing and i used PSS just to be on the safe side. never knew that NPSS was non-existant. thanks for the info.

 

Got a current copy of your DSDT.dsl you'd be willing to share (and the older one?).

 

Thanks!

 

I still get CST related errors and no CSTInfo under SMC_Platform... I am thinking I'm very close but missing something rather major...

[keeza]

Quick question,

 

I've used Everest to dump my SSDT tables and DSDT table.

 

How do you view the bin files Everest creates? I cant open these files!

 

Care to help anyone?