Jump to content

64bit p-state


  • Please log in to reply
128 replies to this topic

#101
Onixs

Onixs

    Since 2007

  • Members
  • PipPipPipPipPipPipPip
  • 734 posts
  • Gender:Male
Where is the best place to put this kext. /Extra or /S/L/E ?

#102
marionez

marionez

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 425 posts
10.6.2 is speedstepping itself here (intel e8400) with asus p5q.
Removed /extra/Nullcpupowermanagement.kext

With no voodoopstate on 64bit:

Attached Files



#103
mitch_de

mitch_de

    InsanelyMacaholic

  • Local Moderators
  • 2,880 posts
  • Gender:Male
  • Location:Stuttgart / Germany

10.6.2 is speedstepping itself here (intel e8400) with asus p5q.
Removed /extra/Nullcpupowermanagement.kext
With no voodoopstate on 64bit:

Yep, OS X can do speedsteping without thrird party .kext, if AppleIntelCPU*.kext are loaded and working (Pstates in dsdt / in bios OK).
But AppleIntelCPU stepping may also depens of which model (iMac, MacPro) you use in smbios , because the AppeIntelCPU stepping also depends on what config in .plist of ACPI_SMC..plugin is used. That .plist changed in structure by 10.6.2.
Until know only some major/main things of that .plist entrys are well known. Most things not, like GPU throttling (also depends on that),
stepping itself (SP1...SP4). YOu cant adjust the thresould of stepping like with all other speedsteping tools.

#104
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,837 posts
  • Gender:Male
  • Location:Brazil
Guys, please take a look at Superhai's forum
http://superhai.com/....php?f=41&t=229

"This will be Snow Leopard only.

There is a lot of work to do yet, and little time and too few beta testers is not helping much. Due to how the snow kernel is changed, especially in 64 bit, there are a few challenges to overcome. I have a base which work, but alot of remaining stuff need to be written, and the kext will be very bound to the kernel.

I don't think I will keep it open source anymore. The reason is that, no one has collaborated. My reason for keeping this open source was that so people could help me and contribute with bugs. Almost no one has done it. Instead people make smaller or more major changes and post everything as their own, and they are not notifying me at all.

I want to find out if there is real interest for me developing this. On most systems you are able to use snow leopard built-in pm kexts to add speedstep, and it works as long as you have support in your bios, and if not it is easily added from editing the ACPI tables.

I will run this poll for a week, if there is little response, I would estimate less than a couple of hundred responses, it is time to put this offline."


Maybe we should contribute with VoodooPower instead of starting a new project. I'm not saying you should stop VoodooPState development, but at least try to contribute with the project it's based on.

#105
Smith@@™

Smith@@™

    InsanelyMac LOL

  • Retired
  • 2,928 posts
  • Gender:Male
  • Location:Somewhere over the rainbow...ITALIA!
  • Interests:Dark matter and dark energy. E basta. HD3000. E basta.

Maybe we should contribute with VoodooPower instead of starting a new project. I'm not saying you should stop VoodooPState development, but at least try to contribute with the project it's based on.


True

#106
marionez

marionez

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 425 posts

True

I absolutely agree.

#107
oldnapalm

oldnapalm

    InsanelyMac V.I.P.

  • Moderators
  • 6,837 posts
  • Gender:Male
  • Location:Brazil
Thanks guys.

Please read this, may interest you:

