Tijl Coosemans wrote:
A couple days ago I updated my system and was excited to see cpufreq
and powerd in 5-stable. Since then however I noticed that my laptop
temperature is about 5°C higher than with est and estctrl. I found that
cpufreq when setting 200MHz for example set the absolute frequency to
1600MHz (max for this laptop) and the relative frequency (p4tcc) to
12.5% instead of using a more power conserving setting like 800MHz/25%.

The problem is that cpufreq_expand_set() (sys/kern/kern_cpu.c)
traverses freq levels from high to low when adding relative levels and
skips duplicates. When it wants to add 800MHz/25% it sees this setting
as a duplicate of 1600MHz/12.5% it has found before. This can be fixed
by letting cpufreq_expand_set() traverse freq levels in reverse order
(and still skipping duplicates). Then each frequency level has the
lowest possible absolute setting. This is a one line change in
sys/kern/kern_cpu.c (line 653).

You have some valid issues but I need some time to analyze your patch to be sure it doesn't introduce new problems. There may be some issues with traversing the list backwards.

Also, somewhat related, the p4tcc driver doesn't recognise
acpi_throttle, which means that when you load the cpufreq module after
booting, the freq levels are messed up. I'm not sure what the best
solution for this is. Let p4tcc detect acpi_throttle and don't attach
if it's present (like acpi_throttle does now if it finds p4tcc) or
detach it before attaching? Or maybe p4tcc and acpi_throttle should be
merged into one driver?

cpufreq is not set up for loading after boot currently. It must be loaded at boot. There are architectural issues that need to be solved to make this happen, namely real arbitration between drivers loaded that support the same feature through different mechanisms. p4tcc and acpi_throttle on some architectures is such a combo that needs special attention.

Finally, is the kernel config option CPU_ENABLE_TCC still relevant?
Because it's still listed in NOTES.

The old option should be removed.

I'll try to review this patch and commit it sometime soon.

--
Nate
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to