AICPMPatch

pernacabeluda · July 24, 2013

São duas coisas distintas, não existe relação. Patch na AICPM só precisa quem tiver KP por causa de bloqueio no BIOS para wrmsr. SSDT só precisa quem tem Sandy ou Ivy Bridge e usa Chameleon (Clover gera automaticamente).

O MacIASL usa o script do Pike, portanto não vai fazer diferença.

PimentelX86 · July 25, 2013

Olá camarada.

Pode parecer loucura, mas quando iniciava o sistema com a DSDT.aml e SSDT.aml na Extra, sem DropSSDT, sem NullCPUPM e com AICPUPM patcheada, na primeira vez não iniciou.

Mas outra hora tentei iniciar o sistema para fazer mais testes e o sistema iniciou, antes só iniciava se eu coloca-se um USB bootável com ML. Mas com DropSSDT continua o mesmo erro. Terei gerenciamento de energia sem a DropSSDT?

pernacabeluda · July 25, 2013

Você disse que não tinha DSDT, será que não era esse o problema? Testa sem ele para ver se faz diferença. Eu apliquei outros patches básicos como o HPET, que é uma causa comum de KP sem NullCPUPM

http://Olarila.com/forum/viewtopic.php?f=7&t=646

Para saber se tem gestão de energia testa com o HWMonitor (Instala FakeSMC + IntelCPUMonitor)

http://Olarila.com/files/10.8/HWSensors/HWSensors.zip

PimentelX86 · July 25, 2013

Olá camarada

Testei com e sem DSDT e o sistema subiu(iniciou)

Eu já tinha DSDT e o sistema antes não subia, agora que tenho sobe. Não sei o que fez a coisa trabalhar.

Iniciei o programa e ele me deu isso:

*A Frequência fica em 1584Mhz com multiplicador x16.0 e varia de 37 a 42º nas CPU

Essa frequência permanece por um tempo, mas logo notei um pico que fica assim:

*A Frequência fica em 3465Mhz com multiplicador x35.0 e varia de 40 a 42º nas CPU

Depois volta à aquela frequência anterior.Meu Processador tem 3.4Ghz ou 3400Mhz não sei e tenho gerenciamento nativo. E talvez ele esteja um pouco acima da frequência. O que acha?

pernacabeluda · July 25, 2013

Acho que está funcionando. Roda o comando yes no terminal, enquanto ele estiver rodando deve permanecer em x35, ao interromper deve voltar para x16.

PimentelX86 · July 25, 2013

Olá camarada

Digito yes e fica sempre em x35.0 como disse, mas fico com medo de que dê defeito na CPU devido sempre trabalhar em frequência alta.

Eu também vasculhei por ai e li alguém falar sobre um comando chamado DropOemSSDT. Coloquei no org.chameleon e o sistema subiu sem problemas, mas não sei se esse DropOemSSDT é um comando válido.

O que achas sobre tudo?

pernacabeluda · July 25, 2013

Ele não volta para x16 quando interrompe o comando yes? Isso é o normal, aumentar o multiplicador quando o CPU é exigido e reduzir quando está ocioso.

DropOemSSDT é do Clover.

Não precisa se preocupar com DropSSDT, as partes que precisam ser "dropadas" (P e C states) no seu caso estão na DSDT, você deve remover manualmente.

PimentelX86 · July 25, 2013

Olá camarada.

Ele não volta para x16 quando interrompe o comando yes? Isso é o normal, aumentar o multiplicador quando o CPU é exigido e reduzir quando está ocioso.

Quando finalizo o terminal volta para x16. Menos mal em relação a isso pensei que iria fazer mal ao CPU, mas quando esta nessa frequência ele fica em torno de 50° na CPU, isso é normal?

Não precisa se preocupar com DropSSDT, as partes que precisam ser "dropadas" (P e C states) no seu caso estão na DSDT, você deve remover manualmente.

Nesse caso tu já removeu na minha DSDT que tu editou né? Eu posso fazer alguns ajustes na SSDT gerada pelo script com o guia que o camarada artur fez?

DropOemSSDT vou tirar pensei que servia para Chameleon. Tem como deixar sempre em x35 sempre com algum método, pois deixar o terminal rodando com yes é muito chato.

pernacabeluda · July 25, 2013

Quando finalizo o terminal volta para x16. Menos mal em relação a isso pensei que iria fazer mal ao CPU, mas quando esta nessa frequência ele fica em torno de 50° na CPU, isso é normal?

Sim, é normal. Seria problema se ficasse sempre em x35.

