Jump to content

DSDT - Vanilla Speedstep - Generic Scope (_PR)

FKA

By FKA,
in Power Management

 Share
1,949 posts in this topic

Recommended Posts

blackosx
blackosx
Posted
Posted
Thanks for your answer FormerlyKnownAs.

I have attached my dsdt. I receive this error:

 

dsdt.dsl  5746:		 Processor (CPU0, 0x00, 0x00000410, 0x06) {}
Error	4056 -					   ^ Name already exists in scope (CPU0)

ASL Input:  dsdt.dsl - 5931 lines, 194179 bytes, 2483 keywords
Compilation complete. 1 Errors, 1 Warnings, 0 Remarks, 60 Optimizations

As the error says, it already exists.

Search your DSDT.for 'Scope (_PR)' and you'll see you have it in twice. My guess would be to replace your Scope (_PR) section at the top with the complete /* CST Tables */ section down at the bottom.

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted

zoliky:

Be carefull to "take" PState values from others !

What never showed in all Pstates listed here is the FSB (in MHZ) which is used.

The MHZ Values + mWatts values shown in the PSS lines are cosmetic/information and make no difference to the stepping.

multi + VID is the main thing in each pss entry , that 0x0820 for example. 8 * FSB, 20hex VID. The second 0x0820 in the PSS is the same value and its used as an validate check. Some use here nothing, or 01, 02,....but thats at least not ACPI standard !

So YOU must safe that X* FSB is not OC eXtreme !

That isnt a problem with standard = unchanged FSB.

But if you, like me =266 MHz FSB > 333 MHz FSB use the FSB for OC

you must be very carefull and set correct multipliers (06zz, 07zz,...) in the PSS!

Link to comment
Share on other sites
leslieking
leslieking
Posted
Posted

Thank you guys!

I have an Intel Q6600 2.4GHz, no OC!

These are my BIOS settings: picture1 | picture2

 

I don't know much about p_states and c_states. I have the following p_states using voodoo_power: P_states

This is my DSDT: http://dl.dropbox.com/u/1924024/dsdt.dsl

 

I have enabled DropSSDT in com.apple.Boot.plist and I think, speedstep works for me because I get the same p_states in CPU-i like voodoopower. Anyway I don't have the courage to use the dsdt. I'm not exactly sure if everthing is OK.

 

Someone check my DSDT file? Please.. Thanks!

Link to comment
Share on other sites
BatcOuntrY
BatcOuntrY
Posted
Posted
Thanks for the tip. I guess this applies to AD2000B.kext as well? Since it's sort of kind of the same thing. I'll have a look later.

 

d'animal, if you try this, please let me know (I can't right now from where I am).

 

Sound stops working if I delete that key from the AD2000B plist. For the record here is what I did.

 

<dict>

<key>BuiltInHDA</key> //sudo vi info.plist and dd this line. left everything else the same.

<dict>

<key>CFBundleIdentifier</key>

Link to comment
Share on other sites
Master Chief
Master Chief
Posted
Posted
Yours dosen't work:

 

Did you fixed the source?

Interesting. We've seen 1810 downloads so far, from my weblog, and not a single report about iasl not working, instead of this 310 thank you notes. I also checked the download and I can compile and decompile with it. I'm confused.

 

And another 29 from here, after the update, and not a single complaint. People appear to have no issues with it, or are stupidly quiet.

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
Are you sure that the 6x @1.068v isn't C1?
The 6x@1.068 (really 1.000 if you do the voltage math for 45nm) corresponds to the 6x vid in my _PSS (as found in the dynamic SSDT table). So that'd make the voltage correspond to a regular C0 performance state, no?

 

 

If I had built my PSS by hand using the info from voodomonitor's p_states tab then I'd have wound up with a significantly higher value at 6X than is actually correct for my CPU. I don't think anyone should trust what it reports for the 6X vid regardless of CPU model. It uses the same buggy vidstep equation as voodoopower and voodoopstate without my fix. That equation can lead to cumulative roundoff errors that cause it to overestimate the vids. I recommend that folks double check their results with my fixed voodoopstate.

Link to comment
Share on other sites
ƃuıʞ ǝɥʇ
ƃuıʞ ǝɥʇ
Posted
Posted
Interesting. We've seen 1810 downloads so far, from my weblog, and not a single report about iasl not working, instead of this 310 thank you notes. I also checked the download and I can compile and decompile with it. I'm confused.

 

And another 29 from here, after the update, and not a single complaint. People appear to have no issues with it, or are stupidly quiet.

 

No idea, just dosen't work here...

BTW I tested on Leopard...mitch_de version works...

 

P.S. Where is that weblog?

Link to comment
Share on other sites
FKA
FKA
Posted
  • Author
Posted
That equation can lead to cumulative roundoff errors that cause it to overestimate the vids. I recommend that folks double check their results with my fixed voodoopstate.

 

