[solved] Problem with AppleALC/CodecCommander

[higorhlg]

I have a problem with AppleALC kext causing cpu frequency to stay at maximum(3.1ghz) and constant use around 20%.
Here's what I observed about CPU Frequency, CPU Utilization and kernel_task in the following situations(in all cases system is idle, with maybe a few apps running):
Boot with no AppleALC(no CodecCommander):
Frequency: 1.3 ghz~2 ghz / Utilization: 3%~10% kernel_task: 10%~25%
Boot with AppleALC(no CodecCommander):
Frequency: 3.1 ghz(constant) / Utilization: 20%~60% kernel_task: 50%~80%
Boot with AppleALC+CodecCommander:
Frequency: 1.3 ghz~2 ghz / Utilization: 3%~10% kernel_task: 10%~25%

So, CodecCommander seems to be "fixing" whatever the issue AppleALC is causing, yet I still have a problem:
When the laptop wakes from sleep, The results of frequency, utilization and kernel_task fly up high to the same state as if the system had booted with AppleALC without CodecCommander.
In other words, CodecCommander "fixes" the problem that AppleALC is causing, but the problem comes back after sleep(on wake).

I tried to do some editing on CodecCommander on the ALC256(my audio codec) section, but no success.

Attached pictures of the system running before and after sleep(boot with AppleALC + CodecCommander).

 

[RehabMan]

I have a problem with AppleALC kext causing cpu frequency to stay at maximum(3.1ghz) and constant use around 20%.
Here's what I observed about CPU Frequency, CPU Utilization and kernel_task in the following situations(in all cases system is idle, with maybe a few apps running):
Boot with no AppleALC(no CodecCommander):
Frequency: 1.3 ghz~2 ghz / Utilization: 3%~10% kernel_task: 10%~25%
Boot with AppleALC(no CodecCommander):
Frequency: 3.1 ghz(constant) / Utilization: 20%~60% kernel_task: 50%~80%
Boot with AppleALC+CodecCommander:
Frequency: 1.3 ghz~2 ghz / Utilization: 3%~10% kernel_task: 10%~25%

So, CodecCommander seems to be "fixing" whatever the issue AppleALC is causing, yet I still have a problem:
When the laptop wakes from sleep, The results of frequency, utilization and kernel_task fly up high to the same state as if the system had booted with AppleALC without CodecCommander.
In other words, CodecCommander "fixes" the problem that AppleALC is causing, but the problem comes back after sleep(on wake).

I tried to do some editing on CodecCommander on the ALC256(my audio codec) section, but no success.

Attached pictures of the system running before and after sleep(boot with AppleALC + CodecCommander).

Keep in mind SSDT-AppleALC.aml (see SSDT-AppleALC.dsl in CodecCommander repo) when trying to use CodecCommander and AppleALC together.

 

[higorhlg]

Keep in mind SSDT-AppleALC.aml (see SSDT-AppleALC.dsl in CodecCommander repo) when trying to use CodecCommander and AppleALC together.

I fixed the problem by using SSDT-ALC256.aml and replacing the CodecCommander kext which I had edited(for alc256) with a clean new one.
Yet I still notice cpu usage around 10% while idle even with no apps open, and the cause seems to be VoodooI2C and/or Voodoo2CHID, is this normal?

 

[RehabMan]

Yet I still notice cpu usage around 10% while idle even with no apps open, and the cause seems to be VoodooI2C and/or Voodoo2CHID, is this normal?

Why are you asking me?
Easy for you to test/verify: Remove the suspect kexts and test.

 

[higorhlg]

Why are you asking me?
Easy for you to test/verify: Remove the suspect kexts and test.

Yes, I tested, what I wanted to ask is if cpu usage around 10% on idle is normal when using those kexts, if you have experienced it too, that is, if you even use it.

 

[RehabMan]

Yes, I tested, what I wanted to ask is if cpu usage around 10% on idle is normal when using those kexts, if you have experienced it too, that is, if you even use it.

I don't use those kexts. No I2C hardware here. Easy for you to verify by testing each case (with/without the suspect kexts).

 

[higorhlg]

I don't use those kexts. No I2C hardware here. Easy for you to verify by testing each case (with/without the suspect kexts).

Ok, anyway, the thread case has been solved, thank you very much.

 

[baohiep]

@higorhlg Are you using VoodooI2C in interrupt or polling mode? Polling mode will cause more CPU usage

 

[higorhlg]

@higorhlg Are you using VoodooI2C in interrupt or polling mode? Polling mode will cause more CPU usage

I'm using it on Interrupt mode as far as I know

 

[baohiep]

@higorhlg The best way to check is checking kernel log. Reboot your laptop, and run this command:

log show --predicate 'process == "kernel"' --start "2017-01-01 00:00:00"

Remember to change the time so that it will only show log from latest boot
Then find VoodooI2C and check if it's in interrupt or polling mode