Nesse caso tu já removeu na minha DSDT que tu editou né? Eu posso fazer alguns ajustes na SSDT gerada pelo script com o guia que o camarada artur fez?

Pode, mas pelo que entendo a gerada pelo script já está boa.

Tem como deixar sempre em x35 sempre com algum método, pois deixar o terminal rodando com yes é muito chato.

Por que você iria fazer isso? Tanto trabalho para fazer o SpeedStep funcionar e agora você quer deixar o CPU sempre no máximo? Não te entendo...

Acho que você não entendeu o propósito do gerenciamento de energia. Se deixar o CPU sempre na frequência máxima, além de consumir mais energia, vai elevar a temperatura e reduzir a vida útil. Por isso queremos ativar a gestão de energia, fazer com que o CPU trabalhe na máxima frequência quando for necessário e reduzir ao mínimo quando não for.

PimentelX86 · July 25, 2013

Olá camarada

Então o comando yes foi somente para ver se o SpeedStep estava funcionando né.

Entendi sobre o gerenciamento de energia, pelo visto esta trabalhando bem.

Mas vou dar uma olhada e ver se consigo melhor mais o SSDT se não deixo como esta.

Então está assim:

*DSDT na extra.

*SSDT na extra.

*Sem NullCPUPM.

*AICPUPM patcheada.

*DropSSDT=No

Só mais uma pergunta: Como posso saber se meu CPU suporta o Kernel Vannila? Pois sendo ele tem mais vantagem no gerenciamento certo?

pernacabeluda · July 25, 2013

Então o comando yes foi somente para ver se o SpeedStep estava funcionando né.

Exato.

Só mais uma pergunta: Como posso saber se meu CPU suporta o Kernel Vannila? Pois sendo ele tem mais vantagem no gerenciamento certo?

Com certeza funciona, deve ser o que você está usando.

PimentelX86 · July 25, 2013

Olá camarada

Que bom saber que tenho Kernel Vanilla.

Somente uma coisa falta: Creio que não tenho Sleep funcionando direito.

Dou repouso e o computador repousa até o cooler para, mas quando volto do repouso é que o problema aparece. O mouse do computador fica lentíssimo e travando.

Tens alguma ideia? Talvez eu deva aplicar algum patcher na DSDT?

pernacabeluda · July 25, 2013

Não tenho idéia.

Testa se faz alguma diferença com ou sem a DSDT que eu te enviei.

Não é assunto para este tópico, dá uma procurada e se não encontrar nada cria um novo tópico.

PimentelX86 · July 25, 2013

Olá camarada

Vou procurar acerca disso tudo.

*Meu hack já tem um gerenciamento de energia quase perfeito(só falta Sleep).

*Tem gráfica trabalhando(só não sei se tem QE/CI, mas já possuo barra translucida).

*Áudio funcionado(só falta ajeitar os canais para 5.1 surround).

*Internet já funciona.

Valeu a pena 4 meses de "fabricação" do hack.

Obrigado PernaCabeluda por todo o suporte até agora me ajudou muito.

mendietinha · August 5, 2013

não sei pq mas sigo os comandos daqui como sempre mas aparece esse erro na aicpm do mavericks dp4:

Unrecognized character \xCF; marked by <-- HERE after <-- HERE near column 1 at /Users/mendietinha/Desktop/AppleIntelCPUPowerManagement.kext/Contents/MacOS/AppleIntelCPUPowerManagement line 1.

como posso corrigir isso? no dp1 não tive problemas.

pernacabeluda · August 5, 2013

Quando aparece essa mensagem?

Aqui vai normal

found wrmsr at 9e33, patched
found wrmsr at 9e9e, patched
found wrmsr at 9f00, patched
found wrmsr at a78b, patched
found wrmsr at a99d, patched
found wrmsr at aba5, patched
found wrmsr at b5d5, patched
found wrmsr at b92b, patched
found wrmsr at 11733, patched
found wrmsr at 12a5a, patched
found wrmsr at 143ee, patched
found wrmsr at 1ce3d, patched
found wrmsr at 1e229, patched

mendietinha · August 5, 2013

aparece quando dou o sudo. estranho.

mas já resolvi pegando de um pacote no insanelymac.

philip_petev · September 7, 2013

Hi there,

This patch works perfectly (at least with OS X ML and later), but I think there's something wrong, when it's being used with OS X Lion and earlier. Initially, the patch is doing its job under these two OS X versions, but if you run it one more time on the same binary, it will find again something for patching. I've made a test script, which uses this one to patch the AICPM binary 10 times in a row and here are the results:

With vanilla AICPM.kext from OS X SL 10.6.8

Starting the patch test on ./AppleIntelCPUPowerManagement

