Jump to content

VoodooPower 1.2.3


Superhai
 Share

VoodooPower User Survey  

736 members have voted

  1. 1. Which CPU do you use this on?

    • Intel Pentium M
      29
    • Intel Pentium 4/D
      40
    • Intel Core (2) Solo/Duo/Quad
      464
    • Intel Atom
      100
    • AMD K8
      31
    • AMD K10
      22
    • Intel I7 or newer
      19
    • AMD K11 or newer
      11
    • Other
      20
  2. 2. Does it work successfully?

    • Yes, no issues
      363
    • Yes, minor issues/annoyances
      237
    • No, Intel Pentium M/4/D
      20
    • No, Intel Core or newer
      58
    • No, AMD K8
      22
    • No, AMD K10 or newer
      15
    • No, other CPU
      21
  3. 3. How do you rate the usefullness of VoodooPower?

    • No use
      105
    • Poor
      32
    • Mediocre
      54
    • Useful
      193
    • Very useful
      273
    • My life depend on it
      79


351 posts in this topic

Recommended Posts

Once again, thanks Hnak this has been integrated into my new kernel (+sources).

Link to comment
Share on other sites

Thanks for testing.

Humm... it is different from my result with Athlon X2 4050e. I can see pstate changes at least.

Does pstate stay at 0 even with only finder ?

 

By the way, I found that TSC difference between cores stay within less than 500 without my crude synchronization code. Voodoo Kernel engineers must have done some smart job.

 

Will you try this one ?

This is what I am working on ( to support both Intel and AMD )

VoodooPower.kext.zip

 

Okay, I've tested and here are the results. I still get the jittering sound with idlehalt=0 cpus=2 but the sound jittering isn't as bad as before (sometimes it will jitter but still hearable in the past with the old kext it jitters and the sound is unberable because it's very distorted). The good side of the new kext is that when I boot with idlehalt=0 and cpus=1, the sound jittering goes away PLUS the system seems to run much faster (I test this by scrolling the dock application -- the dock images were lagging in the old kext and with this new one it's much faster). Autothrottle still works.

Link to comment
Share on other sites

I've updated the sources + built an installer package for the "Generic" kext and the "AMD" kext and tools.

Enjoy...

 

Hi Andy,

Does the AMD version have the fix for jittering sound when it's on autothrottling and cpus=2?

Link to comment
Share on other sites

I've updated the sources + built an installer package for the "Generic" kext and the "AMD" kext and tools.

Enjoy...

Andy, does "Generic" mean Superhai's original kext ? If so, it is almost "Intel".

Please try this one (source only). If it works with your Pentium M, it is likely to be "Generic".

 

VoodooPower.src.zip

 

I moved main file's vendor specific code into the other files for clear separation.

I hope this is my final release.

I wish Superhai grabs this code and make it the base for future enhancement.

Link to comment
Share on other sites

I wish Superhai grabs this code and make it the base for future enhancement.

 

I have started tinkering about version 1.3. Which will have a baseclass for generic non-cpu specific routines to create a nub with CPU matching information. It will allow the AMD part to be subclassed to its own kext, and I will create an Intel subclass kext. I think that is a better solution.

 

It also helps to sort out licensing issues. I have not been very anal about the license, but my source is not under GPL, and will not be. I have decided to extend licensing to "BSD" type. For me there are no problems adding GPL code but it will not be under GPL anymore, and linux folks who designed the original code might have issues seeing their source under BSD license. Therefore creating a new kext with the linux code in a subclass is a better solution.

 

In my plan I also will "snap" it into the location where AppleIntelCPUPowerManagement.kext connects to the kernel, so to totally replace it. Unless it breaks other important parts.

 

If you have comment please do so.

Link to comment
Share on other sites

I have started tinkering about version 1.3. Which will have a baseclass for generic non-cpu specific routines to create a nub with CPU matching information. It will allow the AMD part to be subclassed to its own kext, and I will create an Intel subclass kext. I think that is a better solution.

 

It also helps to sort out licensing issues. I have not been very anal about the license, but my source is not under GPL, and will not be. I have decided to extend licensing to "BSD" type. For me there are no problems adding GPL code but it will not be under GPL anymore, and linux folks who designed the original code might have issues seeing their source under BSD license. Therefore creating a new kext with the linux code in a subclass is a better solution.

 

In my plan I also will "snap" it into the location where AppleIntelCPUPowerManagement.kext connects to the kernel, so to totally replace it. Unless it breaks other important parts.

 

If you have comment please do so.

I agree.

I borrow the code from the linux sample driver on the AMD site even though most of them are obvious from AMD developer guide. I should have referenced *BSD ;) code.

I will write AMD code and attach appropriate license notice when 1.3 is ready. I am looking forward to your new announcement.

Link to comment
Share on other sites

Hi Superhai,

 

I'm looking forward to your next version. So far I'm pleased to the performance brought by VoodooPower, just little problem with the CPU temperature. :) I think I need to build custom cooling system where instead the fan powered by USB, it will powered by PSU, full throttle. :( Of course I will use more powerful fan. I have 17" laptop & it is heavy, so it is ok to have static cooling system.

 

Thank you. :)

 

