64bit p-state

[Smith@@™]

I have try the voodooPstate v2 and it works, but with this version i have lost one pstate; with the "original" version, i have 4 pstate and all 4 pstate work well, looking cpu-x and voodoomonitor, but with v2 i have lost the 3° pstate, the lower, that with multiplier lower (in this case that with multiplier 6), now it is normal or I must come back to voodoopstate unmodded, "original" ? (Original pstate with unmodded version are with multiplier 7.5, 7, 6.5 and 6)

 

Thank you for answer and sorry for my english

 

Ciao

[bcc9]

I have try the voodooPstate v2 and it works, but with this version i have lost one pstate; with the "original" version, i have 4 pstate and all 4 pstate work well, looking cpu-x and voodoomonitor, but with v2 i have lost the 3� pstate, the lower, that with multiplier lower (in this case that with multiplier 6), now it is normal or I must come back to voodoopstate unmodded, "original" ? (Original pstate with unmodded version are with multiplier 7.5, 7, 6.5 and 6)

Ah, I wasn't careful enough with non-integer multipliers. I've made a new version that should handle that (though I cannot test it with my osx laptop). Will also update the diffs in my prior post in a sec...

[hnak]

I built with hnak's default settings, which means it's a 10.6 only bundle. 10.5.x kexts would have to be built separately.

VoodooPState_leo.xcodeproj.zip

Here is the xcode project file to build 10.5 kext.

[bcc9]

VoodooPState_leo.xcodeproj.zip

Here is the xcode project file to build 10.5 kext.

Great. So what do you think, an info.plist entry such as "UseLFM" that can be set to false for systems that lock up on LFM p-states? I can add parsing for that.

[Onixs]

bcc9

 

 

With your build, will it work even without using the monitoring app ?

[Smith@@™]

Ah, I wasn't careful enough with non-integer multipliers. I've made a new version that should handle that (though I cannot test it with my osx laptop). Will also update the diffs in my prior post in a sec...

 

ok, i'll wait a good new, thanks

 

Ciao

[bcc9]

With your build, will it work even without using the monitoring app ?

You can still use the kext with or without the app just as before.

 

ok, i'll wait a good new, thanks

I update my link & the diffs hours ago, (before the above reply), as promised.

[mitch_de]

bcc9:

Can you please make an new thread with that new vodoopowerV2,V3m... way ?

Would be much easier to handle + post changes. Also we users can see clear if new version is out and whats changed.

I cant find the orig. Thread postings - must be in between lots posts over x sites.

I looked in that voodoopowerstate.V3 , in info.plist there are bundle numers 8.0.0 , so will run in Leo also ?

(SL have mostly 10.0.0 as bundles)

Much thanks for your work, i am not complaining, its an idea for even faster+better users downloads + user q+a for your new versions!

 

VoodooPState_leo.xcodeproj.zip

Here is the xcode project file to build 10.5 kext.

 

Great - but something is missed. No sources , opening that .xproj file gives missing .. error?!

Would be nice to have an new upload with .xproj and all needed Leo source.

Thanks

[hnak]

Would be nice to have an new upload with .xproj and all needed Leo source.

Thanks

You can use exactly the same source files. It might require minor modifications to compile.

I do not have 10.5 source files separately. Let me know if you have problems in building kext.

[bcc9]

Can you please make an new thread with that new vodoopowerV2,V3m... way ?

Well I already have a separate thread for my laptop where those are posted.

Ideally these changes would just be folded into the main version in short order, so another thread would be overkill I think. But it's up to hnak as this is his thread. If we could just decide on a UI knob for turning off LFM modes, and or make it the default then this is done.

I don't really want to maintain a fork; I do already have a complete solution for my laptop.

Would be much easier to handle + post changes. Also we users can see clear if new version is out and whats changed.

I cant find the orig. Thread postings - must be in between lots posts over x sites.

Look, it's real simple. My posts above in this very thread are updated to my latest version and I posted when I changed things. The changes are rather simple as well, and twofold - 1) a variable to disable LFM p-state modes, 2) New math to compute the voltage differences between the p-states while avoiding roundoff errors (that otherwise lead to higher voltages). There are no other sites to worry about.

I looked in that voodoopowerstate.V3 , in info.plist there are bundle numers 8.0.0 , so will run in Leo also ?

(SL have mostly 10.0.0 as bundles)

As I mentioned, I just used the default xcode project, which just compiles 10.6 kexts. Time for you to upgrade? Ideally, if ongoing support of 10.5 is a goal, the 1 .xcodeproj file would have 2 release targets, one for 10.5.x and one for the current release.

[Smith@@™]

