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

Hello Superhai.

 

Pleae do not drop support for AMD.

 

This way you can preserve the work you have done already and provide a bright future for AMD users.

 

Please do not sponser intel by not supporting AMD etc!

 

Thats just my opinion tho!

 

To all AMD users, get your bug reports in ASAP!

 

By the way, well done Superhai!

 

HC

 

:(

Link to comment
Share on other sites

Hello Superhai.

 

Pleae do not drop support for AMD.

 

This way you can preserve the work you have done already and provide a bright future for AMD users.

 

Please do not sponser intel by not supporting AMD etc!

 

Thats just my opinion tho!

 

To all AMD users, get your bug reports in ASAP!

 

By the way, well done Superhai!

 

HC

 

:thumbsup_anim:

 

Sorry, not my opinion.

And that, not only because i am an intel user (not intel fan!)!

Its quite simple:

Why should such heros waste their time with AMD nightmares - especially if they own no AMD-Testhadrware!!-

if the result will (for such hobbiests) never be 100% error free ?

 

Look at the voodoo mac kernel dev group : 90% of the dev time and troubles ONLY! by trial&error

to fix lots of AMD bugs/troubles.

I dont think they get an 100% working AMD 10.5.6 (available now 10.5.5 voodoo kernel) before 10.5.8 is realsied !

Thats not because the devs are to dump . its an very hard work to get that all done for AMD without at least 3-4 cpu different Test-AMDsystems in THEIR hand for debugging !

 

AMD users feel free to switch to intel - you wil have lots of trouble with OSX86 fixed at once !

Link to comment
Share on other sites

...

And that, not only because i am an intel user (not intel fan!)!

Its quite simple:

Why should such heros waste their time with AMD nightmares - especially if they own no AMD-Testhadrware!!-

if the result will (for such hobbiests) never be 100% error free ?

 

Look at the voodoo mac kernel dev group : 90% of the dev time and troubles ONLY! by trial&error

to fix lots of AMD bugs/troubles.

I dont think they get an 100% working AMD 10.5.6 (available now 10.5.5 voodoo kernel) before 10.5.8 is realsied !

Thats not because the devs are to dump . its an very hard work to get that all done for AMD without at least 3-4 cpu different Test-AMDsystems in THEIR hand for debugging !

 

AMD users feel free to switch to intel - you wil have lots of trouble with OSX86 fixed at once !

 

Sorry, but you do sound like an intel fanboy... No offense... :)

Wanna trade me an intel quad for my Phenom X4? :)

 

Like I've stated before, not everyone has an intel setup and would want to shell out more $$$ to get a brand new intel setup.

And as far as compatibility goes, I couldn't upgrade my friend's Centrino Duo (which, of course, has an intel cpu, intel chipset, intel LAN, and intel WiFi) notebook to 10.5.6. It's either my incompetence, or some incompatible hardware. But since it's an all intel solution, all the hardware must be 100% compatible, so I'd go with the former. ;)

 

What's the point of OSX86 if it doesn't run on generic x86 systems? It should then be called OSX-on-intel-pc-boxes instead...

As long as it's called OSX86, we, non-intel users will patiently wait for the dev gurus, while contributing wherever we can.

 

It's about spreading the goodness of Mac OS X to the masses.

And if you're really that impatient, go ask the devs for an intel-only release. If what you said about dev time is true (90% wasted on ironing out AMD problems), I'm almost certain they already have your intel-only release ready.

Link to comment
Share on other sites

Sorry, but you do sound like an intel fanboy... No offense... :D

Wanna trade me an intel quad for my Phenom X4? :P

 

Like I've stated before, not everyone has an intel setup and would want to shell out more $$$ to get a brand new intel setup.

And as far as compatibility goes, I couldn't upgrade my friend's Centrino Duo (which, of course, has an intel cpu, intel chipset, intel LAN, and intel WiFi) notebook to 10.5.6. It's either my incompetence, or some incompatible hardware. But since it's an all intel solution, all the hardware must be 100% compatible, so I'd go with the former. :D

 

What's the point of OSX86 if it doesn't run on generic x86 systems? It should then be called OSX-on-intel-pc-boxes instead...

As long as it's called OSX86, we, non-intel users will patiently wait for the dev gurus, while contributing wherever we can.

 

It's about spreading the goodness of Mac OS X to the masses.

And if you're really that impatient, go ask the devs for an intel-only release. If what you said about dev time is true (90% wasted on ironing out AMD problems), I'm almost certain they already have your intel-only release ready.

 

