Jump to content

IvyBridge XCPM pstate table mismatch error (was: IvyBridge SSDT graphical glitches)

Hackmodford

By Hackmodford,
in OSx86 10.9 (Mavericks)

 Share
59 posts in this topic

Recommended Posts

Hackmodford
Hackmodford
Posted
Posted

I've managed to get speed stepping working on my machine by generating a ssdt and changing my smbios.

 

However after doing this flash player give me weird graphical glitches.

 

If I revert the smbios.plist back to mac pro. The glitches go away, and the speed stepping stops working.

 

My question is, what should my smbios.plist be?

 

I've tried Macmini6,2 and MacBookPro9,1

 

Any help would be great :)

 


Here's an example of the glitches.

 

post-1106388-0-88527400-1390086767_thumb.png

 

If I remove my graphics card and use the HD4000 I do not have any problems.

Link to comment
Share on other sites
Allan
Allan
Posted
Posted

u use Chimera bootloader. we do not give support for tonymac tools

read: http://www.insanelymac.com/forum/topic/279450-why-insanelymac-does-not-support-tonymacx86/

 

but you have salvation :lol:

 

please follow these instructions.

http://www.insanelymac.com/forum/topic/291614-intel-hd4000-and-haswell-inject-aaplig-platform-id/ 

Link to comment
Share on other sites
Hackmodford
Hackmodford
Posted
  • Author
Posted

LOL I understand.

I'm not that dedicated to tonymac, and if I switch the boot loader does that make you guys happy :)

But I'm not clear on what the instructions will actually do? I don't need the HD4000 graphics activated.

 

This problem seems to be related to Safari. At first I thought it was from the recent Flash v12 update, because when I used Google Chrome I didn't have the issue on youtube. I browsed to apples mac pro page in safari and got the same graphical glitching and locked up the computer. Tried the same page in Chrome and there was no issue.

 

Next I thought, maybe Safari is corrupted, so I downloaded the 10.9.1 update and reinstalled it. That did not fix the issue either.

 

So at the moment I'm using the Macmini6,2 smbios and have power states, but weird graphic glitches.


Update: Someone told me that the iMac smbios will give you less pstates just like a real iMac. So if I use the iMac smbios I get 16 and 39. If that is how the real iMac would work I'm fine with it. Is this true?

 

With the iMac smbios I do not get graphic glitches.

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

No, I'm pretty sure it's tied to the model identifier you were using, the graphics glitches have something to do with the MacMini not having discrete graphics. It makes sense that everything returns to normal when you use only the HD4000.

 

I have 6 p-states on an i5-3570K (turbo @ 4100MHz) with this iMac13,1 smbios.plist and latest Chameleon. PMPatched Asus Z77 board.

MSRDumper PStatesReached: 16 25 29 34 37 41

Even though I'm getting these messages:

XCPM: P-state table mismatch (error:0x1a)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x1a
X86PlatformShim::start - Failed to send PStates
X86PlatformShim::start - Failed to send stepper

Using -xcpm kernel flag and SSDT.aml generated with ssdtPRGen.sh.

Link to comment
Share on other sites
Hackmodford
Hackmodford
Posted
  • Author
Posted

I just used the iMac13,1 smbios you provided and the kernel flag. I know  get 6 PStates.

MSRDumper PStatesReached: 16 25 30 35 37 39

I have a feeling this isn't related to the smbios but that kernel flag. meaning I'm curious if I used the iMac13,2 smbios if there'd be a difference?

 

I am getting similar messages also.

XCPM: registered
IOPPF: XCPM mode
XCPM: P-state table mismatch (error:0x12)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x12
Link to comment
Share on other sites
Hackmodford
Hackmodford
Posted
  • Author
Posted

Now that I understand more about XCPM I'm not 100% sure you'd need a specific SMBIOS to get it working.

 

I also learned how to fix the p-state table mismatch. Here's the github issue I used to solve it. https://github.com/Piker-Alpha/RevoBoot/issues/9#issuecomment-32725894

 

So all in all, I think I can say this issue has been resolved. Thank guys  :thumbsup_anim:

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

S3 sleep works though, at least it does here. I've never used auto sleep on any of my hacks.

 

But good for you, and you're a smarter man than I am...I can't figure this out..

 

See the comments section here:

http://pikeralpha.wordpress.com/2013/12/17/os-x-mavericks-10-9-1-update/comment-page-1/

 

EDIT

 

Look at me, I'm famous now...my name is in ssdtPRGen.sh :D

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

I passed i5-3570K 4100 77 to v8.7. This is the unmodified output: ssdt.aml.zip

 

There's a line in there that says "Change this to 0 when your CPU isn't stuck in Low Frequency Mode!"

