GA-EX58 and GA-X58A DSDT native power management modifications

[LocusOfControl]

Be sure the voltage for your RAM is high enough. I had to up mine to 2.1v before it ran stable. Auto was only giving it 1.8v. Check the specs for your RAM. Make sure you set the timings too. You can check out my BIOS settings in my signature however I have a P45 MOBO some of it will apply to you.

 

 

Thanks for the tip, when I overclock I can get to 4GHz but I have to run the RAM really slow eg x6 for 12GB

At normal speeds upto about 3.4 auto seems to cope but can be flaky

 

Probably explains why my geekbench scores are slightly lower than others and my i7 is the bottleneck for

my graphics card

[kdawg]

Thanks for the tip, when I overclock I can get to 4GHz but I have to run the RAM really slow eg x6 for 12GB

At normal speeds upto about 3.4 auto seems to cope but can be flaky

 

Probably explains why my geekbench scores are slightly lower than others and my i7 is the bottleneck for

my graphics card

Take a look at this thread. http://gskill.us/forum/showthread.php?t=1169 It's a G.Skill thread but it may apply to you as well. If you're using 12GB RAM you may want to up MCH Core and tRFC too. What is your Geekbench score BTW?

[LocusOfControl]

Take a look at this thread. http://gskill.us/forum/showthread.php?t=1169 It's a G.Skill thread but it may apply to you as well. If you're using 12GB RAM you may want to up MCH Core and tRFC too. What is your Geekbench score BTW?

 

 

At stock 8471 but I've had 11 to 12000 at 3.8GHz some time ago (32 version bit only on 64 bit platform)

 

I've done some tidying up and replaced my onboard NIC so I think my score went up a hundred or more

since last week

 

I find that with the opengl extensions view tests my score goes up depending on cpu speed which to me sounds

like the cpu is slower than the gpu?

[Josvdp]

Thanks LocusOfControl.

 

I'm running several VMware 3.0.1 images successfully without panic.

The KP looks like what I get with an unstable over clock, does any other high CPU activity application cause a KP?

