Trying to get speed stepper fixed.

[takeawaydave]

Looking at trying to get speed stepper fixed. Done what I think is right and created a custom SSDT manually since the ssdtPRgen.sh doesn't support Nehalem. I am running 2x Xeon x5660. With SSDT.aml in /Extra I see:

 

Read HFS+ file: [hd(0,1)/Extra/DSDT/DSDTv1.01f.aml] 27257 bytes.

Read HFS+ file: [hd(0,1)/Extra/SSDT.aml] 8532 bytes.

ACPI Table not found: SSDT-1.aml

FADT: ACPI Restart Fix applied!

FADT: Using custom DSDT!

OEM SSDT tables was dropped

RSDT: Added 1 SSDT table(s)

FADT: ACPI Restart Fix applied!

FADT: Using custom DSDT!

OEM SSDT tables was dropped

Added 1 SSDT table(s) into XSDT

Starting Darwin x86_64

 

mira:~ david$ sudo dmesg | grep AppleIntelCPUPower

AppleIntelCPUPowerManagement: Turbo Ratios 222233

AppleIntelCPUPowerManagement: (built 22:16:38 Sep 19 2013) initialization complete

AppleIntelCPUPowerManagementClient: ready

 

mira:~ david$ kextstat | grep AppleLPC

70 0 0xffffff7f81cf5000 0x3000 0x3000 com.apple.driver.AppleLPC (1.7.0) <59 11 5 4 3>

HWMonitor shows:

P & C States in SMC Monitor show

I don't believe MSRDumper works on 1st ge. Nehalem since nothing is returned….

Question is when the machine is idling how do I make it go in to its lowest p-state ? Currently it sits at above 2000 MHz with no real power management.

smbios.plist:

I think I am close here but something is not right yet.... Any help really appreciated

Archive.zip

[m.gbt]

I see some mistakes in your SSDT... Take this snippet as example:

            Package (0x06)
           {
               0x0AF0, 
               Zero, 
               0x0A, 
               0x0A, 
               0x2000, 
               0x2000
           }, 

           Package (0x06)
           {
               0x0A6B, 
               Zero, 
               0x0A, 
               0x0A, 
               0x1900, 
               0x1900
           }, 

You've gone from 0x1900 to 0x2000 but that's hex code, 19 -> 1A.

Check this snippet on my SSDT generated by ssdtPRGen:

            Package (0x06)
           {
               0x03E8, 
               0x26B8, 
               0x0A, 
               0x0A, 
               0x0A00, 
               0x0A00
           }, 

           Package (0x06)
           {
               0x0384, 
               0x2270, 
               0x0A, 
               0x0A, 
               0x0900, 
               0x0900
           }, 

Also from the snippets above, f you notice, instead of "Zero" I have some actual values, related to the CPU Power at that frequency. But I can't help with that nor tell you if that's critical for your problem.

Your frequency value doesn't match with your step value:

Package (0x06)
           {
               0x0640, 
               Zero, 
               0x0A, 
               0x0A, 
               0x1100, 
               0x1100
           }

0x640 = 1600Hz

0x11 = 15

And finally (but this should be first), Nehalem has steps of 133,33Hz instead of 100Hz so I believe your SSDT should be written accordingly, you're making steps of 100Hz there, that might give some conflicts.

http://www.insanelymac.com/forum/topic/181631-dsdt-vanilla-speedstep-generic-scope-pr/

P-States calculator should help you.

Good luck!

[takeawaydave]

I see some mistakes in your SSDT... !

 

Thanks for the reply seems like I don't know if I am coming or going...

I think I may have been staring the answer in the face for probably a few weeks at least. In fact since I made a successful DSDT edit to get AppleLPC loaded.

I have reverted back to an older DSDT version - I observe the following:

and the following when running Geekbench2

Is this enough to confirm that native power management is setup and working ?

I feel a bit dumb...

[m.gbt]

I don't know a method to tell if a Nehalem has correct power management as AppleIntelCPUPowerManagementInfo wasn't made for it... I hope someone more experienced can help you

