AICPMPatch

[pernacabeluda]

Então é só colocar a DSDT que tu anexou e pronto?

Sim, junto com o SSDT.aml gerado pelo script.

 

Mesmo assim ainda tenho que peatchear a AICPM?

Testa sem, se tiver KP, aplica o patch.

[PimentelX86]

Olá camarada.

*Coloquei a SSDT e a DSDT na pasta extra, mas não dei peatcher na AICPM e deixei a Null e o SLeepEnabler carregados. Mas sempre dá o mesmo erro devido o DropSSDT.

*Fiz outro teste Sem a Null e o SleepEnabler, mas ainda sem peatchear a AICPM ainda e apareceu o mesmo erro devido a DropSSDT.

*Fiz outro teste sem a Null e o SleepEnabler, mas desta vez dei petcher na AICPM e apareceu o mesmo erro devido a DropSSDT.

*Pensei que por não ter colocado a identificação de que eu tenho DSDT no org.chameleon é que dava dando o erro, mas coloquei a identificação:

<key>DSDT</key>
<string>/Extra/DSDT.aml</string>

 

E mesmo assim o erro pesistiu.

*Fiz todos esses testes, mas tenho quase certeza que o erro provem da DropSSDT. Notei algo que chamou minha atenção. No tópico oficial do flAked: http://www.insanelymac.com/forum/topic/258611-speedstepper-now-supports-mountain-lion-1083/

Ele fala lá embaixo:

SpeedStepper v1.3 for Mountain Lion 10.8.3

Only works with AICPUPM v196.0.0

Minha AICPM é v196.0.0, mas uso o ML 10.8, será que isso conta?

Aqui esta a imagem do erro que tanto me persegue quando coloco DropSSDT:

 

Foto1088.jpg.zip

[pernacabeluda]

E se deixar sem o DropSSDT?

O patcher do flAked faz o mesmo que o AICPMPatch, a diferença é que o SpeedStepper tem os offsets hardcoded enquanto o AICPMPatch detecta automaticamente. Eu já verifiquei os offsets de todas as versões e conferem, com certeza não é esse o problema.

[PimentelX86]

Olá camarada

Se deixar sem DropSSDT=No na tela de boot o sistema sobe, mas só se tiver a NullCPUPowermanagement.

Quando removi a Null e tentei iniciar somente com AICPM patcheada o sistema não sobe.

Tens algumas soluções em mente?

[pernacabeluda]

Solução para "não sobe" eu não conheço nenhuma.

Mostra uma foto da tela com DSDT.aml e SSDT.aml na Extra, sem DropSSDT, sem NullCPUPM e com AICPUPM patcheada.

[PimentelX86]

Olá camarada

Bem que eu queria poder lhe mostrar essa foto, mas o problema é que a a mensagem passa muito rápida e o sistema reinicia.

Mas houve uma hora que deu pra ver mais ou menos que a mensagem era de KP.

[pernacabeluda]

Você está usando Clover? Veja a mensagem no log (Console.app - /Library/Logs/CloverEFI/boot.log).

Com Chameleon, se fosse KP, ficaria parado na tela.

Se não conseguir nada, pode gravar o boot em vídeo, pausar na mensagem e capturar a tela.

[PimentelX86]

Olá camarada

Uso Chameleon. Vou tentar capturar no momento certo.

Me diz uma coisa: Tem como fazer o gerenciamento de energia sem ser por esse script? Criar uma SSDT feita por mim?

[pernacabeluda]

O que um script faz, você pode fazer manualmente.

O artur-pt te indicou um guia.

[PimentelX86]

Olá camarada

Está certo. Mas existe um programa chamado MACAISL, ele faz isso também né?

Se eu for fazer manualmente preciso ou não petchear a AICPM?

Posso usar aquela feita pelo IOReg? Ou posso aproveitar a feita pelo script e somente ajustar? Pois me parece que a do script está mais completa ou não? E se eu fosse usar a do script preciso da AICPM peatcheada.

Ufa! Quantas perguntas, desculpa por isso, mas é que em gerenciamento de energia ainda estou um pouco perdido.

[pernacabeluda]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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?