Or calculate them the old fashioned way :D

 

The 6x@1.068 (really 1.000 if you do the voltage math for 45nm) corresponds to the 6x vid in my _PSS (as found in the dynamic SSDT table). So that'd make the voltage correspond to a regular C0 performance state, no?

 

indeed - sorry for being slow on the uptake here ^_^

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
Or calculate them the old fashioned way :hysterical:
Yes. I'm not really trying to plug anything. But with all the other monitoring programs reporting the wrong info when using appleintelcpupowermanagement (cpu-x, cpu-i, pstatechanger without my change, voodoopower) I think it needs to be stressed that the info is typically wrong. Yet post #1 advocates cpu-i and voodoopower to get vid information.
Link to comment
Share on other sites
FKA
FKA
Posted
  • Author
Posted
Yes. I'm not really trying to plug anything. But with all the monitoring programs reporting the wrong info when using appleintelcpupowermanagement (cpu-x, cpu-i, pstatechanger without my change, voodoopower) I think it needs to be stressed that the info is typically wrong. Yet post #1 advocates cpu-i and voodoopower to get vid information.

 

I didn't think you where and you're quite right bcc9.

 

And I will indeed change post#1 - in fact the entire post needs an overhaul, just haven't had the time. :hysterical:

 

EDit** post one actually reads -

"I was very lucky as there is already p-state example for my CPU on the net but this is also a very good guide to calculate FiD and Vid values for _PSS tables. Can be found here ."

 

Addmittedly "UCpu = 800 mV + vid*12.5 mV" 'isn't very acurate either

 

Have Intel since published this information?

Also open to suggestions for what this should read ? - would also be good to cover all CPU bases!

 

D

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
EDit** post one actually reads -

"I was very lucky as there is already p-state example for my CPU on the net but this is also a very good guide to calculate FiD and Vid values for _PSS tables. Can be found here ."

So that's the intended method. Fair enough. I was just noticing lots of references in this thread to the other tools and the "Find Fid and Vid using VoodooPower", and "CPU-i - application, very good!" references in post #1.
Have Intel since published this information?

I haven't found any such info. Lack of documentation is definitely a problem - hard to fact check everything. The new voltage frequency equation for 45nm matches what I get from rmclock, and matches the published voltage ranges in the datasheet for my processor. The old equation doesn't match up.

The roundoff error with vids is verifiable by code inspection and also by noticing that the vid for Vmin doesn't match what the processor reports for Vmin. c2ctl gets this right.

Link to comment
Share on other sites
FKA
FKA
Posted
  • Author
Posted
I haven't found any such info. Lack of documentation is definitely a problem - hard to fact check everything. The new voltage frequency equation for 45nm matches what I get from rmclock, and matches the published voltage ranges in the datasheet for my processor. The old equation doesn't match up.

The roundoff error with vids is verifiable by code inspection and also by noticing that the vid for Vmin doesn't match what the processor reports for Vmin. c2ctl gets this right.

 

Fair play - As most people seem to be plumbing to take fid/ vid values from voodoopstate rather than calculating I'll reference to your fixed voodoopstate -

 

I should have a quite day at work tomorrow, I'll sort it then.

 

If you're reading currently - here is bcc9's fixed voodoopstate for 10.5 and 10.6:-

voodoopstate.v4.zip

 

D

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted

Thanks. Do i need an newer PstateCahnger also ?