Run `top -ocpu' in Terminal.

Ok, I got another KP. It was almost exactly the same and it was, again, when I booted VMware Fusion 3. See attached:

 

 

I still don't know how to interpret these KP's, even though I've read several articles about them. I just don't know what all the funny codes (HEX?) mean.

 

Anyway, developer.Apple.com says this about my type of KP (General protection):

General protection faults, caused by any of a number of conditions, including transferring execution to a non-executable code segment or writing to either a code segment or read-only data segment.

 

I'm going to suspend/wake Windows 7 VMware a couple of times to see if I can recreate the KP. To make things clear: I run an OC, without any voltage mods. My geekbench score for this setup was 9700 yesterday. I get KP's when I start VMware (when I resume a suspended Windows 7) and in the beginning, I used to have 2 or 3 after wake up. Didn't log those though so can't say anything about those.

 

Update

I've suspended/woken Windows 7 in VMware about 4 times now and this seems to be going perfectly smooth! The CPU tops at about 40% when I look at top -ocpu, but no KP's.

 

Update 2

I've also done sleep, then start VMware and wake Windows 7, no problems. I have even managed to successfully sleep/wake OSX while running a (live) Windows 7 in VMware, something I didn't really expect to go smoothly. That didn't even used to go smooth on my MBP.

 

Update 3

I ran some prime tests (very shortly though). I ran a torture Blend test (8 threads, so all cores) and CPU temps seem to go pretty high (I've seen 100 degrees celcius in iStat with about 30 in the case) but no KP's. I stopped because I thought the temperature was just too high to continue. The temperature is about 47 idle. Funny though, top -ocpu reported %CPU loads of 800! I'm not sure if that's a bug or something, but it sure was funny to see it using 4 cores hyperthreading.

[d00d]

Ok, I got another KP. It was almost exactly the same and it was, again, when I booted VMware Fusion 3. See attached:

 

I still don't know how to interpret these KP's, even though I've read several articles about them. I just don't know what all the funny codes (HEX?) mean.

 

Anyway, developer.Apple.com says this about my type of KP (General protection):

 

I'm going to suspend/wake Windows 7 VMware a couple of times to see if I can recreate the KP. To make things clear: I run an OC, without any voltage mods. My geekbench score for this setup was 9700 yesterday. I get KP's when I start VMware (when I resume a suspended Windows 7) and in the beginning, I used to have 2 or 3 after wake up. Didn't log those though so can't say anything about those.

 

Update

I've suspended/woken Windows 7 in VMware about 4 times now and this seems to be going perfectly smooth! The CPU tops at about 40% when I look at top -ocpu, but no KP's.

What it's not is an incompatible kext, because that would give you a KP each time.

If you don't get any KPs using VMware at standard clock, you've isolated the issue to your over clock voltages.

[Josvdp]

What it's not is an incompatible kext, because that would give you a KP each time.

If you don't get any KPs using VMware at standard clock, you've isolated the issue to your over clock voltages.

That's exactly what I was planning on doing and so, I'm running stock speed as we speak. Geekbench score is 7763, kind of a disappointment, but hee, you have to start somewhere. I'm sure I'll manage an over clock in the future. For now, I just want to know if it's the native PM (since this is the topic for it ) or if it was actually my OC.

 

I highly doubt it was my OC, since it only occurred at wake-up of Windows 7 in VMware. Well, that's not entirely true, because an hour ago, I experienced a KP while I was doing nothing. I was actually on the phone and OSX was just idle with Adium, Safari and some other things running (including VMware I think).

 

 

This one seems to be different and includes some kexts that were involved.

 

Is this more worrying?

 

Remember, this KP happened BEFORE I took the OC OFF.

[d00d]

That's exactly what I was planning on doing and so, I'm running stock speed as we speak. Geekbench score is 7763, kind of a disappointment, but hee, you have to start somewhere. I'm sure I'll manage an over clock in the future. For now, I just want to know if it's the native PM (since this is the topic for it ) or if it was actually my OC.

 

I highly doubt it was my OC, since it only occurred at wake-up of Windows 7 in VMware. Well, that's not entirely true, because an hour ago, I experienced a KP while I was doing nothing. I was actually on the phone and OSX was just idle with Adium, Safari and some other things running (including VMware I think).

 

This one seems to be different and includes some kexts that were involved.

 

Is this more worrying?

 

Remember, this KP happened BEFORE I took the OC OFF.

Why would native PM cause KPs?

That is what Apple hardware uses successfully, as well as Gigabyte, ASUS, etc. hardware using guides such as this one.

I don't understand your troubleshooting methodology.

You doubt the KPs are a result of incorrect voltages on your over clock, but you don't mention making any voltage adjustments.

I listed a Gigabyte over clocking forum in post 1, you will be able to see what other people use for voltages there.

[Josvdp]

Why would native PM cause KPs?

That is what Apple hardware uses successfully, as well as Gigabyte, ASUS, etc. hardware using guides such as this one.

I don't understand your troubleshooting methodology.

You doubt the KPs are a result of incorrect voltages on your over clock, but you don't mention making any voltage adjustments, and haven't mentioned testing at standard clock.

I listed a Gigabyte over clocking forum in post 1, you will be able to see what other people use for voltages there.

I'm sorry that I annoyed you (or at least confused you). Yes, I understand what native PM is, but my words weren't chosen careful enough. I meant that the KP's might have been caused by me, trying to obtain native PM and not by the native PM itself. Because it should actually cause less KP's.

 

And, yes, my troubleshooting methodology is like an animal on the loose, because I just don't know where to go/what to do. Although, the things you are mentioning (changing Vcore or the OC itself) I had already in the back of my mind. As we speak, I am testing the system without OC so we'll see what happens from now on.

 

Thanks by the way for the Gigabyte forum, I did take a look around on forums for overclocking my combination but that was only on websites in my language. The Gigabyte forum looks promising!

[aikidoka25]

5. For CPU0 through CPU7, make the following change to pass the CStates to OS X.

This is only needed when clocked over a certain point (148x20 or 2.96 GHz for a i7 920 or Xeon W3520 CPU), as it seems that the Gigabyte BIOS doesn't make the CStates available to the OS above that, even with all energy saving options enabled in the BIOS's Advanced CPU Features section.

 

EDIT:

The kernel log changed after I modified the BIOS setting and enabled C3, also iStat temp seems to match previous setup.

 

 

d00d, to confirm with you, if there is no OC (running at native speed 2.67GHz) I don't have to modify the item 5 above, aren't I?

Also, I got compile error when trying to add that section in my DSDT, copy paste from forum and from your attachment yield the same error.

 

One thing I noticed, after all the modifications (everything seems to be running fine) iStat reported a higher CPU Temp (about 10C higher)

Perhaps it doesn't measure the correct ones? Any good utility to measure the temperature? (

I tried i-mark-i before, but it is in Russian.

 

Also, my latest kernel.log showed a line like "WARNING: ACPI_SMC_CtrlLoop::initCPUCtrlLoop - turbo enabled but no turbo P-state found", is this expected?

Jan 14 21:16:23 localhost kernel[0]: systemShutdown false
Jan 14 21:16:23 localhost kernel[0]: AppleIntelCPUPowerManagement: Turbo Ratios 1112
Jan 14 21:16:23 localhost kernel[0]: AppleIntelCPUPowerManagement: initialization complete
Jan 14 21:16:31 localhost kernel[0]: Waiting for DSMOS...
Jan 14 21:16:35 GigaMacPro kernel[0]: Previous Shutdown Cause: 0
Jan 14 21:16:35 GigaMacPro kernel[0]: identified as RTL8168D/8111Didentified as RTL8168D/8111D
Jan 14 21:16:35 GigaMacPro kernel[0]: FakeSMC: key info not found MSDS, length - 6
Jan 14 21:16:37 GigaMacPro kernel[0]: DSMOS has arrived
Jan 14 21:16:37 GigaMacPro kernel[0]: com_chucko_RealtekR1000: Ethernet address 00:24:1d:cd:bd:72
Jan 14 21:16:37 GigaMacPro kernel[0]: com_chucko_RealtekR1000: Ethernet address 00:24:1d:cd:bd:52
Jan 14 21:16:37 GigaMacPro kernel[0]: ** Device in slot: SLOT-1 **
Jan 14 21:16:37 GigaMacPro kernel[0]: WARNING: ACPI_SMC_CtrlLoop::initCPUCtrlLoop - turbo enabled but no turbo P-state found
Jan 14 21:16:37: --- last message repeated 7 times ---
Jan 14 21:16:37 GigaMacPro kernel[0]: FakeSMC: key not found BEMB, length - 1
Jan 14 21:16:37 GigaMacPro kernel[0]: AppleTyMCEDriver::start coreVIDPID = 0xffffffff Number of packages = 1 Number of cpus = 8 memory monitor trough MCA
Jan 14 21:16:37 GigaMacPro kernel[0]: NTFS driver 3.1 [Flags: R/W].

 

 

I have these kexts in /E/E (following CruiSAr hints)

drwxr-xr-x@ 3 root wheel 102 14 Jan 19:26 EvOreboot.kext

drwxr-xr-x@ 3 root wheel 102 14 Jan 19:26 IOAHCIBlockStorageInjector.kext

drwxr-xr-x@ 3 root wheel 102 14 Jan 19:26 PlatformUUID.kext

drwxr-xr-x@ 3 root wheel 102 14 Jan 19:26 fakesmc.kext

 

Also in /S/L/E

drwxr-xr-x 3 root wheel 102 17 Dec 19:57 RealtekR1000.kext

[d00d]

I'm sorry that I annoyed you (or at least confused you). Yes, I understand what native PM is, but my words weren't chosen careful enough. I meant that the KP's might have been caused by me, trying to obtain native PM and not by the native PM itself. Because it should actually cause less KP's.

 

And, yes, my troubleshooting methodology is like an animal on the loose, because I just don't know where to go/what to do. Although, the things you are mentioning (changing Vcore or the OC itself) I had already in the back of my mind. As we speak, I am testing the system without OC so we'll see what happens from now on.

 

Thanks by the way for the Gigabyte forum, I did take a look around on forums for overclocking my combination but that was only on websites in my language. The Gigabyte forum looks promising!

No problem, it took me several months to get a stable high over clock.

One KP is too many, a properly configured machine should very rarely or never KP.

 

EDIT:

The kernel log changed after I modified the BIOS setting and enabled C3, also iStat temp seems to match previous setup.

 

d00d, to confirm with you, if there is no OC (running at native speed 2.67GHz) I don't have to modify the item 5 above, aren't I?

Also, I got compile error when trying to add that section in my DSDT, copy paste from forum and from your attachment yield the same error.

 

One thing I noticed, after all the modifications (everything seems to be running fine) iStat reported a higher CPU Temp (about 10C higher)

Perhaps it doesn't measure the correct ones? Any good utility to measure the temperature? (

I tried i-mark-i before, but it is in Russian.

 

Also, my latest kernel.log showed a line like "WARNING: ACPI_SMC_CtrlLoop::initCPUCtrlLoop - turbo enabled but no turbo P-state found", is this expected?

 

I have these kexts in /E/E (following CruiSAr hints)

drwxr-xr-x@ 3 root wheel 102 14 Jan 19:26 EvOreboot.kext

drwxr-xr-x@ 3 root wheel 102 14 Jan 19:26 IOAHCIBlockStorageInjector.kext

drwxr-xr-x@ 3 root wheel 102 14 Jan 19:26 PlatformUUID.kext

drwxr-xr-x@ 3 root wheel 102 14 Jan 19:26 fakesmc.kext

 

Also in /S/L/E

drwxr-xr-x 3 root wheel 102 17 Dec 19:57 RealtekR1000.kext

I use Marcel Bresink's Temperature Monitor.

What's the compile error tell you?

It will list the line number where the error occurs, you can use vi to edit the dsdt.dsl, and in vi hit the esc key and type #G to go to the line where you made the mistake so you can fix it.

DSDTSE has a line numbering guide as well.

There are three misconfigurations I can think of that would give you `turbo enabled but no turbo P-state found' at standard clock;