Dont worry about my opinion. But its really an problem to develop / make OS X86 running 100% perfect for AMD. Some things are different. Thats all.

AMD isnt bad or less fast than Intel, only - superhais much, much work to get most AMD CPUS working with speedstep/AMDs Cool&qiet wasnt successful for all AMDs.

Thats like the voodoo kernel develop: The project started much fast and lots of AMD things worked - but later, after more AMD users tested deeply mor+more problems came up.

I would be glad if you AMD users also get all things running, no question.

 

But here, superhais AMD work is more like COOL&QUIT than COOL&QUIET - perhaps collecting some money for an AMD test system would help superhai or the kernel (voodoo) project to develep for AMD much better.

Link to comment
Share on other sites

Dont worry about my opinion. But its really an problem to develop / make OS X86 running 100% perfect for AMD. Some things are different. Thats all.

AMD isnt bad or less fast than Intel, only - superhais much, much work to get most AMD CPUS working with speedstep/AMDs Cool&qiet wasnt successful for all AMDs.

Thats like the voodoo kernel develop: The project started much fast and lots of AMD things worked - but later, after more AMD users tested deeply mor+more problems came up.

I would be glad if you AMD users also get all things running, no question.

 

But here, superhais AMD work is more like COOL&QUIT than COOL&QUIET - perhaps collecting some money for an AMD test system would help superhai or the kernel (voodoo) project to develep for AMD much better.

 

Nah, everyone has a right to make an opinion. It's just that you've made it sound like it's the fault of non-intel user's that the development of OSX86 doesn't go faster. But now that that's cleared up, I agree that it's harder to make everything work 100%. Not just for AMD, but also for non-Apple-like intel hardware. It would be a dream to see a 100% x86 compatible OS X. ;)

 

LOL. Cool&Quit. That's funny. :)

Link to comment
Share on other sites

Yeah - so i meaned it - dev such things is hard so some fun is a must have :(

When those devs would have also access to AMD hardware they could test & dev much easier i think.

Its an absolute magic that such things like speedstep or the voodoo kernel is developed mostly without having AMDs (no at home) PCs.

Link to comment
Share on other sites

...snip...

Its an absolute magic that such things like speedstep or the voodoo kernel is developed mostly without having AMDs (no at home) PCs.

 

From what I've seen, those dev gurus tend to have some magic up their sleeves, as long as those reports keep coming in. :(

Link to comment
Share on other sites

Work like a charm on C2D T9300 2.5 GHz. The app gives wrong values, but i checked with MRS and it is fine.

Great job Superhai, it's nice to have guys like you who does so much work for Leo on PC.

Thanks a lot

Link to comment
Share on other sites

VoodooPower (1.2.1) leads to seemingly random kernel panics on MSI Wind when on battery power.

 

A somewhat reliable way to reproduce this is to:

  • Run from battery
  • Open a mp4 file in QuickTime player
  • Drag the icon of another mp4 file onto the already open QuickTime player window (this joins the two files)
  • Repeat this until you get a kernel panic

I only get kernel panics when running from battery, not when running from AC.

 

Can anyone reproduce this?

Link to comment
Share on other sites

Hi Superhai,

Thank you for your great work. My notebook run much cooler after using your VoodooPower v1.2.1. My notebook now able to get higher result with Geekbench 2. More 1000 than usual score. This time it show almost the same Geekbench 2 score that I got in windows.

 

Thank you. :)

 

kizwan

Link to comment
Share on other sites

Does it make technical sense that VoodooPower and/or the SMBIOS kext can make running from battery more prone to kernel panics? I seem to get lots of kernel panics when running the MSI Wind from battery and doing something with high CPU usage (especially QuickTime). When i plug it into power, I don't get these kernel panics (despite the fact that VoodooPower does clock down the processor as well in either case...)

Link to comment
Share on other sites

I have the same bug, I can't shut down. I had to Uninstall :D

 

hmmm maybe thats what happen to my shutdown.... thing is mine works for like the first 10 min or so. Same with restart.

 

How do i uninstall this thing?

Link to comment
Share on other sites

Does it make technical sense that VoodooPower and/or the SMBIOS kext can make running from battery more prone to kernel panics? I seem to get lots of kernel panics when running the MSI Wind from battery and doing something with high CPU usage (especially QuickTime). When i plug it into power, I don't get these kernel panics (despite the fact that VoodooPower does clock down the processor as well in either case...)

 

Seem like your battery can't deliver enough juice to your cpu.

Link to comment
Share on other sites

I tested VoodooPower.kext with my K8/K10 systems.