I ask because zero mVolts shown, even all VIDs (to compute mV) are listed .All other is great working :(

HINT: I set .kext by .plist to useACPI, which my OC_by_FSB cpu needs , voodooPstate is based on voodoopower and would take(reads cpu type) wrong 10* multi on my system=KP, even there is no 10* in dsdt PSS(=ACPI). I OC by FSB 266>333MHz on C2D 2.66 cpu. 10*333 would give to high OC, so PState 0 is 9*333=3000MHz (also BIOS multi is set dwon to 9*) , not 10*=3333MHz in my case.

So if you get KPs and have working Pstates try to set useACPI in all voodoopower based .kext. useACPI reads your Pstates (dsdt) and not use cpu type standard Pstates. That non ACPI voodooway often KPs on FSB OC systems!

Bild_438.jpg

Bild_439.jpg

Bild_437.jpg

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted

I have now used PStateChanger with VoodooPstate(bcc9's v4) to recalculate my values for P-states.

They did read

Package (0x06) { 2660, 0, 10, 10, 0x0A1D, 0 },
Package (0x06) { 2394, 0, 10, 10, 0x091C, 1 },
Package (0x06) { 2128, 0, 10, 10, 0x081C, 2 },
Package (0x06) { 1862, 0, 10, 10, 0x071B, 3 },
Package (0x06) { 1596, 0, 10, 10, 0x061B, 4 }

and now read

Package (0x06) { 2670, 0, 10, 10, 0x0A1D, 0 },
Package (0x06) { 2403, 0, 10, 10, 0x091D, 1 },
Package (0x06) { 2136, 0, 10, 10, 0x081C, 2 },
Package (0x06) { 1869, 0, 10, 10, 0x071B, 3 },
Package (0x06) { 1602, 0, 10, 10, 0x061A, 4 }

So a slight change which must be down to the rounding. So Thanks bcc9 for pointing this out. :D

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted

Do yout get the mVolts shown ? (In PstateChanger) (look my screenshoots - no mVolts, but VIDs ?! )

If you perhaps i have an older version, can you share yours ?

Someone else where PstateChanger + the kext V4 cant show mVolts but all others?

Link to comment
Share on other sites
blackosx
blackosx
Posted
Posted
Do yout get the mVolts shown ? (In PstateChanger) (look my screenshoots - no mVolts, but VIDs ?! )

If you perhaps i have an older version, can you share yours ?

Someone else where PstateChanger + the kext V4 cant show mVolts but all others?

Hi mitch

 

I am using PstateChanger v1.0.3 (1) + the kext V4 posted by FormerlyKnownAs a couple of posts ago.

It shows mVolts on mine. Here's a grab.

post-331032-1258355867_thumb.png

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted
Do yout get the mVolts shown ? (In PstateChanger) (look my screenshoots - no mVolts, but VIDs ?! )

If you perhaps i have an older version, can you share yours ?

Someone else where PstateChanger + the kext V4 cant show mVolts but all others?

I'm assuming you have your 0 volt problem with hnak's versions as well, or is it something I broke? I'm not seeing that problem, and my PMs indicate that it's working OK for others. That v4 version is the latest&greatest if you want to play with my changes. The 0 volt issue should be easy to debug from the source, please do :D
Link to comment
Share on other sites
leslieking
leslieking
Posted
Posted

I removed SleepEnabler.kext and NullCPUPowerManagement.kext. Sleep works :D

These are my P-states (obtained using Voodoomonitor + Voodoopstate-v4): http://dl.dropbox.com/u/1924024/speedstep.png

My CPU is Intel Q6600 2.4Ghz, No overclock!

 

I have the DSDT code from @FormerlyKnownAs:

 

Scope (_PR.CPU0)
   {
       Method (_PSS, 0, NotSerialized)
       {
           Return (Package (0x03)
           {
               Package (0x06)
               {
                   Zero, 
                   Zero, 
                   10, 
                   10, 
                   0x0928, 
                   Zero
               }, 

               Package (0x06)
               {
                   Zero, 
                   0, 
                   10,
                   10, 
                   0x0827, 
                   One
               }, 

               Package (0x06)
               {
                   Zero, 
                   Zero, 
                   10, 
                   10, 
                   0x0727, 
                   0x02
               }
})
}

           Method (_PSD, 0, NotSerialized)
           {
               Return (Package (0x05)
               {
                   0x05,
                   0x00,
                   0x00,
                   0xFC,
                   0x04
               })
           }

       Method (_CST, 0, NotSerialized)
       {
		Return (Package (0x02)
		{
			One, 
			Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x1, 0x2, 0x0, 0x1,)},0x01,0x9D,0x3E8}
		})
       }
   }

   Scope (_PR.CPU1)
   {
       Method (_PSS, 0, NotSerialized)
       {
               Return (^^CPU0._CST ())
       }

       Method (_PSD, 0, NotSerialized)
       {
               Return (^^CPU0._CST ())
       }

       Method (_CST, 0, NotSerialized)
       {
           Return (Package (0x04)
           {
               0x03, 
               Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x01, 0x02, 0x000, ,)},0x01,0x00,0x3E8}, 
               Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x414, ,)},0x02,0x01,0x1F4}, 
               Package (0x04) {ResourceTemplate () {Register (FFixedHW, 0x08, 0x00, 0x415, ,)},0x03,0x55,0x0FA} 
           })
       }
   }

   Scope (_PR.CPU2)
   {
       Method (_PSS, 0, NotSerialized)
       {
               Return (^^CPU0._CST ())
       }

       Method (_PSD, 0, NotSerialized)
       {
               Return (^^CPU0._CST ())
       }

       Method (_CST, 0, NotSerialized)
       {
               Return (^^CPU1._CST ())
       }
   }
   Scope (_PR.CPU3)
   {
       Method (_PSS, 0, NotSerialized)
       {
               Return (^^CPU0._CST ())
       }

       Method (_PSD, 0, NotSerialized)
       {
               Return (^^CPU0._CST ())
       }

       Method (_CST, 0, NotSerialized)
       {
               Return (^^CPU1._CST ())
       }
   }

 

I hope everything is OK and my CPU doesn't burn up ;)

The multiplier column in CPU-i changes every time (x6, x7, x8 and x9). When I open an application (or CPU is used) the multiplier is x9. The CPU doesn't stay much at x7 and x8. Is this normal? Thanks!

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...