Initial MD5: 34b41cf327a6914acb3a26e55e7df292

Attempt 1

./AppleIntelCPUPowerManagement

arch: x86_64

found wrmsr at 948e, patched

found wrmsr at 98c1, patched

found wrmsr at 997e, patched

found wrmsr at 99eb, patched

found wrmsr at 9aae, patched

found wrmsr at a958, patched

found wrmsr at abff, patched

found wrmsr at ac96, patched

found wrmsr at 11d0e, patched

found wrmsr at 11dc2, patched

arch: i386

found wrmsr at 34a46, patched

found wrmsr at 34d3e, patched

found wrmsr at 34d5f, patched

found wrmsr at 34f03, patched

found wrmsr at 34fa2, patched

found wrmsr at 35f27, patched

found wrmsr at 3617c, patched

found wrmsr at 361ce, patched

found wrmsr at 3d61a, patched

found wrmsr at 3d677, patched

MD5: 475e6e9103be251e31cfbc4c8b77775e

Attempt 2

./AppleIntelCPUPowerManagement

arch: x86_64

found wrmsr at 9c8e, patched

arch: i386

found wrmsr at 351a9, patched

MD5: 4d3d57cac6d440d6d8f97725587ea6b1

Attempt 3

./AppleIntelCPUPowerManagement

arch: x86_64

found wrmsr at 9c93, patched

arch: i386

found wrmsr at 351ad, patched

MD5: 72708c9ed6272a7fdb230a5deadff99a

Attempt 4

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

found wrmsr at 35382, patched

MD5: 47fc309fe056e45aa6f4c7d62fe29bcd

Attempt 5

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 47fc309fe056e45aa6f4c7d62fe29bcd

Attempt 6

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 47fc309fe056e45aa6f4c7d62fe29bcd

Attempt 7

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 47fc309fe056e45aa6f4c7d62fe29bcd

Attempt 8

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 47fc309fe056e45aa6f4c7d62fe29bcd

Attempt 9

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 47fc309fe056e45aa6f4c7d62fe29bcd

Attempt 10

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 47fc309fe056e45aa6f4c7d62fe29bcd

With vanilla AICPM.kext from OS X Lion 10.7.5

Starting the patch test on ./AppleIntelCPUPowerManagement

Initial MD5: ca66ae8acf93d6bbae4f8b47e9b8ab11

Attempt 1

./AppleIntelCPUPowerManagement

arch: x86_64

found wrmsr at a312, patched

found wrmsr at a35b, patched

found wrmsr at a6e5, patched

found wrmsr at ac6b, patched

found wrmsr at ad36, patched

found wrmsr at addf, patched

found wrmsr at b639, patched

found wrmsr at bda9, patched

found wrmsr at 1253f, patched

found wrmsr at 13f05, patched

found wrmsr at 153bd, patched

arch: i386

found wrmsr at 39b73, patched

found wrmsr at 39ba4, patched

found wrmsr at 39eff, patched

found wrmsr at 3a484, patched

found wrmsr at 3a52d, patched

found wrmsr at 3a5a7, patched

found wrmsr at 3ad5b, patched

found wrmsr at 3b4d0, patched

found wrmsr at 418de, patched

found wrmsr at 43556, patched

found wrmsr at 449b6, patched

MD5: 0955d983091bf150d66fad037f3f3284

Attempt 2

./AppleIntelCPUPowerManagement

arch: x86_64

found wrmsr at ad8c, patched

arch: i386

MD5: 169bf480405177e88235aab87f891dd7

Attempt 3

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 169bf480405177e88235aab87f891dd7

Attempt 4

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 169bf480405177e88235aab87f891dd7

Attempt 5

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 169bf480405177e88235aab87f891dd7

Attempt 6

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 169bf480405177e88235aab87f891dd7

Attempt 7

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 169bf480405177e88235aab87f891dd7

Attempt 8

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 169bf480405177e88235aab87f891dd7

Attempt 9

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 169bf480405177e88235aab87f891dd7

Attempt 10

./AppleIntelCPUPowerManagement

arch: x86_64

arch: i386

MD5: 169bf480405177e88235aab87f891dd7

As you can see, the kexts under these two OS X versions can be patched several times (4 times in SL 10.6.8 and 2 times in Lion 10.7.5). My presumption is the situation will be the same with all kext versions between these two. There is no such issue on ML:

With vanilla AICPM.kext from OS X ML 10.8.1

Starting the patch test on ./AppleIntelCPUPowerManagement

Initial MD5: 25c8cdae193c973521ccfea021d66a77

Attempt 1