kizwan

Link to comment
Share on other sites

I've updated the sources + built an installer package for the "Generic" kext and the "AMD" kext and tools.

Enjoy...

 

Hi Andy,

 

I installed the VoodooPowerAMD w/VoodooPower Tools, installed from the pkg installer you provided.

Upon reboot, I receive the message several times:

 

VoodooPowerAMD.kext: No PState table in ACPI

VoodooPowerAMD.kext: [Warning] Unloading

 

Also, when checking in GenericCPUPMControl, it says the kernel extension is offline.

Am I doing something wrong? Or, is there something else I needed to do for the kext to load properly?

Sorry, Im completely lost in this department.

 

As a side note, when I use Superhai's kext from his site, the kernel extension loads, but my the system studders very bad, and within 2 minutes i get kernel panic. Happens the same way everytime, until I remove the voodoopower kext.

 

Currently I am using Leopard 10.5.2, everything else remains the same in my sig.

 

Thanks!

Link to comment
Share on other sites

I installed the VoodooPowerAMD w/VoodooPower Tools, installed from the pkg installer you provided.

Upon reboot, I receive the message several times:

 

VoodooPowerAMD.kext: No PState table in ACPI

VoodooPowerAMD.kext: [Warning] Unloading

Unfortunately, your ACPI BIOS does not have _PSS table, from which my kext gets various information needed for p-state switching.

Link to comment
Share on other sites

Unfortunately, your ACPI BIOS does not have _PSS table, from which my kext gets various information needed for p-state switching.

 