It was a change that Apple came into one of the early snow beta builds. The move to split it into an app is also not a good solution at all. Cocoa does not have a method that update the kext fast enough, currently also the method in VoodooPower is too slow. Cocoa is able to update at maximum per 500ms properly, this kext is when release version is out have an update refresh of 50ms (the debug version updates at every 5 s, so it won't kill the kernel.log due to all the logging). Latency of p-states are at 10-100 us, and Apples P-state manager is able to utilize that fully. What it means is that when you need i.e. P-state 0 the built-in OS stepper will be at P0 within 100us, this kext needs up to 50ms + p-state latency and the Cocoa app up to 500ms + p-state latency. Of course when browsing the web it has not a high impact, but you will notice that the higher the latency the more slower the startup is. Especially if it is as slow as 800MHz and is set to jump to maybe 2400MHz. Therefor in the next major milestone (1.3.x) I will integrate it so it attaches instead of AppleIntelCPUPowerManagement so it is able to use the OS functionality fully.


Let's support him, at least with some motivation. I've been testing the beta version of VoodooPower 1.3 and it's already working with basic SpeedStep (highest and lowest p-state).

http://superhai.com/....php?f=41&t=229

#108
bcc9

bcc9

    InsanelyMac Legend

  • Coders
  • 1,277 posts
  • Gender:Male
I started out by contributing fixes to superhai directly. For example, see here:

http://code.google.c...es/detail?id=18

The net result was that my fix was ignored and never integrated into voodoopower. Instead he re-orged his web site and took down references to the bug list, and is now claiming that "no one has collaborated". You can not even respond to him without registering on his private web site where all previously reported issues have been wiped... It would seem that my ideas are not valued at all by him, at least that's the impression those actions leave.

Meanwhile I really wanted a 64 bit solution. I waited months and nothing, except voodoopstate emerged as the only 64 bit solution that is still open source.

I had noticed that voodoopstate is largely using the same code as voodoopower (yet is missing the superhai copyright). Same with cpu-i. Didn't seem kosher to me, but I have no idea what sort of arrangement they made with superhai so I didn't make a big stink about it. Not my place to do so anyways. For all I know they got permission.

Still, I have been careful to point out that the code is the same across all these derivative versions. I've also been careful to provide source for my changes and not take credit for the work of others, instead I reference the prior work over&over.

By the time I made my vidstep bug fix the source for voodoopower was already down, the source to voodoomonitor is mia, and so the only remaining logical place to contribute it was here....

I would be much happier just having my changes integrated into superhai's code base. I still don't want to maintain some derivative version.

At this point I think I really just need a monitoring application as applieintelcpupowermanagement is doing the stepping for me. Yet none of the monitoring applications are displaying correct info. If voodoopower can be re-orged to separate the pieces - the cpu specific hardware register interactions, the OSPM governor, and the gui monitoring/cpu-x-like functionality (that doesn't require a voodoo governor), and pick up my openly posted fixes, that'd be great.

#109
marionez

marionez

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 425 posts
I think that on this forum and in general in osx project people are on his very own.
This site is full of noob guide with wrong tips, when you try to speak about this, they ignore you, they're on their own.
This is not useful for our growing.

For sure, Superhai is quite hard to work with, but *he* did the real power management for our x86. So we have to try to work together on the same target, join forces and reach the goal, speaking with Superhai.

#110
blackosx

blackosx

    InsanelyMacaholic

  • Coders
  • 3,083 posts
  • Gender:Male
  • Location:UK

Guys, please take a look at Superhai's forum
http://superhai.com/....php?f=41&t=229

I agree and I have also read what bcc9 posted. So maybe a fresh unified approach can be attained?
But I also don't want to discount this contribution by hnak, and I don't want to dis-respect his thread.

#111
mitch_de

mitch_de

    InsanelyMacaholic

  • Local Moderators
  • 2,880 posts
  • Gender:Male
  • Location:Stuttgart / Germany
I get allways ZERO mVolts shown even all others (VID!!!) are shown correct.

I got in deep of the sources: PstateChanger wasnt the prob - its VoodooPstate and usage of UseACPI=YES (means read the dsdt _PSS)
I need this, because if i let VoodooPstate guess the pstates and not usinf my _PSS (dsdt) i get KP because all Voodoo based steps
guess i have Pstates 6*...10*, which is wrong. i Ihave 6* ...9* , because OC by FSB. 10* 333 MHZ = KP, 9*333 MHZ = Ok.
Workaround would be to set PstateLimitHigh =1 (0 is default) - but better to fiy the source.


I found the source part which does the mVolts = 0 :) ;
It happens if you enabled useACPI (means read the dsdt _PSS, not using voodoo based Pstate "computing")
 find_acpi_pss_table(PStateClass* PState)
{
// Use ACPI to extract fid/vid
// borrowed from xnu-speedstep
/* Find CPUs in the IODeviceTree plane */
IORegistryEntry* ioreg = IORegistryEntry _linenums:0'>// Just for referencestatic int<strong class='bbc'> find_acpi_pss_table</strong>(PStateClass* PState){ // Use ACPI to extract fid/vid // borrowed from xnu-speedstep /* Find CPUs in the IODeviceTree plane */ IORegistryEntry* ioreg = IORegistryEntry::fromPath("/cpus", IORegistryEntry::getPlane("IODeviceTree")); if (ioreg == 0) { DebugLog("No CPU!"); return 0; } /* Get the first CPU - we assume all CPUs share the same P-State */ IOACPIPlatformDevice* cpu = (IOACPIPlatformDevice*) ioreg->getChildEntry(IORegistryEntry::getPlane("IODeviceTree")); if (cpu == 0) { DebugLog("CPU = 0!"); return 0; } /* Now try to find the performance state table */ OSObject* PSS; cpu->evaluateObject("<strong class='bbc'>_PSS</strong>", &PSS); if(PSS == 0) { InfoLog("No PState table in ACPI."); return 0; } OSArray* PSSArray = (OSArray*) PSS; UInt32 numps = PSSArray->getCount(); for(int k=0; k < numps; k++){ OSArray* onestate = ( OSArray* )(PSSArray->getObject(k)); PState[k].frequency = ((OSNumber*) onestate->getObject(0))->unsigned32BitValue(); <strong class='bbc'>PState[k].voltage = 0; // Not yet figured out</strong> PState[k].ctl = ((OSNumber*) onestate->getObject(4))->unsigned32BitValue(); } return numps;}


The easiest thing is to use the available VIDs , which can sure be read with ACPI (_PSS) and do the VID > mVolts here like without ACPI too.

How could i implement that there ?


EDIT: I did it !

Now works to show mVolt also with useACPI=Yes (reads _PSS from dsdt, not using "computed pstates").

I also removed AMD code out of that VoodooPstate - smaller size. Based on lastest 1.0.3.
settings in .plist unchanged (useACPI=NO, default)
I only can build Leo .kext. I added also the new src for them who wants build it for SL.

Attached Files



#112
mitch_de

mitch_de

    InsanelyMacaholic

  • Local Moderators
  • 2,880 posts
  • Gender:Male
  • Location:Stuttgart / Germany
VoodooPowerMini 10.6 is out ! supehai did it again ;)

I think i will switch .

#113
Smith@@™

Smith@@™

    InsanelyMac LOL

  • Retired
  • 2,928 posts
  • Gender:Male
  • Location:Somewhere over the rainbow...ITALIA!
  • Interests:Dark matter and dark energy. E basta. HD3000. E basta.

VoodooPowerMini 10.6 is out ! supehai did it again :)

