The Perfect Customac-Pro: X99-A II, i7-6950X, 128GB G.Skill TridentZ, Aorus GTX 1080 TI Xtreme

[kgp]

Never had problems with my display not coming back on (I have a single 4K monitor). Sleepwake does not work though.

Now I understand why brumbear got upset with your comments That sleep/wake does not work is not true. It might still not work perfectly, entirely and have still its limitations, but you are invited to propose and publish alternative solutions at any time if you know how to solve things and issues in a better, more clever and more sophisticated way I am quite happy with that what I reached so far... I do not need sleep/wake at all. I tried to move something in the right direction on user request... That's all! Please feel free to proceed and go ahead

 

[jasperlevi]

Now I understand why brumbear got upset with your comments That sleep/wake does not work is not true. It might still not work perfectly, entirely and have its limitations, but you are invited to propose and publish alternative solutions at any time if you know how to solve things and issues in a better, more clever and more sophisticated way I am quite happy with that what I reached so far... I do not need sleep/wake at all. I tried to move something in the right direction on user request... That's all!

I never meant to say that it's his kext making my sleepwake not work! It has to be a BIOS or Clover setting that will eventually make it work for me too. Maybe I didn't put it so well. My bad, but never my intention.

 

[kgp]

I never meant to say that it's his kext making my sleepwake not work! It has to be a BIOS or Clover setting that will eventually make it work for me too. Maybe I didn't put it so well. My bad, but never my intention.

But in the same way you offend me . You say that the sleep/wake approach I am suggesting does not work at all, independently now from using or not using PMDrvr.kext. But it does, at least if one refers to forced sleep, although maybe still not perfectly and still within some limitations. In any case, you are free to contribute with major improvements at any time!

Cheers,

KGP

 

[jasperlevi]

But in the same way you offend me . You say that the sleep/wake approach I ma suggesting does not work at all, independently now from using or not using PMDrvr.kext. But it does, at least if one refers to forced sleep, although maybe still not perfectly and still within some limitations. In any case, you are free to contribute with major improvements at any time!

Cheers,

KGP

Oh no! I apologise!

OK, to put things (a little more) clearly:

• Your method of implementing XCPM is perfect, and sleep/wake etc., works flawlessly all through. The only thing I found is that if I do not put the XCPM Core Scope patch in the kernel patches, and enable c-states from within Clover, I get C3-states as well.
• As soon as I add the PMDrvr kext to the mix, sleepwake stops working BUT if it is working for others, it definitely has to be a BIOS setting or a patch that I am applying wrong. For instance, I use the FakeCPUID for my 5820K as 0x0306F2 (Clover reports Real CPU Id for it as that value when booting up). Yet, if I enter the same value in Clover in the box for FakeCPUID, it shows up as 0x00306F2 while booting up. If I leave the box blank, it shows up as 0x000000. So any one of these myriad settings could be messing up sleepwake for me. I do not blame the PMDrvr kext for it.

Please excuse me as someone who does not know how to use English very articulately (it is not my primary language) if I do end up offending someone again. I am here very humbly, to get help with something that I have very limited knowledge about.

 

[jasperlevi]

On that note, good night. See you guys on the other side...

 

[kgp]

Oh no! I apologise!

OK, to put things (a little more) clearly:

• Your method of implementing XCPM is perfect, and sleep/wake etc., works flawlessly all through. The only thing I found is that if I do not put the XCPM Core Scope patch in the kernel patches, and enable c-states from within Clover, I get C3-states as well.
• As soon as I add the PMDrvr kext to the mix, sleepwake stops working BUT if it is working for others, it definitely has to be a BIOS setting or a patch that I am applying wrong. For instance, I use the FakeCPUID for my 5820K as 0x0306F2 (Clover reports Real CPU Id for it as that value when booting up). Yet, if I enter the same value in Clover in the box for FakeCPUID, it shows up as 0x00306F2 while booting up. If I leave the box blank, it shows up as 0x000000. So any one of these myriad settings could be messing up sleepwake for me. I do not blame the PMDrvr kext for it.

Please excuse me as someone who does not know how to use English very articulately (it is not my primary language) if I do end up offending someone again. I am here very humbly, to get help with something that I have very limited knowledge about.

Slowly! You are addressing a solution I am searching for months already. So you say that by disabling the "xcpm_core_scope_msrs" KernelToPatch entries and by ticking "Generate Cstates" in the ACPI Section of the Clover Configurator one is able to also get the C3 states?? That would be really great if true and that simple! I will give it a try and report back...

Cheers and good night,

KGP

 

[kgp]

Oh no! I apologise!

OK, to put things (a little more) clearly:

• Your method of implementing XCPM is perfect, and sleep/wake etc., works flawlessly all through. The only thing I found is that if I do not put the XCPM Core Scope patch in the kernel patches, and enable c-states from within Clover, I get C3-states as well.
• As soon as I add the PMDrvr kext to the mix, sleepwake stops working BUT if it is working for others, it definitely has to be a BIOS setting or a patch that I am applying wrong. For instance, I use the FakeCPUID for my 5820K as 0x0306F2 (Clover reports Real CPU Id for it as that value when booting up). Yet, if I enter the same value in Clover in the box for FakeCPUID, it shows up as 0x00306F2 while booting up. If I leave the box blank, it shows up as 0x000000. So any one of these myriad settings could be messing up sleepwake for me. I do not blame the PMDrvr kext for it.

Please excuse me as someone who does not know how to use English very articulately (it is not my primary language) if I do end up offending someone again. I am here very humbly, to get help with something that I have very limited knowledge about.

o.k. I disabled the "xcpm_core_scope_msrs" KernelToPatch entry and ticked "Generate Cstates" in the ACPI section of the Clover Configurator, but there are still no C3-states reported by AppleIntelInfo.kext. Note that for what reason ever I am not able to enable the "xcpm_bootstrap" KernelToPatch entry, as it breaks XCPM in my case (with xcpm_bootstrap enabled, both "sysctl machdep.xcpm.mode" and "sysctl -n machdep.xcpm.vectors_loaded_count" return 0 and the CPU exclusively runs at max. turbo frequency, which means just at one power state). Do you have any explanation why "xcpm_bootstrap" does not work in my case? This also could be the real reason why there are no c3 states in the AppleIntelInfo.kext report. Or does one only obtain the C3-states when using the PMDrvr.kext? Anyway my "xcpm_bootstrap" issue is still without solution. Any help would be more than appreciated!

Let's wait on your reply tomorrow.

Cheers,

KGP

 

[morganb]

Did you check whether or not you properly restored all required BIOS settings after the BIOS update?

Yes, I did.

 

[kgp]

Yes, I did.

And do you use the EIST approach with PMDrvr.kext and related BIOS settings? If you have preferences in sleep/wake remove the EIST approach. Then forced sleep/wake might work again without problems.

 

[morganb]

And do you use the EIST approach with PMDrvr.kext and related BIOS settings? If you have preferences in sleep/wake remove the EIST approach. Then forced sleep/wake might work again without problems.

EIST off, as per original BIOS settings. Will try the other approach tonight.