Hi bcc9, i have try your modded voodoopstate v3, and it works, but I yet have lost the pstate value lower, exactly like with the voodoopstate v2.. I guess in a fix in future, thanks a lot again

 

Have a nice day

 

Ciao

[bcc9]

Hi bcc9, i have try your modded voodoopstate v3, and it works, but I yet have lost the pstate value lower, exactly like with the voodoopstate v2.. I guess in a fix in future, thanks a lot again

Are you sure you're not just losing pstates < 6X? That would be expected since I'm disabling any super-LFM pstates.

 

I've double checked my work by running it on a gigabyte p35 motherboard, and the results are significant and it's working just fine:

Before (with hnak's 1.0.3 version):

After (with my v3 version):

[Smith@@™]

But the v3 working well, really, it's fantastic, the voltage is lower; only "problem" is that with original 1.0.3 version i haved 4 pstate, and with your modded version i have only 3 pstate, simply, but your version working fantastic anyway... The lost pstate is the lower, that with frequency lower, but it isn't a 'big' problem

 

Sorry for my english, Ciao

[mitch_de]

You can use exactly the same source files. It might require minor modifications to compile.

I do not have 10.5 source files separately. Let me know if you have problems in building kext.

 

I dont have the problem using xcode if i had that already diffed v3 source !

bcc9: Is ist too much wanted to add your ready to complie sourcecode V3 (already diffed) with the project file in one .zip?!

 

Thanks

[bcc9]

I dont have the problem using xcode if i had that already diffed v3 source !

bcc9: Is ist too much wanted to add your ready to complie sourcecode V3 (already diffed) with the project file in one .zip?!

Oy... If you can compile source you should also know how to use patch and you would not be asking. But I take it all you really wanted was an old 10.5.x build.

 

Anyways, here's a new version, v4.

• I've added a UseLFM variable to info.plist as I suggested.
  
• I updated the xcode project so that there is a second release target, rel.10.5, for building legacy kexts.
  
• I once again think I fixed the way UseLFM works with for non-integer frequency multipliers. I got it wrong last time. Normally I don't screw up like this but in my defence I have no such hardware to test against.
  

Source & 10.5&10.6 binaries included.

voodoopstate.src.v4.zip

voodoopstate.v4.zip

[mitch_de]

Great - thanks !

I didnt complained but was a bit ?? why not post both things (source V3 + Xcode proj) together.

I think some other users will be happy with your kind "posting both ilinks n one"

lets xcoding - i´ll be back

[bcc9]

Great - thanks !

I didnt complained but was a bit ?? why not post both things (source V3 + Xcode proj) together.

I didn't want to start a fork or maintain one, I wanted opinions on the fix and possible UI knob to control LFM mode before going any further. I also didn't want to deal with 10.5.x any more or test it anymore. Oh well on all counts I guess Not to mention that the diffs are a lot more concise than just dumping some edited source on developers.

[mitch_de]

I didn't want to start a fork or maintain one, I wanted opinions on the fix and possible UI knob to control LFM mode before going any further. I also didn't want to deal with 10.5.x any more or test it anymore. Oh well on all counts I guess Not to mention that the diffs are a lot more concise then just dumping some edited source on developers.

 

Perhaps some users didnt need LFM Mode if using USEACPI flag (in .plist).

I get all Pstates which are injected by dsdt for my C2D CPU which have also that 0.5 steps !

Or does LFM means not that 0.5 steps in Pstates ?

 

I now a bit confused about that Timing keys in PstateChanger and .plist of the .kext.

GOAL:

- less cpu usage / less cpu ticks for showing that changes = PstateChanger Timer 1000mS , once / sec showning changes is enough for me

- computing & switching up/down should be independed and made by the .kext itself.

In the .kext there is an key timerinterval (,plist) which i thinked made that up/downs independed with its own timer.

I use there 300 mS( 3 times check& up/down)

 

My looking on both gave not the results i thinked & wanted.

1. If i close PstateChanger stepping stops and stay at last P-State , cant the .kext run independed (configure&fire&forget)like voodoominipower ?! -

2. I could life with 1., but and more bad:

If i set the Timer (screenshoot) of Pstatechanger to 1000mS (show changes once / sec) i feal that

also the stepping itself, which is configured in the .plist of the .kext (i use 300mS there) runs much slower. Not only the showing part.

So can it be that even i set timer in .kext to 300/200/100mS the Timer in the PState Changer "overwrite" that with for example 1000mS.

Means not only showing is once / second , which OK & wanted, also stepping is only once/second(=wrong) ?, which is unwanted (wanted that 100-300mS in .kext)

 

Thanks for helping to understand. Hope i am wrong with my fear of PstateChanger

 

Conclusion:

If its needed to run always PstateChanger to step up/down - not a real problem if someone

could add an second Timer to PstateChager:

RefreshTimer (new) : how often the PstateChager TAB items get refreshed/shown , can be much less often than

SteppingTimer (was interval) : how often Pstatechager does compute cpu load & does step up/down calls to the .kext

 

Screenshoots:

Perfect using Pstates 6.0 ...9.0, even with 0.5 steps, UseACPI Yes = GREAT + Thanks!

?? PStateChanger Timer 1000mS slows also stepping and not only slows showing chages ?! - HELP

[bcc9]

You lost me, none of your comments or testing seem to be about anything I've done. And also, UseACPI and UseLFM are different and don't accomplish the same thing.

[mitch_de]

You lost me, none of your comments or testing seem to be about anything I've done. And also, UseACPI and UseLFM are different and don't accomplish the same thing.

Sure, my last posting wasnt focused to your code, its more an HELP call for the main App, PstateChanger to the original developer of that great PStateChanger

By the way, perhaps you understand that timer setting (.plist of .kext) . What excat does this timer and is it independend to PStateChanger Timer(interval in Pref TAB)?

Thanks

 

EDIT:

I did some looking for my fear "slow refresh interval" made also slow stepping ;(

Running CPU-X beside PStatechanger shows:

CPU-X itself gets updated CPU MhZ twice / second i think - and that independed from PstateChanger.

If i set the PREF-Tab interval = 2000 (mS, slowest refresh) the stepping up/downis too less often, (shown in CPU_X) (BAD!)

If i set the interval = 400 (mS, fastest refresh) the stepping up/down is often=normal, (shown in CPU-X )

Both tests running beside an App that produces cpu loads from, 20-50%.

 

BAD: If setting to interval=400, stepping works as it should, but the PstateChanger uses much (too much!!) cpu load itself.

Even if hide the app (only in Dock) cpu load is not as low as it should.

 

The cpu load(usage) with interval=2000 is perfect low , but the bad sideeffect of much to less often stepping.

 

So main question :

Why is there an Timer key in the .kext, when PStateChange has its own timer setting and using that also for how often stepping, and not only for how often refreshing shown changes.

[Smith@@™]

I have the pstate lower again, thank you bbc9. But I have 2 question:

1) Which the optimal value for interval cpu load? The default is set to 400;

2) Confuse idea: if I don't use the app, PSTATE CHANGER, in the dock, or well if I don't use the app never, what happen? Have I will problems in the future; that I would say is: the up and down of pstates works will the same?

 