1. turbo enabled in BIOS, PSS not in DSDT, and DropSSDT=yes in com.apple.Boot.plist (may give `_PSS evaluation failed' instead)

2. turbo enabled in BIOS, EIST not enabled in BIOS, PSS not in DSDT, and DropSSDT=no (default) in com.apple.Boot.plist

3. turbo enabled in BIOS, incorrect PSS in DSDT, and DropSSDT=yes in com.apple.Boot.plist

[LocusOfControl]

No problem, it took me several months to get a stable high over clock.

One KP is too many, a properly configured machine should very rarely or never KP.

 

I use Marcel Bresink's Temperature Monitor.

What's the compile error tell you?

It will list the line number where the error occurs, you can use vi to edit the dsdt.dsl, and in vi hit the esc key and type #G to go to the line where you made the mistake so you can fix it.

DSDTSE has a line numbering guide as well.

There are three misconfigurations I can think of that would give you `turbo enabled but no turbo P-state found' at standard clock;

1. turbo enabled in BIOS, PSS not in DSDT, and DropSSDT=yes in com.apple.Boot.plist (may give `_PSS evaluation failed' instead)

2. turbo enabled in BIOS, EIST not enabled in BIOS, PSS not in DSDT, and DropSSDT=no (default) in com.apple.Boot.plist

3. turbo enabled in BIOS, incorrect PSS in DSDT, and DropSSDT=yes in com.apple.Boot.plist

 

 

Hi d00d

 

Could you just confirm something. If I follow your DSDT edits as per page 1 then I should activate my C States and

I should find CPUPLimit = 0x0

 

IOService:/AppleACPIPlatformExpert/CPU0@0/AppleACPICPU/ACPI_SMC_PlatformPlugin you will see CPUPLimit with a value of 0x0, a different value if it's not activated, or not there at all if not enabled.

 

This doesn't require any additional tinkering eg demong1's MacPro4_1.plist

 

I don't get any errors, all the other info is provided in DSDT but this CPUPLimit attribute is not shown.

Is there any physical way to measure or test CStates as opposed to PStates?

[d00d]

Hi d00d

 

Could you just confirm something. If I follow your DSDT edits as per page 1 then I should activate my C States and

I should find CPUPLimit = 0x0

 

IOService:/AppleACPIPlatformExpert/CPU0@0/AppleACPICPU/ACPI_SMC_PlatformPlugin you will see CPUPLimit with a value of 0x0, a different value if it's not activated, or not there at all if not enabled.

 

This doesn't require any additional tinkering eg demong1's MacPro4_1.plist

 

I don't get any errors, all the other info is provided in DSDT but this CPUPLimit attribute is not shown.

Is there any physical way to measure or test CStates as opposed to PStates?

Please reread post 263 carefully.

CSTinfo is related to CStates, see ACPIspec40.pdf for details of CST.

CPUPLimit is related to speed step (x19 and lower PStates when using x20 base), which is enabled by demong1's MacPro4_1.plist (see warning at bottom of post 1), or possibly by specifying SMproductname=MacPro3,1 in smbios.plist.

[LocusOfControl]

Please reread post 263 carefully.

CSTinfo is related to CStates, see ACPIspec40.pdf for details of CST.

CPUPLimit is related to speed step (x19 and lower PStates when using x20 base), which is enabled by demong1's MacPro4_1.plist (see warning at bottom of post 1), or possibly by specifying SMproductname=MacPro3,1 in smbios.plist.

 

That is as I understood things, I thought the wording

 

value of 0x0, a different value if it's not activated, or not there at all if not enabled

 

was ambiguous in that it wasn't crystal clear what the "it's" referred to, either C-States in general or lower speed steps

which from your opening posts on page one I infer are not native apple implementation. Therefore if I wish to have

a fully vanilla I don't need concern myself with this . It's not a criticism since the generic gigabyte thread is also

ambiguous implying that if you do not see 00 for CPUPLimit then C-States are not working

 

Seems clear now though, thanks

[d00d]

That is as I understood things, I thought the wording

 

value of 0x0, a different value if it's not activated, or not there at all if not enabled

 

was ambiguous in that it wasn't crystal clear what the "it's" referred to, either C-States in general or lower speed steps

which from your opening posts on page one I infer are not native apple implementation. Therefore if I wish to have

a fully vanilla I don't need concern myself with this . It's not a criticism since the generic gigabyte thread is also

ambiguous implying that if you do not see 00 for CPUPLimit then C-States are not working

 

Seems clear now though, thanks

CStates are native PM for the MacPro4,1.

The x20 and higher PStates are native PM for the MacPro4,1.

The x19 and lower PStates (speed step) are not native PM for the MacPro4,1.

 

Speed step is enabled by having PStates in the first place (EIST enabled in BIOS), and by using demong1's modified MacPro4_1.plist (see warning at bottom of post 1).

Specifying SMproductname=MacPro3,1 in smbios.plist, instead of using the modified MacPro4_1.plist, may or may not currently work.

I experimented with it in 10.6.1 where it worked.

Even if it currently works I wouldn't suggest using MacPro3,1, because that's a different processor family, and there may be undesired side effects.

For some reason Apple doesn't enable speed step in their MacPro4_1.plist, even though the hardware supports it.

When I get some time I'm going to experiment with SMproductname=iMac11,1, which is the i7 and i5 CPU version.

According to Apple's Advanced power management section of http://www.apple.com/imac/environment.html, they seem to have enabled speed step.

Seeing that iMac11_1.plist contains StepDataDict would tend to confirm this.

Enabling speed step gives no benefit of energy savings and lower idle CPU temperatures unless one uses the new DVID feature of the BIOS, but it seems that doing so intermittently breaks resume from S3 sleep.

[Josvdp]

Hi d00d! I totally agree with you that KP's should be a rare phenomenon. In the 3 years that I have had my Macbook Pro, it KP'ed only about twice. So everytime this OSX86 system KP's, there's a small part of my heart that dies .

 

Anyway, as you advised, I took off my OC but this morning when I woke the system from sleep, I got a KP right away (it's attached at the end of the post). This time, it stated something involving iStatMenus. In the beginning, the KP's seemed to be much alike, but this one and the one before are quite different. Even though they are from the same type (13, general protection) I'm still not sure what's causing this.

 

Would you recommend a full reinstall maybe? That would take up loads of precious time, especially since I have everything set and done on my user profile. But if that is what it takes to get to a stable system, then I will do that.

 

[d00d]

Hi d00d! I totally agree with you that KP's should be a rare phenomenon. In the 3 years that I have had my Macbook Pro, it KP'ed only about twice. So everytime this OSX86 system KP's, there's a small part of my heart that dies .

 

Anyway, as you advised, I took off my OC but this morning when I woke the system from sleep, I got a KP right away (it's attached at the end of the post). This time, it stated something involving iStatMenus. In the beginning, the KP's seemed to be much alike, but this one and the one before are quite different. Even though they are from the same type (13, general protection) I'm still not sure what's causing this.

 

Would you recommend a full reinstall maybe? That would take up loads of precious time, especially since I have everything set and done on my user profile. But if that is what it takes to get to a stable system, then I will do that.

Did you use the revised CPU instructions to create your DSDT, or are you using the attached F9m DSDT?

There was a problem with KPs after wake with the pre F9m CPU instructions and DSDT, but usually only when booting in 32 bit.

[Josvdp]

Did you use the revised CPU instructions to create your DSDT, or are you using the attached F9m DSDT?

There was a problem with KPs after wake with the pre F9m CPU instructions and DSDT, but usually only when booting in 32 bit.

I'm using the attached F9m DSDT with an added modification for step 16 (shutdown and restart, if I'm right). But when I did that, I checked if all the steps in this tutorial were correctly put in. I didn't change anything when it comes to the CPU instructions, so that is very likely to be the cause? We're talking about step 5 of your guide, right? Are the steps in your start post revised or are they in a different post?

 

I didn't manage to properly use 32-bit, I think it was because of KP's after wake.

 

I could maybe start with a fresh DSDT and then redo the steps in your tutorial. But the big question for me is how to get a fresh and untouched DSDT ?

 

I'm going to check now if the CPU instructions (Step 5 (CStates) are put in correctly.

 

update

It looks like they are. Just to be clear, I attached my DSDT and I have a i7 920. The CPU CStates are there, although in DSDTSE, the HEX codes look like this: 0x0A65 instead of 0x00000A65. I don't think that should be much of a problem.

 

I must say that I took the attached 9Fm 920 DSDT and then (with DSDT) edited it a few time in order to get step 16 and step 17 working. These steps weren't done yet in the attached DSDT and I wanted shut down/restart to work properly without extra kexts.

 

DSDT.aml.zip

[aikidoka25]

...

I could maybe start with a fresh DSDT and then redo the steps in your tutorial. But the big question for me is how to get a fresh and untouched DSDT ?

 

...

 

if you are able to boot into Ubuntu Live CD (thanks to LocusOfControl who suggested me there is a linux way) , execute this

 

sudo cat /proc/acpi/dsdt > dsdt.aml

 

then you can decompile the aml file using DSDTSE

[Josvdp]

if you are able to boot into Ubuntu Live CD (thanks to LocusOfControl who suggested me there is a linux way) , execute this

 

sudo cat /proc/acpi/dsdt > dsdt.aml

 

then you can decompile the aml file using DSDTSE

I already have a (second) working SL running on a different disk (but no sleep working, and no native PM) so I guess I could use that string in Terminal too?

[LocusOfControl]

I already have a (second) working SL running on a different disk (but no sleep working, and no native PM) so I guess I could use that string in Terminal too?

 

 

No, that string is for linux, not OS X, but aikidoka25 posted a solution ie bootable linux cd

[aikidoka25]

...

I use Marcel Bresink's Temperature Monitor.

What's the compile error tell you?

It will list the line number where the error occurs, you can use vi to edit the dsdt.dsl, and in vi hit the esc key and type #G to go to the line where you made the mistake so you can fix it.

DSDTSE has a line numbering guide as well.

There are three misconfigurations I can think of that would give you `turbo enabled but no turbo P-state found' at standard clock;

1. turbo enabled in BIOS, PSS not in DSDT, and DropSSDT=yes in com.apple.Boot.plist (may give `_PSS evaluation failed' instead)

2. turbo enabled in BIOS, EIST not enabled in BIOS, PSS not in DSDT, and DropSSDT=no (default) in com.apple.Boot.plist

3. turbo enabled in BIOS, incorrect PSS in DSDT, and DropSSDT=yes in com.apple.Boot.plist

 

d00d,

thanks for the tips, i managed to solve the `turbo enabled but no turbo P-state found' warning message.

 

now i have a lot of 'FakeSMC: key not found' message in kernel.log

is this something i should worried?

Jan 15 18:45:26 GigaMacPro kernel[0]: FakeSMC: key not found BEMB, length - 1
Jan 15 18:50:01 GigaMacPro kernel[0]: FakeSMC: key info not found TB2T, length - 6
Jan 15 18:50:01 GigaMacPro kernel[0]: FakeSMC: key info not found TB3T, length - 6
Jan 15 18:50:01 GigaMacPro kernel[0]: FakeSMC: key info not found TN0P, length - 6
Jan 15 18:50:01 GigaMacPro kernel[0]: FakeSMC: key info not found TN1P, length - 6
...

 

i haven't tried this, but from http://www.insanelymac.com/forum/index.php?showtopic=186490 , apparently we could turn off the debug to get rid these messages.

 

fyi, i have to use vi to paste the processor part of dsdt, no more error when compiling.

for strange reason pasting that part using DSDTSE creates strange error and the line pointed by the error message doesn't make sense at all.

 

about Temperature Monitor, the CPU Temp Diodes show incredibly high more than 10000 degree, SMC CPU Diodes too, in the range of 9000 degree.

however the CPU Cores seem reasonable, about 39 degree.

 

is this normal or there is something that i missed?

 

thanks again d00d

 

ciao

[d00d]

d00d,

thanks for the tips, i managed to solve the `turbo enabled but no turbo P-state found' warning message.

 

now i have a lot of 'FakeSMC: key not found' message in kernel.log

is this something i should worried?

Jan 15 18:45:26 GigaMacPro kernel[0]: FakeSMC: key not found BEMB, length - 1
Jan 15 18:50:01 GigaMacPro kernel[0]: FakeSMC: key info not found TB2T, length - 6
Jan 15 18:50:01 GigaMacPro kernel[0]: FakeSMC: key info not found TB3T, length - 6
Jan 15 18:50:01 GigaMacPro kernel[0]: FakeSMC: key info not found TN0P, length - 6
Jan 15 18:50:01 GigaMacPro kernel[0]: FakeSMC: key info not found TN1P, length - 6
...

 

i haven't tried this, but from http://www.insanelymac.com/forum/index.php?showtopic=186490 , apparently we could turn off the debug to get rid these messages.

 

fyi, i have to use vi to paste the processor part of dsdt, no more error when compiling.

for strange reason pasting that part using DSDTSE creates strange error and the line pointed by the error message doesn't make sense at all.

 

about Temperature Monitor, the CPU Temp Diodes show incredibly high more than 10000 degree, SMC CPU Diodes too, in the range of 9000 degree.

however the CPU Cores seem reasonable, about 39 degree.

 

is this normal or there is something that i missed?

 

thanks again d00d

 

ciao

You can add dummy keys for each one, or just turn off debug to not see those cosmetic messages.

To show the correct CPU Temperature Diode values in Temperature Monitor, I use oldnapalm's modified fakesmc 2 source (http://www.insanelymac.com/forum/index.php?showtopic=192517), changed it to write the keys big-endian, and compiled it.

Look for the following line in fakesmc.cpp;

MySMCKey->data[0] = Tjmax-GlobalThermal;

...and change it to;

MySMCKey->data[1] = Tjmax-GlobalThermal;

[ryansimms]

For step #16, is there a benefit to using that DSDT patch if you don't plan on using the modified bootloader, since you'll need a kext for restart functionality anyway?

 

Also, for #5 your posted code and the attached dsdt file (for a 920) don't seem to match up. Is one of them incorrect?

 

Ryan!

[Josvdp]

For step #16, is there a benefit to using that DSDT patch if you don't plan on using the modified bootloader, since you'll need a kext for restart functionality anyway?

 

Also, for #5 your posted code and the attached dsdt file (for a 920) don't seem to match up. Is one of them incorrect?

 

Ryan!

Mmmh, maybe that's why I'm having those KP's?

[Josvdp]

Hehe, is this is rather funny, look at this KP:

 

 

But, it's not that funny, because KP's really frustrate me. Especially since they seem to happen more often now. I got the KP while in Logitech Control centre, setting the scroll acceleration to "none" gave a KP. This time, it's not of the type "13 general protection" but "14 page fault" which often has to do with memory (if I'm right). I have no overclock at all though!

 

d00d, I'm not sure if you've seen my last post, but I'm really lost in the woods now. I'm thinking of completely rebuilding my DSDT. In order to do that I have to get a fresh DSDT first, because I'm not sure if your attached (920) DSDT is OK, is it?