[artur-pt]

hello

only use p and c-states=Yes

or

extract u original ssdt tables and use it

DropSSDT=Yes

P and C-states=No

and test

good hack

[takeawaydave]

hello

only use p and c-states=Yes

or

extract u original ssdt tables and use it

DropSSDT=Yes

P and C-states=No

and test

good hack

 

Hello - yes this is what I tried. Extracting SSDT proved tricky. I tried it from linux and received incomplete garbage. ssdtPRgen.sh also doesn't work on Nahalem processors - hence my attempt at building one manually...

any other ideas on how to extract one ? Or any thoughts on previous post of mine ?

[m.gbt]

Instead of making any modifications to the SSDT, artur is telling you first to try to use the automatic states generator included in whichever bootloader you use. You do it simply by using the keys Generate P-States and C-States = Yes.

Then if that doesn't work for you, the second thing artur suggested is to use the clean extracted SSDT. If you believe Linux is not giving you a correct extraction, I recommend you to install Clover to a FAT32 USB drive as Legacy, boot into Clover and then press F4 to save all your ACPI tables to the drive. Then they will all be inside the folder USBDrive/EFI/CLOVER/ACPI/origin.

[artur-pt]

hello

u can also extract it from windows

good hack

[takeawaydave]

OK looks like no SSDT - clover seemed to have become unresponsive when trying to extract by pressing F4 and Window AIDA64 tool doesn't at least me appear to have the ACPI Dump command.

I have set to P + C states = Yes and I do see a lower multiplier jn use most of the time getting higher when load is applied.

I ran a Geekbench score and I have dropped 2000 points to 22000 with these options. Is this normal ? I read more about people seeing increases when speed stepping is enabled.

[takeawaydave]

ok realised that this configuration is not enabling the 3 turbo states....hence the lower score.

[takeawaydave]

Just thought I'd make a note on how to extract the ACPI tables from Windows now that AIDA64 doesn't include the ACPI dump command anymore and the earlier versions of AIDA64 that do have the ACPI Dump command don't support Windows 8.

I did the following:

1. Downloaded the tools from here:

https://www.acpica.org/downloads/binary-tools

2. Ran dump command redirecting to a dat file:

 

C:\Users\David>C:\Users\David\Downloads\iasl-win-20140214\acpidump.exe > C:\Users\David\acpi.dat

 

3. Extract the separate tables using the extract command:

C:\Users\David>C:\Users\David\Downloads\iasl-win-20140214\acpixtract.exe -a acpi.dat

 

Intel ACPI Component Architecture
ACPI Binary Table Extraction Utility version 20140214-32 [Feb 14 2014]
Copyright (c) 2000 - 2014 Intel Corporation

Acpi table [DSDT] - 26189 bytes written to dsdt.dat
Acpi table [XSDT] - 140 bytes written to xsdt.dat
Acpi table [FACS] - 64 bytes written to facs.dat
Acpi table [FACP] - 244 bytes written to facp.dat

 

4. Decompile the dat files to dsl files using the following such commands:

 

C:\Users\David>C:\Users\David\Downloads\iasl-win-20140214\iasl.exe -d C:\Users\D

avid\dsdt.dat

Intel ACPI Component Architecture

ASL Optimizing Compiler version 20140214-32 [Feb 14 2014]

Copyright © 2000 - 2014 Intel Corporation

Loading Acpi table from file C:/Users/David/dsdt.dat - Length 00026189 (00664D)

Acpi table [DSDT] successfully installed and loaded

Pass 1 parse of [DSDT]

Pass 2 parse of [DSDT]

Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)

Parsing completed

Disassembly completed

ASL Output: C:/Users/David/dsdt.dsl - 255078 bytes

 

This will leave you with a set of decompile ACPI tables with dsl extensions that can be opened, corrected and added to using DSDT Editor.

______________________

Now for some strange reason I STILL did not get an SSDT extracted. It seems my machine doesn't use one at all. Any suggestions on how to Turbo working appreciated.