AnVAL (ACPI Loader)

[valv]

Yes, if busratio is working and also it does limit PState i would comment the usage of busratio with " also limit fastest PSate to busratio".[/i]

I think I'd vote for something like: "P-State: Already using bus-ratio injection! PStart key will have no effect." just to give users plenty of choices.

 

Only i cant get rid of C3 State, even i use EnableC2State=Yes (should disable C3,C4,...)

did you also got rid of EnableC3State=No & GenerateCStates=Yes ?

 

Thanks. It would be very nice if the GPU is supported in OSX. The Dell is not a mistake since I bought it for work reason. The Asus was for OSX to be honest but it is a mistake since I didn't know it have Optimus switchable graphic card (poor advertisement). But at least it have good GPU for gaming.

we 'll see what would happen next's on the scene.

[mitch_de]

No, i used GenerateCStates=Yes always beside EnableC2 / C3.

So i must set GenerateCStates=No together with EnableC2..= Yes ?

That was unclear for me - maybe renameing / or commenting thats GenerateCStates does mean ALL,

and if someone want to limit he has to set it to NO and add the EnableC2 or the others.

Unclear: How to enable only C1 - because there is no EnableC1State key.

 

Also maybe usefull to tell the users (early bird versions ) that the key MoreVolt = uses NOT mV as value.

I tested with 40 and now 10 as value.

P-State: Added [Frequency 2997 MHz, FID 0x9, VID 0x2c]

with 40 it was 0x2d, diff of one in VID means 32mV diff (for my knowledge)

without any MoreVolt it was :VID 0x20, so diff of 10 MoreVolt gives 0c (dez 12) more VIDs - each 32mV = 300mV insted of 10mV wanted?

So any user who wants to use MoreVolt should start with very less values like 2..4 and look after the generated VIDs (compared to the dsdt ones or generated without moreVolt)

[valv]

No, i used GenerateCStates=Yes always beside EnableC2 / C3.

remove GenerateCStates=Yes altogether.

 

Unclear: How to enable only C1 - because there is no EnableC1State key.

Use EnableC2State=No, and look what happens; but without GenerateCStates (this one is used only in case you want to enable every c-state without knowing which one is actually supported by your cpu).

[mitch_de]

"remove GenerateCStates=Yes altogether."

Sir, Yes SIR

No changes : C-State: Adding 3 states: C1 C2 C3

I removed the GenerateCStates key complete (not set No) , left EnableC2State=Yes

PS: No probs at least

[valv]

"remove GenerateCStates=Yes altogether."

Sir, Yes SIR

No changes : C-State: Adding 3 states: C1 C2 C3

I removed the GenerateCStates key complete (not set No) , left EnableC2State=Yes

PS: No probs at least

ok, I 'll give it a look!

[kizwan]

@valv,

 

This is bdmesg output on Dell Studio:-

Studio1557_boot_5.txt

[mitch_de]

To all:

dutchkockeypro: "Apple may have changed their OSPM code for (certain) Intel Core iN CPU's. Went back (from 10.6.5) to OS X 10.6.4 to check (with the same booter and P_States) and everything is fine again."

 

Because i now seen again the posting one site back about some changes in 10.6.5 (Pstates) i am unsure if they work!

I am sure they worked before with my dsdt (and must work with autogen).

The Mark-i (uses an kext to read out MSR) can check that. (If you dont have winbond IO Chip it also shows values for Fan, Volt but they are wrong - doenst matter for the MSR cpu temp and MHz/busratio readings also shown)

http://www.insanelymac.com/forum/index.php?showtopic=190060 - you can use kextload to load the ring.kext, no need to install that!)

For me it stays always at max. Mhz, doesnt matter which load on CPU

We should now try to find out to be sure have an method to see the real (MSR) MHz to check if the generated Pstates (or similar dsdt Pstates) really work! Coolbook has its own strategie ( i asked the dev) - which isnt Speedstep - useless.