Thank you and sorry for my english..

 

Ciao

[bcc9]

I notice that hnak, and now I, have been asked over&over why the pstatechanger application has to run in order for cpu stepping to actually take place. He's answered repeatedly that it's because architecturally the policy has been taken out of the kext that makes the p-state changes.

 

I agree that architecturally the policy should be separate from the component that makes the p-state changes. The ACPI spec dictates as much I think. But in other OSes, the policy is still implemented as a core component of the OS, such as in a daemon. Then there are separate applications for the user to configure preferences for the policy and control the policy. The policy governor is always running, regardless of whether or not the user is running an application to configure its preferences.

 

I still don't even get why we can't get AppleIntelCPUPowerManagement* to do all the work. (And hardcoding p-states into the dsdt doesn't count as a solution in my opinion as the solution is then limited to a particular machine).

[mitch_de]

Sure.

But its simple : The PstateChanger App does use much to high cpu ticks (cpu usage) to do its work.

Again: PstateChanger should refersh the window / results TABs much less + independed from do the stepping so save cpu load/ticks.

So an second timer is needed in PstateChanger: One timer (configurable) for how often to step / An other timer (configurable) for how often to refresh the values shown.

For me its useless in that stage, i will use voodoominipower which has an much less cpu footprint doing same job (in Leo).

Also AppleIntelCPUPowermanagement , which can be used with SL (voodoominipower not) will have an much less cpu footprint.

[bcc9]

Also AppleIntelCPUPowermanagement , which can be used with SL (voodoominipower not) will have an much less cpu footprint.

If you know of a way to get AppleIntelCPUPowerManagement to do the speedstep state changes and policy without requiring voodoo kexts I'd love to hear about it.

As far as I've seen, voodoopstate is the only utility shipping that can change a hackintosh's cpu stepping under 64 bit snow leopard.

 

Hardcoding one's CPU voltages into dsdt is a non-starter.

[bcc9]

But its simple : The PstateChanger App does use much to high cpu ticks (cpu usage) to do its work.

Hmm, yes it looks like it. But it would be irrelevant if the policy governor was a daemon as you wouldn't need to run the gui application unless you wanted to actually watch the processor states. Which is the model I was advocating.