./AppleIntelCPUPowerManagement

arch: x86_64

found wrmsr at 97cc, patched

found wrmsr at a05e, patched

found wrmsr at a0e9, patched

found wrmsr at a136, patched

found wrmsr at a266, patched

found wrmsr at a580, patched

found wrmsr at afd2, patched

found wrmsr at b2c5, patched

found wrmsr at 1165b, patched

found wrmsr at 12a7a, patched

found wrmsr at 13389, patched

MD5: e4ac16e5bf43d51010a0ba2accef5cf4

Attempt 2

./AppleIntelCPUPowerManagement

arch: x86_64

MD5: e4ac16e5bf43d51010a0ba2accef5cf4

Attempt 3

./AppleIntelCPUPowerManagement

arch: x86_64

MD5: e4ac16e5bf43d51010a0ba2accef5cf4

Attempt 4

./AppleIntelCPUPowerManagement

arch: x86_64

MD5: e4ac16e5bf43d51010a0ba2accef5cf4

Attempt 5

./AppleIntelCPUPowerManagement

arch: x86_64

MD5: e4ac16e5bf43d51010a0ba2accef5cf4

Attempt 6

./AppleIntelCPUPowerManagement

arch: x86_64

MD5: e4ac16e5bf43d51010a0ba2accef5cf4

Attempt 7

./AppleIntelCPUPowerManagement

arch: x86_64

MD5: e4ac16e5bf43d51010a0ba2accef5cf4

Attempt 8

./AppleIntelCPUPowerManagement

arch: x86_64

MD5: e4ac16e5bf43d51010a0ba2accef5cf4

Attempt 9

./AppleIntelCPUPowerManagement

arch: x86_64

MD5: e4ac16e5bf43d51010a0ba2accef5cf4

Attempt 10

./AppleIntelCPUPowerManagement

arch: x86_64

MD5: e4ac16e5bf43d51010a0ba2accef5cf4

Such was the result with the kexts from 10.8.5 12F36 and Mavericks DP7. Is there a way for this issue to be fixed?

RehabMan · September 7, 2013

I've been working with philip_petev on this very issue... and... I have my own version of this script.

Change log:

- it will work with a (newer) otool where the disassembler writes immediates in decimal

- it will not patch an already patched AppleIntelCPUPowerManagement binary

- there is a bit more debug info (as I was using it to figure out what the changes should be...)

Code follows:

#!/usr/bin/perl
# by el coniglio
#
# modified by RehabMan to work with more versions of otool
# (some versions of otool are writing disassembled code using
#  decimal instead of hex)
#
# other changes by RehabMan to not patch if already patched

$file = $ARGV[0];
$patch = 0;
if($ARGV[1] and $ARGV[1] eq "--patch") {
$patch = 1;
}
if(!$file) {
die "Usage: perl $0 <file> [--patch]\n";	
}
my %arch;
my %off;
my %addr;

open(PIPE, "lipo -detailed_info $file|");
while(<PIPE>) {
chomp;
$line = $_;
if($line =~ /^architecture (.*)$/) {
	$carch = $1;
} elsif($line =~ /offset (\d+)$/) {
	$arch{$carch} = $1;
} elsif($line =~ /^Non-fat .* architecture: (.*)$/) {
	$carch = $1;
	$arch{$carch} = 0;
}
}
close(PIPE);

print "\n$file\n";