I am not 100% sure but 90% that also the command : sysctl hw.cpufrequency should list the chaning CPU Mhz.

[valv]

see the real (MSR) MHz to check if the generated Pstates (or similar dsdt Pstates) really work!

agreed!

 

In the main time, come-on Core-i guyz! Only kizwan is testing or was he the only one who's giving feedback ?

Please, test this one! It 'd help to know if Turbo is ok or if it needs more work. Also, I'd like to see your bdmesg with p-states auto-generator.

 

Here: boot 6 is now useless

[crencom]

Im testing the Boot6 and have tested all previous versions. I have a Samsung r530 Core i3 350m - Geforce 310m. I have only had this notebook for a couple of weeks. I have attached bdmesg and boot.plist. Please offer any other ideas if needed on the boot.plist.

bootplist.rtf

bdmesg.rtf

[valv]

@crencom, hi! And thank you for testing.

btw, could mind using this command (for sanity): bdmesg > Desktop/bdmesg.txt

edit it (if u want to remove some private info like uuid) and then upload it again.

Thank u for understanding.

edit:

- don't use PStates key if you want all of them or give 0 as value.

- use SystemType instead of PMProfile (for what is PMProfile ?)

- u can use -x64 instead of -arch=x86_64

- GeneratePStates (u don't have it on boot.plist, even-though u showed bdmesg with pss generated)

 

@mitch_de, and all speed-steppers over here, look at this screenshot (sorta proof of concept) without an smc_platform_plugin legacy kext:

EDIT: the values on terminal (green scares) disappeared in 64bit mode

EDIT2: values in green where not vanilla! sorry, false positive

[Maniac10]

Valv, how can I help you troubleshoot my video enabler problem? For now this is my new bdmesg dump:

 

[JBraddock]

@mitch_de, and all speed-steppers over here, look at this screenshot (sorta proof of concept) without an smc_platform_plugin legacy kext:

I got a 512MB flash drive from a friend so I can do testing. You know my configuration and kexts I am using.

 

I should remove:

 

- smc_platform_plugin legacy kext

- SSDT tables from Extra folder

What else?

 

I am using your previous boot.plist so tell me how to change them. Which keys I should need to add or change?

Mac model is set to MacbookPro5,4 as you know.

[crencom]

Valv - The turbo function you mentioned. I am new to these Core I3 processors so my knowledge is limited. I noticed on verbose boot for "appleintelcpupowermanegement- Turbo Ratio=0000" Is that turbo what you are talking about? Doesn't seem right to have all 0000s?

 

scott

[valv]

First, here is the nth test: boot7 is now useless

 

@JBraddock, those are the steps I took:

• Removed the platformplugin thingy from our legacy kext
  
• rebuilt mkext to /Volumes/EFI/Extra/10.6/Extensions.mkext
  
• reboot into 32bit mode
  

other than that, I still use mbp5,3 as model

EDIT: sorry, it is mbp5,4

my boot.plist is this: Bootplist.zip

 

@crencom, should u try boot7, please post your bdmesg.

 

@eMatoS, sorry! I to time have no idea. I'll study it further and keep you informed

 

@mitch_de, the thing with c-states wasn't an issue: c2 & c3 are special states that get enabled (relying on fadt) even if you specify not to. I'll see what I could do.

[kizwan]

Valv - The turbo function you mentioned. I am new to these Core I3 processors so my knowledge is limited. I noticed on verbose boot for "appleintelcpupowermanegement- Turbo Ratio=0000" Is that turbo what you are talking about? Doesn't seem right to have all 0000s?

 

scott

It actually make sense since i3 processor don't have Turbo Boost. You can check it at Intel website. So, Turbo Ratio=0000 is correct.

[The Edge3000]

It seems that all my motherboard/CPU needs for speedstep is c-states?

GeneratePStates = Yes -> ALWAYS results in instant reboot right after bootloader defines c-states

 

I tested the following conditions:

c-state and p-sate defined in dsdt, no c-state gen.-> 46ºC, speedstep works

no c-state in dsdt, c-state gen............................-> 46ºC, speedstep works

no c-state in dsdt, no c-state gen.......................-> 60ºC, no speedstep

no c or p-state in dsdt, c state gen....................-> 46ºC, speedstep works

no dsdt at all, c state gen..................................-> 60ºC, no speedstep

 

Also, without any dsdt whatsoever the system boots in 3 revs vs 11 it normally takes, albeit without any of my dsdt fixes like sleep/USB/speedstep/ect.

 

bdmsg for when c state gen is active:

Found ACPI CPU: CPU1
Found ACPI CPU: CPU2
Found ACPI CPU: CPU3
Found ACPI CPU: CPU4
C1 C3 C6
FADT: Restart Fix applied !
Patched ACPI version 2 DSDT
Starting Darwin x86_64

 

EDIT: I get the same results regardless of CPU clock (266 mhz vs 333 mhz FSB).

I can use the same p-states in the DSDT for both OC and non OC or not define p-states at all, but as long as c-states are either generated or defined, speedstep works.

[Oxtie]

hmm... I got iAtKoS s3 and choose AnVal (which worked and rest all failed). Upgrading to 10.6.4 worked, updating to that graphics update crashed and upgrading to 10.6.5 also crashed... (since noobs like me were feeded with distroz, its hard to go back to level 1) Now, all i did was extracted your files to OSX drive from WIN (macDrive) and the result is same stuck at ACPI plugin or something power management related

 

Screenshot

[kizwan]

@valv,

 

These are bdmesg output on Dell Studio.

1) Without GeneratePStates:-

- Speedstep working

- Turbo Boost working

- In IOReg, there are 7 entry under PerformanceStateArray

Studio1557_boot_7.txt

 

2) With GeneratePStates (just in case you want to see the bdmesg output if using GeneratePStates):-

- Speedstep not working

- Turbo Boost not working

- In IOReg, there is no PerformanceStateArray

Studio1557_boot_7_G.txt

 

I didn't use smc_platform_plugin legacy kext.

[Rik26]

Hi! I've a fully working Speedstep with DSDT but I wanted to try this bootloader (I've the latest version).

Without options (P-states, c-states generation) my system boots normally but If I add P-states and c-states generation in com.apple.boot.plist my hack reboot automatically after ffffffff at apple logo. This is my bdmesg without p-c states generation (boot ok)

bdmesg.rtf

[mitch_de]

"I tested the following conditions:

c-state and p-sate defined in dsdt, no c-state gen.-> 46ºC, speedstep works

no c-state in dsdt, c-state gen............................-> 46ºC, speedstep works

no c-state in dsdt, no c-state gen.......................-> 60ºC, no speedstep

no c or p-state in dsdt, c state gen....................-> 46ºC, speedstep works

no dsdt at all, c state gen..................................-> 60ºC, no speedstep"

To all : which way or measuremet Tool do you use to see if speedstep is working (MHt changing by cpu loads) or not ?

Would also be nice to now , by test of an users which knows speedstep is runnung well (Tool?) if the terminal command can also be used or not : sysctl hw.cpufrequency . Also nice if someone with older OS X (10.5 / 10.6.4) would try that command and report if MHz changes like with other MHz measurement tools. I ask because most tools (without an MSR.kext to read out CPU ) measures/shows always an fixed, the highest possible MHz (like Systemprofiler, cpu-x,...)

Q to the user no c or p-state in dsdt, c state gen....................-> 46ºC, speedstep works :

does you in these thests always also used P-States autogen Gen ? .

I ask because not said about that but i think it must be used (C State only by autogen but no Pstates at all cant Speedstep working , or?)

 

@mitch_de, and all speed-steppers over here, look at this screenshot (sorta proof of concept) without an smc_platform_plugin legacy kext:

EDIT: the values on terminal (green scares) disappeared in 64bit mode

 

Thanks.

Can you upload the MSRTool (lift side of the picture) somewere ?

I have one, but perhaps older version and this version stalls after some seconds or even didnt start.

Can you run that MSR Tool in 64 Bit Mode also or perhaps thats the reson for my prob ?

For my knowledge Coolbook does its own way and overwrites hand made (injected) Pstates. So you see NOT your Pstates working or not.

IDEA: We collect some working speedstep measure tools (with info 32Bit or 32/64Bit) in the first valv posting - so all can test reliable und easy

[mitch_de]

To all : I use an ACPI_PPM kext (in Extra ) in the past for injecting the powermanagent for my system.

The orig. .kext which does this / gets the injected data is IOPlatformPluginFamily.kext (there plugin ACPI_SMC_Platform....) . In this Resoources there are all used .plist for the powermanagement (CPU+GPU in one) sorted by the model name.

I can see some changes - some keys added / changed to my legancy inject - needs to be "recreated". Use fitting modell-plist as model for the own in Legancy .plist.

Maybe such changes may also be an reason Speedstep not working anymore without changes in dsdt/autogen.

[The Edge3000]

Q to the user no c or p-state in dsdt, c state gen....................-> 46ºC, speedstep works :

does you in these thests always also used P-States autogen Gen ? .

I ask because not said about that but i think it must be used (C State only by autogen but no Pstates at all cant Speedstep working , or?)

That's the funny thing... I can define my processors as this in the DSDT:

	Scope (_PR)
{
	Processor (CPU1, 0x01, 0x00000810, 0x06){}
	Processor (CPU2, 0x02, 0x00000810, 0x06){}
	Processor (CPU3, 0x03, 0x00000810, 0x06){}
	Processor (CPU4, 0x04, 0x00000810, 0x06){}
}

...and all I need is the injected c-states or c-states defined in the DSDT to get speedstep working.

No matter what I do - stock speed vs OC vs various DSDTs - GeneratePStates ALWAYS causes a reboot.

I thought that maybe the bootloader could be loading the SSDT tables from my motherboard and that they just worked, but when I leave off the DSDT all together, even with GenerateCStates, speedstep doesn't work.

Is there a good utility to extract/view the SSDT tables? Everything I've found is DSDT only, and RW-Everything on windows crashes when loading the SSDT tables.

 

Also, I can use VoodooMonitor in E/E to see the actual speedstepping, but the thermal readings are pretty much a dead giveaway.

[kizwan]

...and all I need is the injected c-states or c-states defined in the DSDT to get speedstep working.

No matter what I do - stock speed vs OC vs various DSDTs - GeneratePStates ALWAYS causes a reboot.

What happen if you removed the c-states & p-states injection from DSDT & try again the GeneratePStates?

Is there a good utility to extract/view the SSDT tables? Everything I've found is DSDT only, and RW-Everything on windows crashes when loading the SSDT tables.

I use Everest to extract ACPI tables (DSDT, SSDT, etc) in Windows but you need to have a license to do that. There is a way to dump DSDT & SSDTs tables in OSX using ssdtboot_chameleon2 which available in this thread. I haven't use this tool for a long time but it should work.

[MiniHack]

While on my i5 430M the p-states seem to generate fine, there is no evidence of them actually being used.

 

For instance, in latest boot7, MSR tools shows both freq.s (actual and max) as identical and running geekbench at same time causes no variation.

 

As I mentioned in an earlier post though, I have to keep the nullcpupowermanagement kext to avoid KP so maybe it is because I have no working power management kext to actually use the values (and yes I have enabled speedstep in BIOS).

[rednous]

valv, I notice the CPUFreq is reported 0 with boot6 & boot7:

 

CPU: TSCFreq: 2933MHz
[b]CPU: CPUFreq: 0MHz[/b]
CPU: FSBFreq: 266MHz