I think i will switch .


mich, a question: which difference are there between voodoopowermini and voodoopower? Simply.

Thanks for answer ;)

Ciao

#114
mitch_de

mitch_de

    InsanelyMacaholic

  • Local Moderators
  • 2,880 posts
  • Gender:Male
  • Location:Stuttgart / Germany
BIG difference - smaller RAM usage, less cpu usage!
mini is reduced from AMD code and also some other optimisations for even more lesser cpu usage than normal superhai.
But even the normal superhai vodoopower has much less cpu usage, because not needed to run an extra COntrall Ap (no PstateChanger must run) beside the .kext.

#115
pinarek

pinarek

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 643 posts
  • Gender:Male
  • Location:Deutschland
Marionez, from what for a Tool ist the pictures here ?

http://www.insanelym...62943_thumb.jpg

Thank you for info

Pinarek

10.6.2 is speedstepping itself here (intel e8400) with asus p5q.
Removed /extra/Nullcpupowermanagement.kext

With no voodoopstate on 64bit:



#116
iHack13

iHack13

    InsanelyMac Protégé

  • Members
  • PipPip
  • 64 posts
I have a question to the topic starter.

why didnt you mention Superhai even once?

#117
westwaerts

westwaerts

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 879 posts
  • Gender:Male
@pinarek
an app called mark-i, its in russian language, monitors speedstep

#118
hnak

hnak

    InsanelyMac Sage

  • Members
  • PipPipPipPipPip
  • 303 posts
  • Gender:Male

I have a question to the topic starter.

why didnt you mention Superhai even once?

There is no reason. I thought almost everyone knows VoodooPower's author.
How do you want me to modify the text in my first post ?

#119
hotcorez

hotcorez

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 115 posts
Please. No need to speak to hnak like this. He is a decent guy and helps others. I know their is some bullying by so called tek lords but there must be a more polite way of asking hnak this question, maybe a pm?

No disrespect to superhai tho and I appreciate what ihack13 is saying, I just don't like to see negativity.

hnak helps to make superhai's work, work properly on AMD, and as far as i know, he is the only one doing this.

Please do not kill topics!

Cheers,

HC

#120
ctheanh

ctheanh

    InsanelyMac Protégé

  • Members
  • Pip
  • 8 posts
Help me,I tried with Acer Aspire 5520G (AMD TL 56) and get problem with USB Audio
WARNING: AppleUSBAudio has detected that clock_get_uptime () value changed radically from previous values ...
What can I do with this?It can work only with unstick Audio (when select pstate=0)





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy