Open Hackmodford opened 10 years ago
Have you tried this change already?
-let gIvyWorkAround=3 +let gIvyWorkAround=1 or +let gIvyWorkAround=0
Also. You can now use debugMachKernel.sh to patch the mach_kernel and add 'ioppf=0xff msgbuf=262144' under 'Kernel Flags' in com.apple.Boot.plist to redirect debug output to system.log We may need this when the change doesn't work for you. In that case please provide (per e-mail) me your log file (with all identifiable/unrelated stuff removed) so that I can check what is going on.
gIvyWorkaround=1 gives me this.
2/8/14 6:58:34.000 PM kernel[0]: XCPM: registered
2/8/14 6:58:36.000 PM kernel[0]: IOPPF: XCPM mode
2/8/14 6:58:36.000 PM kernel[0]: XCPM: P-state table mismatch (error:0x13)
2/8/14 6:58:36.000 PM kernel[0]: X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x13
gIvyWorkaround=0 gives me:
2/8/14 7:02:51.000 PM kernel[0]: XCPM: registered
2/8/14 7:02:52.000 PM kernel[0]: IOPPF: XCPM mode
2/8/14 7:02:52.000 PM kernel[0]: XCPM: P-state table mismatch (error:0x11)
2/8/14 7:02:52.000 PM kernel[0]: X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11
I ran the debug kernel script. Can I add the "ioppf=0xff msgbuf=262144" via boot arguments in clover? What kind of personal info could the log have? What should I look for before giving it to you?
Also when I ran the script, I did not edit it. I simply typed
./debugMachKernel.sh
Interesting... it seems like after running the debug script xcpm works without errors. Time Machine seems to automatically backup also (which was my original problem).
For reference I'm using the ssdt generated with gIvyWorkaround=0
Should I undo the debug script in any way?
Is there some sort of cache that was cleared after a second reboot? I'm trying to understand whether if it was the debugMachKernel.sh that made a difference or maybe the second reboot...
No idea. Never used Clover. I would like to suggest to put them where they belong i.e. in /Library/Preferences/SystemC*/com.apple.Boot.plist
I thought that 'gIvyWorkaround=0' was working previously for you so I was thinking about checking: /usr/sbin/sysctl -n machdep.xcpm.mode to see if that is one (1) and set gIvyWorkaround=0 for people using XCPM.
And yes. All changes to the mach_kernel will trigger a kernelcache refresh. Speaking about debugMachKernel.sh - I better make a backup of the mach_kernel and add an argument (on/off) so that you restore the original mach_kernel.
You could set gIvyWorkaround=3 and restore the untouched mach_kernel to see what happens.
I restored the original mach_kernel via time machine. Then I ran Kext Utility because it was the only thing I know of that will rebuild the cache, and I'm not sure how to do it from the terminal.
Rebooted and the errors came back! Rebooted again just incase... still got errors. Rebooted and ignored caches and still got errors. Re-Ran script and rebooted. No errors!
All this while using the gIvyWorkaround=0 that was working before.
This time:
You can use: sudo touch /S/L/Extensions to trigger a rebuild of the kernelcache.
Hmm. Maybe we should use C3 (ret) instead of 90 (nop) as last byte/instruction. Done. New version now available. Please give it a go.
Computer doesn't boot now. I am attempting to restore mach_kernel via recovery partition terminal. Was the "mach_kernel_13B42" the backup the script makes?
Yes. The script checks the build version and use that in the filename. I'll check this myself after dinner. Need to go help my wife now. Later!
Okay after using v0.9 of the debug kernel the errors are back. So I'm assuming 0.7 was just hiding them somehow?
In any case I added the boot flags and did a search for xcpm and this is what I get now.
2/10/14 8:47:53.000 PM kernel[0]: Kernel boot args: '-xcpm -v slide=0 ioppf=0xff msgbuf=262144'
2/10/14 8:47:53.000 PM kernel[0]: XCPM: registered
2/10/14 8:47:53.000 PM kernel[0]: XCPM: registered
2/10/14 8:47:59.000 PM kernel[0]: IOPPF: XCPM mode**** [IOBluetoothHostControllerUSBTransport][SuspendDevice] -- Suspend -- suspendDeviceCallResult = 0x0000 (kIOReturnSuccess) -- 0x2800 ****
2/10/14 8:47:59.000 PM kernel[0]: IOPPF: XCPM mode
2/10/14 8:47:59.000 PM kernel[0]: ErP Timer is not specified! Defaulting to 0x3840XCPM: P-state table mismatch (error:0x11)
2/10/14 8:47:59.000 PM kernel[0]: XCPM: P-state table mismatch (error:0x11)
2/10/14 8:47:59.000 PM kernel[0]: X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11
2/10/14 8:47:59.000 PM kernel[0]: X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11
I'm not sure what type of "personal information" could be in the entire log. Can you give me any clues of what to filter out?
I have no idea what was going on with v0.7 I was also unable to duplicate it, but I know that the kernelcache is being rebuild after you run the script.
About the log file. E-mail me the output of:
cat /var/log/system.log | grep -e 'ACPI' -e 'X86PlatformPlugin' -e 'X86PlatformShim' -e 'CPUMaxNonTurboPState' -e 'Max efficient' -e 'XCPM' -e 'IOPPF' -e 'AGPM' -e 'IOPlatformPluginLegacy'
That filters out everything what we are interested in.
Hey this is interesting: "ErP Timer is not specified!"
I don't have this error. And it shouldn't be there because 'ErPDelay' is there in the Mac-[board-id].plist so what board-id and Mac model identifier are you using? Maybe the plist isn't getting loaded?
You should se something like this: X86PlatformPlugin::startDelayedPlatformDatabaseRead - Mac-F60DEB81FF30ACF6.plist
I sent you a PM via InsanelyMac, I couldn't find your email :P
I just switched the smbios back to the iMac. If I reboot without the extra kernel flags you mentioned I get no errors now. If I add the debug kernel flags you mentioned I get errors.
My e-mail address can be found in all scripts and other source code that I published. Please use that because it is one long line of text. No formatting. Unreadable.
You where using MacPro3,1? Oops. That should not be used for XCPM! And what iMac model are you using now? Is that a model that is supported by XCPM or not? Check your board-id against the plists in: /S/L/Extensions/IOPlatformPluginFamily.kext/C/P/X86PlatformPlugin.kext/C/R/
K, couple of questions. What determines if XCPM can be used or not? I see a list of plist files with what looks like serial numbers but I don't know how to determine which profiles go with which.
I've been using iMac13,2 in all of our other tests...
Update: This seems like a good reference. http://www.tonymacx86.com/wiki/index.php/Smbios.plist
I'm still not sure what determines if I can use xcpm with the board-id
Update 2: If the board is listed in that folder, is that what makes it compatible?
Update 3: Using the unmodified kernel and ssdt generated with gIvyWorkAround = 0 with iMac 13,2 smbios gives me 0 errors.
So I guess the key was I have to use the right smbios.
Should we add the list of supported smbios in the readme?
Update 4: I just turned off xcpm and re-generated the ssdt.aml file. Then rebooted with -xcpm and the imac13,2 smbios. I get no errors with this configuration either.
Curiouser and curiouser...
Key factors for XCPM are: The processor model i.e. Ivy Bridge or Haswell (uses Frequency Vectors) SMBIOS data with supported model and board-id (see plist files in Resources) boot argument (like xcpm for Ivy Bridge setup) gIvyWorkAround setting in ssdtPRGen.sh
About this: "I just turned off xcpm..." How did you do that?
K, I have the right processor ;) Board id is set to : Mac-FC02E91DDD3FA6A4 gIvyWorkAround was generated with xcpm on.\
"About this: "I just turned off xcpm..." How did you do that?"
I just removed the boot argument to stop xcpm ;)
Grrr.... this is so confusing.
I had a problem with the clover botloader and had to rollback to an older version. After doing that the errors came back!
I'm using the imac13,2 smbios I generated the ssdt with version 10.5 I changed a setting in clover to remove the system type error (it said it was 1 but should be 2)
ssdtPRGen.sh v0.9 Copyright (c) 2011-2012 by † RevoGirl
v6.6 Copyright (c) 2013 by † Jeroen
v10.5 Copyright (c) 2013-2014 by Pike R. Alpha
-----------------------------------------------------------------
System information: Mac OS X 10.9.1 (13B42)
Brandstring 'Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz'
Scope (_PR_) {26 bytes} with Processor declarations found in the DSDT (ACPI 1.0 compliant)
Generating ssdt.dsl for a iMac13,2 [Mac-FC02E91DDD3FA6A4]
Ivy Bridge Core i7-3770K processor [0x306A9] setup [0x0704]
With a maximum TDP of 77 Watt, as specified by Intel
Number logical CPU's: 8 (Core Frequency: 3500 MHz)
Number of Turbo States: 4 (3600-3900 MHz)
Number of P-States: 24 (1600-3900 MHz)
XCPM detected (Ivy Bridge workarounds disabled)
Injected C-States for CPU0 (C1,C3,C6)
Injected C-States for CPU1 (C1,C2,C3)
No errors when generating it. Now I get these messages in the console.
2/12/14 7:10:30.000 PM kernel[0]: XCPM: registered
2/12/14 7:10:31.000 PM kernel[0]: IOPPF: XCPM mode
2/12/14 7:10:31.000 PM kernel[0]: XCPM: P-state table mismatch (error:0x11)
2/12/14 7:10:31.000 PM kernel[0]: X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x11
Thanks. I fixed the desktop model error (should use 1 and not 2) in v10.6
About the error:0x11 That is some strange index bug. Seems to point to the P-State for 1700 MHz when it expects 1600 MHz. I even re-checked the AML/DSL code of related Apple ACPI tables and what we do is exactly the same as what Apple does, but for some odd reason it isn't working for Ivy Bridge hacks.
Note: Increasing the package length with one, like you said to have done in one of your last e-mails, gave me this remark:
/Users/Apple/Desktop/ssdt_pr.dsl 45: Name (APSS, Package (0x17) Remark 5063 - Initializer list shorter than declared package length ^
In my case it should be 0x16
Yes, MaciASL gave me that notification too. But it still compiles and -xcpm runs with no errors for me but it causes automatic Time Machine Backups to fail for me.
Even though I've been getting the errors with a "correct" SSDT everything seems to be working 100%. Should I worry about it?
Is there any downside to having the error? Because I'm able to use the macpro3,1 profile with -xcpm enabled and everything seems to work fine.
I'm starting to think this is just a kernel bug. I never get this error message
X86PlatformShim::initializePMInfo - Failed to send stepper
When I run the script I get this output:
ssdtPRGen.sh v0.9 Copyright (c) 2011-2012 by † RevoGirl
v6.6 Copyright (c) 2013 by † Jeroen
v13.4 Copyright (c) 2013-2014 by Pike R. Alpha
-----------------------------------------------------------
Bugs > https://github.com/Piker-Alpha/ssdtPRGen.sh/issues <
System information: Mac OS X 10.9.2 (13C1021)
Brandstring 'Intel(R) Core(TM) i7-4700HQ CPU @ 2.40GHz'
Scope (_PR_) {220 bytes} with ACPI Processor declarations found in the DSDT (ACPI 1.0 compliant)
Generating ssdt.dsl for a 'iMac14,2' with board-id [Mac-*********replaced**************]
Haswell Core i7-4700HQ processor [0x306C3] setup [0x0705]
With a maximum TDP of 47 Watt, as specified by Intel
Number logical CPU's: 8 (Core Frequency: 2400 MHz)
Number of Turbo States: 12 (2500-3600 MHz)
Number of P-States: 29 (800-3600 MHz)
Adjusting C-States for detected (mobile) processor
Injected C-States for CPU0 (C1,C3,C6,C7)
Injected C-States for CPU1 (C1,C2,C3)
Warning: 'system-type' may be set improperly (2 instead of 1)
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20130117-64 [Jan 19 2013]
Copyright (c) 2000 - 2013 Intel Corporation
ASL Input: /Users/andrei/Desktop/ssdt.dsl - 324 lines, 9749 bytes, 71 keywords
AML Output: /Users/andrei/Desktop/ssdt.aml - 2106 bytes, 28 named objects, 43 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
Should I worry about above warning regarding 'system-type'?
After dropping the SSDT for CpuPm and unchecking the Generate pstate and cstate in Clover, I'm getting a similar error:
IOPPF: XCPM mode
XCPM: P-state table mismatch (error:0x12)
X86PlatformShim::sendPStates - pmCPUControl (XCPMIO_SETPSTATETABLE) returned 0x12
X86PlatformShim::start - Failed to send PStates
[AGPM Controller] unknownPlatform
Also, how do I know that my CPU is properly recognized? How do I know this works?
Using the latest script (9.6) I get these messages in the console.
Here is the generated ssdt.aml