foreach $ar (keys %arch) {
my @enderecos = ();

print "\narch: ".$ar."\n\n";

open(PIPE, "otool -l -arch $ar $file|");
$segname = "";
while(<PIPE>) {
	chomp;
	$line = $_;
	if($line =~ /sectname (.*)$/) {
		$segname = $1;
	} elsif($segname eq "__text" and $line =~ /addr 0x(.*)$/) {
		$addr{$ar} = hex($1);
	} elsif($segname eq "__text" and $line =~ /offset (\d+)$/) {
		$off{$ar} = $1;
	}
}
close(PIPE);

open(PIPE, "otool -tV -arch $ar $file|");
$flag = 0;
while(<PIPE>) {
	$line = $_;
	if($line =~ /mov[lw]\t\$0x([0-9A-Fa-f]+),\s*\%e?cx/) {
           # rehabman: monitoring deltas
           $line_mov = $line;
           $delta = -1;
           # rehabman end
		$value = hex($1);
		if($value == 0xe2) {
			$flag = 1;
		} else {
			$flag = 0;
		}
	}
       # rehabman: added ecx to be set with decimal (226)
       # mov[lw]\t\$226,\s*\%e?cx
       if($line =~ /mov[lw]\t\$([0-9]+),\s*\%e?cx/) {
           # rehabman: monitoring deltas
           $line_mov = $line;
           $delta = -1;
           # rehabman end
		if($1 == 0xe2) {
			$flag = 1;
		} else {
			$flag = 0;
		}
	}
       # rehabman end
       # rehabman: monitoring deltas
       if ($flag == 1) {
           $delta++;
           #rehabman: one other way to detect (distance of mov to wrmsr)
           #if ($delta > 20) {
           #    $flag = 0;
           #}
       }
       #rehabman end

       # rehabman: added so patching already patched does nothing
       # (if 'ret' instruction seen, no need to patch a following wrmsr
       #  because it is part of a different function)
       if($flag == 1 and $line =~ /^(.*)\tret/) {
           $flag = 0;
       }
       # rehabman end
	if($flag == 1 and $line =~ /^(.*)\twrmsr/) {
           # rehabman: printing line of mov/wrmsr + delta info
           printf("delta: %d\n", $delta);
           printf("%s", $line_mov);
           printf("%s\n", $line);
           # rehabman end
		$tmp = hex($1) + $arch{$ar} + $off{$ar} - $addr{$ar};
		push(@enderecos, $tmp);
		$flag = 0;
	}
}
close(PIPE);

   $found = 0;
   $ignored = 0;
open(FILE, "+<".$file) or die "$file: $!\n";
binmode FILE;
foreach $offset (@enderecos) {
	seek FILE, $offset, 0;
	$ret = read FILE, $data, 2;
	($char1, $char2) = split(//, $data);
	if(ord($char1) == 15 and ord($char2) == 48) {
		if($patch) {
			seek FILE, $offset, 0;
			print FILE chr(144).chr(144);
		}
		printf("found wrmsr at %x".($patch?", patched\n":"\n"), $offset);
           # rehabman: monitoring patching totals
           $found++;
	} else {
		printf("ignored %x (%02x %02x)\n", $offset, ord($char1), ord($char2));
           # rehabman: monitoring ignored totals
           $ignored++;
	}
}
close(FILE);
   # rehabman: counting just FYI...
   printf("wrmsr found: %d\n", $found);
   printf("wrmsr ignored: %d\n", $ignored);
   # rehabman end
}

I tried to bracket my changes with #rehabman/#rehabman end. Hope you find it useful.

oldnapalm · September 9, 2013

Hi there,
This patch works perfectly (at least with OS X ML and later), but I think there's something wrong, when it's being used with OS X Lion and earlier. Initially, the patch is doing its job under these two OS X versions, but if you run it one more time on the same binary, it will find again something for patching. I've made a test script, which uses this one to patch the AICPM binary 10 times in a row and here are the results:

You are right, the script works with all versions, but in some, if you try to patch a kext that is already patched, it will patch instructions that do not need to be patched.

I've been working with philip_petev on this very issue... and... I have my own version of this script.

Change log:

- it will work with a (newer) otool where the disassembler writes immediates in decimal

- it will not patch an already patched AppleIntelCPUPowerManagement binary

- there is a bit more debug info (as I was using it to figure out what the changes should be...)

Thanks, I added your changes and a link to your post in the OP.

Allan · September 22, 2013

Então estava lendo sobre os states do user Pixel.

dai rodei o comando "yes" no Terminal e verifiquei meus states e parecem estar errados...

Meu processador vai até 3.10 GHz ou seja deveria ir a 3100MHz mas vejam como fica os meus states.

E quando eu cancelo o comando Yes.

Como posso concertar isso??

artur-pt · September 22, 2013

olá

o patch é só para n teres KP com a kext

tens de ter ssdt

http://Olarila.com/forum/viewtopic.php?f=2&t=34

bom hack

Allan · September 22, 2013

olá

o patch é só para n teres KP com a kext

tens de ter ssdt

http://Olarila.com/forum/viewtopic.php?f=2&t=34

bom hack

Sim, amigo Artur, eu tenho SSDT.

Veja se esta tudo oks.

SSDT.aml.zip

artur-pt · September 22, 2013

olá

gera com o novo script do pike

tá ai no topico

o k n deve tar a fazer é os turbo..

bom hack

Allan · September 23, 2013

Bem tentei o Script mas nada de Turbo!!

Coloquei o comando "yes" mas ainda permanece assim, trocar para uma FakeSMC mais atual tem haver com isso?

Uso a versão 4.2, e ja tem a versão 5.2.

Edited September 23, 2013 by Guest

Sign In

AICPMPatch

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Hackintosh Tutorials

Hackintosh Tutorials

Support Olarila by making a donation