Jump to content

64bit p-state

hnak

By hnak,
in Intel SpeedStep

 Share
131 posts in this topic

Recommended Posts

mitch_de
mitch_de
Posted
Posted
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.

Link to comment
Share on other sites
oldnapalm
oldnapalm
Posted
Posted

Guys, please take a look at Superhai's forum

http://superhai.com/forum/viewtopic.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.

Link to comment
Share on other sites
oldnapalm
oldnapalm
Posted
Posted

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/forum/viewtopic.php?f=41&t=229

Link to comment
Share on other sites
bcc9
bcc9
Posted
Posted

I started out by contributing fixes to superhai directly. For example, see here:

 

http://code.google.com/p/voodoo-power/issues/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.

Link to comment
Share on other sites
marionez
marionez
Posted
Posted

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.

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted

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")

// Just for reference
static int[b] find_acpi_pss_table[/b](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("[b]_PSS[/b]", &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();
	[b][color="#FF0000"]PState[k].voltage = 0; // Not yet figured out[/color][/b]
	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.

VoodooPState_Intel_mVoltswithACPI.kext.zip

Bild_502.jpg

VoodooPState_103_ACPImVolts_Intel.zip

Link to comment
Share on other sites
mitch_de
mitch_de
Posted
Posted

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.

Link to comment
Share on other sites
  • 1 month later...
hnak
hnak
Posted
  • Author
Posted
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 ?

Link to comment
Share on other sites
  • 1 month later...
hotcorez
hotcorez
Posted
Posted

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

Link to comment
Share on other sites
  • 4 weeks later...
ctheanh
ctheanh
Posted
Posted

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)

Link to comment
Share on other sites
  • 3 months later...
MacKonsti
MacKonsti
Posted
Posted

Guys, I know this is probably an abandoned thread, I was looking for a newer version of VoodooMonitor because on my new mobo using Gigabyte P55M-UD4 and Core i7-860, the VoodooMonitor.kext causes constant kernel panics whether on 32-bit or 64-bit loader/bootmode. I cannot use it at all and I really liked the tool on my previous Core2Quad mobo! Does anyone have a recommendation/advice or even suggest a replacement tool, if this is "dead"? Superhai's forum is well-shut-down... Thanks in advance.

Link to comment
Share on other sites
Jadas
Jadas
Posted
Posted
Guys, I know this is probably an abandoned thread, I was looking for a newer version of VoodooMonitor because on my new mobo using Gigabyte P55M-UD4 and Core i7-860, the VoodooMonitor.kext causes constant kernel panics whether on 32-bit or 64-bit loader/bootmode. I cannot use it at all and I really liked the tool on my previous Core2Quad mobo! Does anyone have a recommendation/advice or even suggest a replacement tool, if this is "dead"? Superhai's forum is well-shut-down... Thanks in advance.

 

I think there is a program called cpu-i. Check applelife.ru .

Link to comment
Share on other sites
hnak
hnak
Posted
  • Author
Posted
Could someone explain what is each threshold value in Pref tab in PStateChanger ?

 

Thanks in advance,

Jadas.

If total CPU usage:

> threshold max -> switch to highest p-state (usually 0)

> threshold up -> switch to upper p-state

< threshold down -> switch to lower p-state

< threshold min -> switch to the lowest p-state.

Link to comment
Share on other sites
  • 11 months later...
indiandragon
indiandragon
Posted
Posted
T7250 2Ghz with 7 (0-7) Pstates: 2000-1800-1600-1400-1200-1000-800-600. I disabled the EFI FSB in Info.plist, if its enabled, it gets wrong FSB - 183Mhz.

 

*With Coolbook it works fine with 600Mhz, the throttling level is set to very high.

 

 

With these settings it feels smooth.

 

scheduledTimerWithTimeInterval:0.2

 

 

		if(load > 0.95){	// up to highest
		 newState = 0;
	 } else if(load > 0.1){
		 if(newState > 0)
			 newState -= 1;
	 } else if(load < 0.1){
		 newState += 1;
	 } else if(load < 0.1){	// down to lowest
		 newState = _pstateCount-1;
	 }

 

So the App has to run to get these changed Settings?

 

Hi Riws,

 

Iam having the same Processor as you, T7250. My pstates are varying between 540MHz to 1881MHz in Voodoopower mini. If I use DSDT solution I get PStates between 720MHz and 1881MHz only. Can you share more info on your Pstates and your kexts ?

 

P.S - Iam running OSX Lion (64).

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