It did nothing in K10, and froze K8.

(I reported the behaviors about GenericCPUManagement in superhai.com)

 

After AMD support was abandoned, I downloaded VoodooPower1.2.1 source and investigated the AMD part.

I compared it with open source linux frequency driver and figured out the problem.

 

The original code tries to read p-state values from K10 registers and it works, but K10 transition code was wrong.

It generates the p-state table in K8 procedurally, and tries to execute transitions with hard-coded timing values. As the values are not appropriate (at least for my system, 4050e), it hangs.

 

So, I modified the VoodooPower.cpp to incorporated linux cpu driver logic (reading timing constans from ACPI, using K10 hardware transition). The built code works with my K8/K10 systems. (I am now sure if it really wors, but it does not crash instantly at least)

I did not touch anything other than VoodooPower.cpp's AMD part (probe(), processorDriver(), etc.).

 

Here I upload the modified source.

If interested in making VoodooPower.kext wok with AMD, download the original from superhai.com and replace VoodooPower.cpp with this one. To simplify debugging, I removed Intel code.

 

---

Feb 9, update to prevent K8 kernel panic. ( removed rtc_* calls ).

VoodooPower.cpp.zip

Link to comment
Share on other sites

@vani and SuperHai

 

I was having similar kernel panics on my Wind. I then disabled TState throttling. That helped a LOT. Not a single crash since.

Link to comment
Share on other sites

After AMD support was abandoned, I downloaded VoodooPower1.2.1 source and investigated the AMD part.

I compared it with open source linux frequency driver and figured out the problem.

The original code tries to read p-state values from K10 registers and it works, but K10 transition code was wrong.

It generates the p-state table in K8 procedurally, and tries to execute transitions with hard-coded timing values. As the values are not appropriate (at least for my system, 4050e), it hangs.

 

So, I modified the VoodooPower.cpp to incorporated linux cpu driver logic (reading timing constans from ACPI, using K10 hardware transition). The built code works with my K8/K10 systems. (I am now sure if it really wors, but it does not crash instantly at least)

I did not touch anything other than VoodooPower.cpp's AMD part (probe(), processorDriver(), etc.).

 

I have not yet decided wheter to go on with amd or abandon the work. I am looking a bit on the new bug reports coming in. But lots of other work and also other things have put the entire project a bit in the shadows for the moment.

 

I used the ACPI approach on the earlier versions, but has removed it for support for advanced features in Chameleon etc. ACPI have also major flaws on a wide variety of m/b's and I really don't want to depend on it. I also know different timing values, and found it in the AMD documents, but they are not consistent, so I needed testers to try out to find correct values. K10 transistion I found out, and I have new version planned.

Link to comment
Share on other sites

I used the ACPI approach on the earlier versions, but has removed it for support for advanced features in Chameleon etc. ACPI have also major flaws on a wide variety of m/b's and I really don't want to depend on it. I also know different timing values, and found it in the AMD documents, but they are not consistent, so I needed testers to try out to find correct values.

FYI.

As far as I observed (by disabling processorDriver()), the K8 vid values of the original code were quite different from ACPI default . In fact, they were all zeros, which means the highest voltage and seemed dangerous to me.

 

Though I admit ACPI has many flaws, acquiring the default p-state values from _PSS does not seem so bad to me, as it is not a function and (mostly) linux works with the code.

Link to comment
Share on other sites

does voodoopower and xnu speedstep http://code.google.com/p/xnu-speedstep/ are the same thing which handle the speedsteep function of CPU ?

 

Yeah, both do speedstep with the steedstep function of the CPU (must support EIST, BIOS must enable that).

But superhais has some features beside the basic speedstep function (which do BOTH!!)

- some AMD CPU may work

- more configurable in the .plist

- has an api to superhais control tool which does show MHZ/TemP... in Menue or in an window

that control app must NOT! run always, only if you want to show the values of MHZ/temp) - if you exit this app, speedstep works with the settings in the .plist of voodoo.kext all the time until you reboot

Link to comment
Share on other sites

Hi, Superhai. :)

 

GenericCPUPMControl used to work great with iPC Beta on my rig, but Voodoo Power with iPC PPF5 kernel panics every minute or so.

 

Otherwise, I installed most of the some drivers:

 

Vanilla Kernel

ICH10 Chipset

DSDT (1st on the list)

 

The only difference is the SMBios. I switched an AppleSMBios v.1.1.1 I was given by someone for your SMBios Resolver.

Link to comment
Share on other sites

 Share

×
×
  • Create New...