Ah, I see then. Well thats a bit of a let down. If I had knowledge on how to emulate my BIOS to produce the _PSS table required, I sure would start right now, unfortunately, I am not, even if it were possible. :( I guess that really does conclude the fact BIOStar is an extremely poor choice for running Leopard on.

 

Thanks hnak, Superhai, and Andy, , I appreciate the efforts and time you all have put into this.

Link to comment
Share on other sites

Ah, I see then. Well thats a bit of a let down. If I had knowledge on how to emulate my BIOS to produce the _PSS table required, I sure would start right now, unfortunately, I am not, even if it were possible. :P I guess that really does conclude the fact BIOStar is an extremely poor choice for running Leopard on.

 

Thanks hnak, Superhai, and Andy, , I appreciate the efforts and time you all have put into this.

K10 (Phenom) does not need _PSS as its hardware p-state transition does not require the information.

As your MB (BIOSTAR TA780G?) supports K10, you will be able to use power management if you change the processor to K10.

-------- or -------

If you want to patch and build the kext from the source I posted in #236, I have a DOS tool to collect necessary information from BIOS.

Link to comment
Share on other sites

:( hnak, really confused here, because if I look at the CPU configuration in my BIOS (yes BIOSTAR TA780G), PowerNow is indicating that it generates the _PSS table.

post-334690-1237420919_thumb.jpg

 

Just a side note, the original GenericCPUPowerManagement.kext v1.1.4 does load and throttles my CPU and voltages, however, I receive many, many kernel panics everytime randomly during normal usage. So, I did not use this kext for stability issues on my machine.

 

I will try anything to get a working cpu management kext for my machine, the DOS tool you mentioned can gather the required information for voodoopower?

 

Thanks again hnak, i really appreciate your time and help :)

Link to comment
Share on other sites

:( hnak, really confused here, because if I look at the CPU configuration in my BIOS (yes BIOSTAR TA780G), PowerNow is indicating that it generates the _PSS table.

 

...

 

I will try anything to get a working cpu management kext for my machine, the DOS tool you mentioned can gather the required information for voodoopower?

 

Thanks again hnak, i really appreciate your time and help :)

TEST.EXE

This DOS utility works with Gigabyte MBs. However, I also found it doesn't work with some others.

It tries to detect string "AMDK7PNOW!" ( and data that follows ).

If it fails, "no psb found." message appears.

If it succeeds, it will show some information about Performance State Block (PSB) as indicated in AMD Bios Kernel developer's guide. I will tell you how to modify a source file.

 

From BIOS screen shot, you MB should support _PSS. I have seen some ACPI implementation of which trace fails in *BSD (probably succeeds in Windows).

Link to comment
Share on other sites

This DOS utility works with Gigabyte MBs. However, I also found it doesn't work with some others.

It tries to detect string "AMDK7PNOW!" ( and data that follows ).

If it fails, "no psb found." message appears.

If it succeeds, it will show some information about Performance State Block (PSB) as indicated in AMD Bios Kernel developer's guide. I will tell you how to modify a source file.

 

From BIOS screen shot, you MB should support _PSS. I have seen some ACPI implementation of which trace fails in *BSD (probably succeeds in Windows).

 

It appears to fail, giving me the "no psb found" message. I even updated my BIOS last night, it did have a couple of new features with ACPI, trying all of them 1 by 1 yielded no change though unfortunately. Thanks for all the help hnak, I'm starting to think this particular MB is jinxed :rolleyes:

Link to comment
Share on other sites

It appears to fail, giving me the "no psb found" message. I even updated my BIOS last night, it did have a couple of new features with ACPI, trying all of them 1 by 1 yielded no change though unfortunately. Thanks for all the help hnak, I'm starting to think this particular MB is jinxed :(

If you find someone who has the same CPU and a good MB, you will be able to get the info.

( What is your CPU signature ? rev.F or G ? )

It seems that switching to K10 is the easiest way to get power management work.

Link to comment
Share on other sites

If you find someone who has the same CPU and a good MB, you will be able to get the info.

( What is your CPU signature ? rev.F or G ? )

It seems that switching to K10 is the easiest way to get power management work.

 

an older screen I took:

post-334690-1237507572_thumb.jpg

 

Ok, K10 being the easiest way, I suppose this board is just not compatible with power management.

I had planned to upgrade to a deneb 940 and either a Gigabyte MB, or a DFI MB later this year.

I'm guessing the Gigabyte MB would be a better choice for running Lepard on.

Thanks once again for all your help hnak, I appreciate it!

Link to comment
Share on other sites

Ok, K10 being the easiest way, I suppose this board is just not compatible with power management.

I had planned to upgrade to a deneb 940 and either a Gigabyte MB, or a DFI MB later this year.

I'm guessing the Gigabyte MB would be a better choice for running Lepard on.

Thanks once again for all your help hnak, I appreciate it!

If you know how to modify source code and build programs, you might be able to implement your own kext.

 

My K8 (4050e) is basically manufactured with the same process, however with lower voltage range. Its test result is:

found PSB header at fad0:0
vstable = 5
rvo = 1
irt = 0
vidmvs = 2
plllock = 2
pstate count = 4
pstate 0 = fid(13), vid(14)
pstate 1 = fid(12), vid(15)
pstate 2 = fid(10), vid(17)
pstate 3 = fid(2), vid(22)

I explain how-to customize the kext completely at your own risk, using my CPU case.

Download the project files posted by Andy and locate the next part in amd.cpp.

		// Use ACPI to extract fid/vid
	vp->PStateCount = find_acpi_pss_table(vp->PState);
#if	USE_PSB
	if(vp->PStateCount == 0)
		vp->PStateCount = find_psb_table(PState);
#endif

Enable find_psb_table call by "#define USE_PSB 1"

 

Then completely replace the content of find_psb_table to:

static int find_psb_table(PStateClass* PState)
{
k8_data.vstable = 5;	// 100 micro, BIOS default
k8_data.rvo = 1;	// Ramp Voltage Offset
k8_data.irt = 0;	// 10 micro, BIOS default = 3 (80 micro)
k8_data.vidmvs = 2;		// max voltage step
k8_data.plllock = 2;	// 2 micro

PState[0].fid = 13;	// 10.5x
PState[0].vid = 14;	// 1.200V
PState[1].fid = 12;	// 10x
PState[1].vid = 15;	// 1.175V
PState[2].fid = 10;	// 9x
PState[2].vid = 17;	// 1.125V
PState[3].fid = 2;	// 5x
PState[3].vid = 22;	// 1.000V

return 4;
}

 

Your CPU's standard voltage range is 1.25 - 1.35 V (mine is 1.15 - 1.20), you need to modify vid values. Of course, you must change fids( PState[0].fid = 14 at least ). You must download "BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh Processors" from AMD to know appropriate values for fid/vid.

You also might have to change other values, as your MB vendor might use different values and you are overclocking fsb.

 

Good luck!

Link to comment
Share on other sites

If you know how to modify source code and build programs, you might be able to implement your own kext.

 

Honestly, I do not know the first thing about modifying source code or how to build programs. But, I will give it a shot, a big thank you for all your help and information.

Link to comment
Share on other sites

Hnak, I've tried the new VoodooPower on my friend's AMD Athlon64.

Immediately KP...

What could there be wrong as it works fine on all others?

Link to comment
Share on other sites

Hnak, I've tried the new VoodooPower on my friend's AMD Athlon64.

Immediately KP...

What could there be wrong as it works fine on all others?

KP did not occur with previous versions ?

What is the error type ?

Link to comment
Share on other sites

KP did not occur with previous versions ?

What is the error type ?

Well, it give immediately kp related to com.superhai.VoodooPower...

That's all I could gather, it happens immediately after load...

Link to comment
Share on other sites

Well, it give immediately kp related to com.superhai.VoodooPower...

That's all I could gather, it happens immediately after load...

KP should show error type like divide error, invalid memory access...

Please check if it happens when processorDriver() invocation is commented out.

If not, use debug build to see what kind of fid/vid values are detected.

--- edit ----

Please change the code in amd.cpp like:

muldiv(AMDGetK8Frequency(GlobalCurrent.fid),vp->CpuFSB,50*Mega)

to simply:

AMDGetK8Frequency(GlobalCurrent.fid)

(There are 3.)

CpuFSB may not be always correctly detected in AMD.

Link to comment
Share on other sites

 Share

×
×
  • Create New...