Bug 234455

Summary:	CPU frequency scaling fails for multiple cores
Product:	Base System	Reporter:	D Green <dfrg>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Some People	CC:	cem, dg, freebsd.ed.lists, jamie, sascha.folie, schaiba
Priority:	---
Version:	12.0-RELEASE
Hardware:	amd64
OS:	Any

Description D Green 2018-12-28 09:22:15 UTC

An intel i5-8400 processor has 6 cores. On both FreeBSD 11.2 and 12.0-RELEASE frequency scaling via both powerd or explicit sysctl is broken unless all but one core is disabled via BIOS.

# sysctl dev.cpu.0.freq_levels
dev.cpu.0.freq_levels: 2801/65000 2800/65000 2700/61690 2500/55888 2400/52759 2200/47301 2100/44946 1900/39204 1800/37000 1700/34277 1500/29546 1400/27531 1200/22557 1100/20688 900/16549 800/14296

# sysctl dev.cpu.0.freq=2800
dev.cpu.0.freq: 800 -> 800

It appears cf_set_method() returns EPERM at sys/kern_cpu.c:287 and commenting out that conditional restores frequency scaling when multiple cores are enabled.

Whilst this ugly local patch suffices its obviously not correct and I'm not sure how to proceed from here.

Comment 1 Conrad Meyer freebsd_committer

2018-12-28 19:36:43 UTC

If you set debug.acpi.disabled="thermal" in loader.conf and reboot, does powerd / sysctl work?  It seems any kernel setting overrides and userspace space setting.

A related question, what are the temperature sensors reporting?  Is your CPU cooled appropriately / might it be reasonable that thermal throttling is kicking in?

Comment 2 Conrad Meyer freebsd_committer

2018-12-28 19:43:21 UTC

This code hasn't changed substantially in a long time, so I suspect this is not some recent regression.

Comment 3 Erich Dollansky 2019-01-30 15:04:39 UTC

It could be that this is related to my observation:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234733

Comment 4 Dave Green 2020-01-21 20:02:34 UTC

Still present in 12.1-RELEASE-p1

Comment 5 Conrad Meyer freebsd_committer

2020-01-21 20:16:22 UTC

@Dave, did you try debug.acpi.disabled="thermal"?  It seems bizarre that the default dev.cpu.0.freq is 800.  Is that the case at boot, or was your initial description after running, say, powerd?  It might be that Coffeelake does not really support est and needs Intel Speed Shift instead.  That is not yet in tree but there is a work-in-progress patch: https://reviews.freebsd.org/D18028

@Erich, I suspect these are unrelated issues in that a different cpufreq driver is used on Zen (hwpstate) and Intel (est).  But maybe there is some relation.

I do not recommend powerd and would suggest disabling it.  In fact, we should probably remove it from FreeBSD.  It is extremely legacy and only really works correctly on ancient single core devices.

I also don't recommend manual p-state setting via sysctl.  Modern CPUs do a fantastic job of power saving with C states alone — P-state throttling doesn't get you much anymore.

Comment 6 Dave Green 2020-01-21 20:31:05 UTC

CPU is 800 at boot either with or without powerd.

Temperature is always stable at 25 degrees.

I'll retry debug.acpi.disabled="thermal" but I don't recall it having any effect for 11.2-RELEASE.

If I comment out the conditional in cf_set_method() at kern/kern_cpu.c:291 then both sysctl and powerd can be used to adjust the frequency.

>    if (priority < sc->curr_priority) {
>        CF_DEBUG("ignoring, curr prio %d less than %d\n", priority,
>            sc->curr_priority);
>        error = EPERM;
>        goto out;
>    }

Comment 7 Conrad Meyer freebsd_committer

2020-01-21 21:29:51 UTC

I wonder where those bogus priorities are coming from, though.  I thought I recall looking and seeing acpi_thermal as the only possible source, but I might be mistaken.

Comment 8 Conrad Meyer freebsd_committer

2020-01-21 21:30:10 UTC

Also: 800 at boot sounds like a BIOS bug.

Comment 9 schaiba 2020-01-24 08:28:00 UTC

FWIW, debug.acpi.disabled="thermal" on my 12.1-p1 system on a AMD Ryzen seems to have solved the issue I had with the CPU staying at the lowest frequency even when building world.

Comment 10 D Green 2021-05-08 08:06:03 UTC

Fixed in 13.0-RELEASE