I guess I should change that to 0 then? I've never touched it.

 

/Edit - NM, Pike changed the way that setting works (or the way it's worded) in v8.8 of the script:

 

 

# Change this to 1 when your CPU is stuck in Low Frequency Mode!
#
# Note: Injects extra Turbo P-State at he top with max-Turbo frequency + 1 MHz.
#
let gIvyWorkAround=0
Link to comment
Share on other sites
Hackmodford
Hackmodford
Posted
  • Author
Posted

Okay here it is. I removed the top pstate, and removed all the bottom ones until they got to 16.

 

Then I changed APLF to Zero because I removed the extra low end pstates so Zero is the first one now. (make sense?)

I then changed APSN from 0x08 (8) to 0x07 (7) because I removed the top Turbo State so now you only have 7.

Then I changed the APSS number to reflect the new, lower total of pstates.

 

I believe this will get rid of the warning for you.

 

(I wasn't sure how to attach files here, so here's a dropbox link.) https://dl.dropboxusercontent.com/u/6851931/Gringo%27s%20ssdt.aml.zip

  • Like 1
Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

Thanks! It sounds like you did the same thing that Pike told me to do, except it's probably done correctly now lol

 

Use the full editor to attach files.

 

Rebooting...aand it's a no-go.....the same 0x11 error messages as I got after following Pike's directions.

 

 

XCPM: P-state table mismatch (error:0x11)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11
X86PlatformShim::start - Failed to send PStates
X86PlatformShim::start - Failed to send stepper
Link to comment
Share on other sites
Hackmodford
Hackmodford
Posted
  • Author
Posted

Bummer, I'm not sure then.

Did I explain it we'll enough for you to debug/diy further?

Another thing is to use an online decimal to hexadecimal converter to figure out the numbers.

 

I'm going to bed now, hope it all works out.

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

No problem, thanks for trying! I'll keep at it.

 

From what I can understand you're saying the same thing that Pike told me on his blog. Seeing it worded differently helps a lot.

 

I like to use an old DSDT editor, DSDTSE, it has a dec/hex converter in the GUI.

OS X's calculator does it too, just type a number and change to programmer mode (command+3).

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

*high-fives Hackmodford*

 

We're gonna need an agent.. :lol:

 

I changed the topic title since we're discussing this now, hopefully others will see it and join in. I hope you don't mind.

 

ssdtPRGen.sh 8.8

IOPPF: XCPM mode

XCPM: P-state table mismatch (error:0x11)

X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11

X86PlatformShim::start - Failed to send PStates

X86PlatformShim::start - Failed to send stepper

Still, the six p-states are there: Jan 20 13:37:03 Gringos-iMac kernel[0]: AICPUPMI: CPU P-States [ 16 25 29 34 37 41 ]

 

Generated with ./ssdtPRGen.sh i5-3570K 4100: ssdt.aml.zip

  • Like 1
Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

Right, 3400 is the default clock of the 3570K. Default turbo is 3800 (I think) but I upped it to 4100 in the BIOS, for all 4 cores.

But apparently, as I understand it, setting this in the BIOS doesn't matter anyway when using XCPM?

 

I used to have it at 4200 but that required overclocking and changing the base freq (I think it was at 104 point something). I saw Pike recommended leaving it at 100 (he said OS X uses it to calculate other functions) so I put it back. When I took it back to 100, the max turbo freq dropped down to 4100 by itself.

 

Do you think it would make any difference if I went back to the default settings? I haven't done that yet because, from what I understood, BIOS settings don't matter anymore when using XCPM.

 

0x15 now with the ssdt you posted:

IOPPF: XCPM mode
XCPM: P-state table mismatch (error:0x15)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x15
X86PlatformShim::start - Failed to send PStates
X86PlatformShim::start - Failed to send stepper

..oh you uploaded a new one.. hang on..this is the 3800 one:

 

XCPM: P-state table mismatch (error:0x13)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x13
X86PlatformShim::start - Failed to send PStates
X86PlatformShim::start - Failed to send stepper

 

I'll see what happens on default clock settings...reboot marathon lol

Link to comment
Share on other sites
Hackmodford
Hackmodford
Posted
  • Author
Posted

Well, if the new one doesn't work I"m not sure.

 

But I would mention to Pike that you got some kind of BIOS settings that aren't default for the processor. I don't know if it makes a difference or not. But first I would try to get it working with default settings.

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

BIOS reverted to default settings for CPU and RAM.

 

Your 3800 ssdt:

 

 

IOPPF: XCPM mode
XCPM: P-state table mismatch (error:0x11)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11
X86PlatformShim::start - Failed to send PStates
X86PlatformShim::start - Failed to send stepper

 

Weirdness.

Link to comment
Share on other sites
Pike R. Alpha
Pike R. Alpha
Posted
Posted

Let's try something new. So we have something like this:

        Name (APLF, Zero)
        Name (APSN, 0x07)
        Name (APSS, Package (0xNN)
        {
            /* High Frequency Modes (turbo) */
            Package (0x06) { 0x1004, 0x012CC8, 0x0A, 0x0A, 0x2900, 0x2900 }, * (see note below)
            Package (0x06) { 0x0FA0, 0x012CC8, 0x0A, 0x0A, 0x2800, 0x2800 },
            Package (0x06) { 0x0F3C, 0x012CC8, 0x0A, 0x0A, 0x2700, 0x2700 },
            Package (0x06) { 0x0ED8, 0x012CC8, 0x0A, 0x0A, 0x2600, 0x2600 },
            Package (0x06) { 0x0E74, 0x012CC8, 0x0A, 0x0A, 0x2500, 0x2500 },
            Package (0x06) { 0x0E10, 0x012CC8, 0x0A, 0x0A, 0x2400, 0x2400 },
            Package (0x06) { 0x0DAC, 0x012CC8, 0x0A, 0x0A, 0x2300, 0x2300 }, * (see note below)
            /* High Frequency Modes (non-turbo) */
            Package (0x06) { 0x0D48, 0x012CC8, 0x0A, 0x0A, 0x2200, 0x2200 },
            Package (0x06) { 0x0CE4, 0x0120A0, 0x0A, 0x0A, 0x2100, 0x2100 },
            Package (0x06) { 0x0C80, 0x0114B0, 0x0A, 0x0A, 0x2000, 0x2000 },
            Package (0x06) { 0x0C1C, 0x0108F8, 0x0A, 0x0A, 0x1F00, 0x1F00 },
            Package (0x06) { 0x0BB8, 0x00FD77, 0x0A, 0x0A, 0x1E00, 0x1E00 },
            Package (0x06) { 0x0B54, 0x00F22D, 0x0A, 0x0A, 0x1D00, 0x1D00 },
            Package (0x06) { 0x0AF0, 0x00E719, 0x0A, 0x0A, 0x1C00, 0x1C00 },
            Package (0x06) { 0x0A8C, 0x00DC3B, 0x0A, 0x0A, 0x1B00, 0x1B00 },
            Package (0x06) { 0x0A28, 0x00D192, 0x0A, 0x0A, 0x1A00, 0x1A00 },
            Package (0x06) { 0x09C4, 0x00C71F, 0x0A, 0x0A, 0x1900, 0x1900 },
            Package (0x06) { 0x0960, 0x00BCDF, 0x0A, 0x0A, 0x1800, 0x1800 },
            Package (0x06) { 0x08FC, 0x00B2D4, 0x0A, 0x0A, 0x1700, 0x1700 },
            Package (0x06) { 0x0898, 0x00A8FC, 0x0A, 0x0A, 0x1600, 0x1600 },
            Package (0x06) { 0x0834, 0x009F58, 0x0A, 0x0A, 0x1500, 0x1500 },
            Package (0x06) { 0x07D0, 0x0095E6, 0x0A, 0x0A, 0x1400, 0x1400 },
            Package (0x06) { 0x076C, 0x008CA7, 0x0A, 0x0A, 0x1300, 0x1300 },
            Package (0x06) { 0x0708, 0x008399, 0x0A, 0x0A, 0x1200, 0x1200 },
            Package (0x06) { 0x06A4, 0x007ABD, 0x0A, 0x0A, 0x1100, 0x1100 },
            /* Low Frequency Mode */
            Package (0x06) { 0x0640, 0x007212, 0x0A, 0x0A, 0x1000, 0x1000 },

Now remove a Turbo P-State until the error is gone. Make sure you lower the value of APSN by one too. One other thing. Do not remove the Turbo P-State with the asterisks. 

Link to comment
Share on other sites
Gringo Vermelho
Gringo Vermelho
Posted
Posted

Thanks Pike, I'll try that and let you know later. :thumbsup_anim: Right now I have to drive into town and run some errands before traffic goes crazy.

 

btw;

 

With default BIOS settings for CPU + RAM and running ssdtPRGen.sh with no additional parameters, this is the resulting ssdt: ssdt_pr.dsl.zip

 

...again causing XCPM messages with error code 0x11:

XCPM: P-state table mismatch (error:0x11)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11
X86PlatformShim::start - Failed to send PStates
X86PlatformShim::start - Failed to send stepper

But still, six P-states:

Jan 20 17:38:20 Gringos-iMac kernel[0]: AICPUPMI: CPU P-States [ 16 25 29 34 36 37 38 ]

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...