cpufreq not working as module on i386/amd64

Jia-Shiun Li jiashiun at gmail.com
Thu Jul 4 05:37:34 UTC 2013 

ok anyone can help test and review this patch?

It will allow cpufreq to be removed from kernel conf, loaded and
function correctly as kernel module. I've tested it ok on my own
i5-3450.

It removes get_features method definition from acpi_if.m and
corresponding implementations from est, p4tcc, & hwpstate. Feature
flags are set directly in acpi_cpu.c omitting previous procedure of
querying cpufreq drivers.


After this, I'd like to find some ways to feed CPU loading info
directly in kernel to cpufreq for finer & quicker control of
frequencies.


On Tue, Jan 8, 2013 at 11:01 PM, Konstantin Belousov
<kostikbel at gmail.com> wrote:
> On Tue, Jan 08, 2013 at 01:15:59PM +0800, Jia-Shiun Li wrote:
>> Hi all,
>>
>> move to -hackers as it seems a better place to discuss.
>>
>> Turns out, at  acpi_cpu_attach(), the bus probe will query
>> ACPI_GET_FEATURES() to get cpu_features flags from each cpufreq
>> drivers. Since it is only executed once at booting, subsequent module
>> loading after booting will not be called get_features() and will not
>> be able to express interests in terms of ACPI_CAP_* flags. And if
>> these flags were not set first, acpi_perf won't get attached. Later
>> when loading cpufreq.ko, est_attach(), etc. will not be able to find
>> acpi_perf and thus failed to attach.
>>
>> After referred to Intel doc. #302223 mentioned in
>> dev/acpica/acpivar.h, I got confused by the meaning of these bits.
>> According to the document, capability bits probably should be set as
>> long as OSPM is *capable* of using them, no matter when they will be
>> used. I am not familiar with ACPI, but I suppose it will expose
>> states/methods to OSPM according to these bits?
>>
>> To confirm this, I add a line to simply OR'd (ACPI_CAP_PERF_MSRS |
>> ACPI_CAP_C1_IO_HALT) to sc->cpu_features after the loop calling
>> ACPI_GET_FEATURES(). And then I am able to load cpufreq.ko after boot.
>> powerd also works fine with it.
>>
>> If this is true, then probably we don't need get_features() for acpi
>> interface/drivers. It is sufficient to just turn on proper bits
>> directly for acpi_cpu when related code is added to repository.
>>
>> Any comments?
>>
>> ----->8----->8----->8-----
>> # svn diff
>> Index: sys/dev/acpica/acpi_cpu.c
>> ===================================================================
>> --- sys/dev/acpica/acpi_cpu.c   (revision 245148)
>> +++ sys/dev/acpica/acpi_cpu.c   (working copy)
>> @@ -350,6 +350,7 @@
>>                 sc->cpu_features |= features;
>>         }
>>         free(drivers, M_TEMP);
>> +       sc->cpu_features |= ACPI_CAP_PERF_MSRS | ACPI_CAP_C1_IO_HALT;
>>      }
> I had almost word-to-word identical conversation with Andrey Gapon,
> might be a year ago. I Cc:ed him.
>
>>
>>      /*
>>
>> ----->8----->8----->8-----
>>
>>
>> Jia-Shiun
>>
>> On Wed, Dec 26, 2012 at 2:10 AM, Jia-Shiun Li <jiashiun at gmail.com> wrote:
>> > I was cleaning up hard drive and found these old logs. Anyway I added
>> > some printf()
>> > and saw the process failed at device_find_child(..., "acpi_perf", ...)
>> > of est_acpi_info() i.e. it cannot find acpi_perf device.
>> >
>> > devinfo did confirmed the absence of acpi_perf. Comparing the dmesgs
>> > revealed the main difference: IST (i-state?) OEM tables in SSDT seems
>> > not loaded if cpufreq was not compiled into kernel, as it shows below.
>> >
>> > Before I diving into the ACPI part, can anyone familiar with how ACPI
>> > works shed me some light?
>> >
>> > ----->8----->8----->8-----
>> > % diff -bu cpufreq-nb.log cpufreq-no.log
>> > ...
>> > @@ -158,17 +158,11 @@
>> >  acpi0: Power Button (fixed)
>> >  cpu0: Processor \\_PR_.CPU0 (ACPI ID 1) -> APIC ID 0
>> >  cpu0: <ACPI CPU> on acpi0
>> > -ACPI: SSDT 0xbfd8dc98 00223 (v01  PmRef  Cpu0Ist 00003000 INTL 20051117)
>> > -ACPI: Dynamic OEM Table Load:
>> > -ACPI: SSDT 0 00223 (v01  PmRef  Cpu0Ist 00003000 INTL 20051117)
>> >  ACPI: SSDT 0xbfd8b598 00537 (v01  PmRef  Cpu0Cst 00003001 INTL 20051117)
>> >  ACPI: Dynamic OEM Table Load:
>> >  ACPI: SSDT 0 00537 (v01  PmRef  Cpu0Cst 00003001 INTL 20051117)
>> >  cpu1: Processor \\_PR_.CPU1 (ACPI ID 2) -> APIC ID 1
>> >  cpu1: <ACPI CPU> on acpi0
>> > -ACPI: SSDT 0xbfd8ce18 001CF (v01  PmRef    ApIst 00003000 INTL 20051117)
>> > -ACPI: Dynamic OEM Table Load:
>> > -ACPI: SSDT 0 001CF (v01  PmRef    ApIst 00003000 INTL 20051117)
>> >  ACPI: SSDT 0xbfd8df18 0008D (v01  PmRef    ApCst 00003000 INTL 20051117)
>> >  ACPI: Dynamic OEM Table Load:
>> >  ACPI: SSDT 0 0008D (v01  PmRef    ApCst 00003000 INTL 20051117
>> >
>> > On Sat, Jan 29, 2011 at 4:41 PM, Alexander Best <arundel at freebsd.org> wrote:
>> >> On Sat Jan 29 11, Jia-Shiun Li wrote:
>> >>> Hi all,
>> >>>
>> >>> I found that cpufreq driver failed to attach when compiled as module
>> >>> and loaded, but it works fine when compiled into kernel. I am
>> >>> wondering if this is due to some kind of limitation, or can be fixed?
>> >>
>> >> that's rather odd. for me neither the module nor the kernel code works, since
>> >> my cpu isn't supported by sys/x86/cpufreq/est.c. actually only pentium mobile
>> >> cpus seem to be supported.
>> >>
>> >> maybe you can add some printf's to est.c:est_get_info() to identify at which
>> >> point error gets set. also you might want to make
>> >>
>> >> "est: cpu_vendor %s, msr %0jx\n", cpu_vendor, msr);
>> >>
>> >> non-conditional. maybe the output differy in kernel/module mode.
>> >>
>> >> cheers.
>> >> alex
>> >>
>> >>>
>> >>> Tested on a Pentium E5200 desktop (i386) and a Pentium T4200 laptop
>> >>> (amd64). Both got the same result. dmesg of T4200 attached.
>> >>>
>> >>> kldload module:
>> >>> ----->8----->8----->8-----
>> >>> est0: <Enhanced SpeedStep Frequency Control> on cpu0
>> >>> est: CPU supports Enhanced Speedstep, but is not recognized.
>> >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a
>> >>> device_attach: est0 attach returned 6
>> >>> est1: <Enhanced SpeedStep Frequency Control> on cpu1
>> >>> est: CPU supports Enhanced Speedstep, but is not recognized.
>> >>> est: cpu_vendor GenuineIntel, msr 6194c1a06004c1a
>> >>> -----8<-----8<-----8<-----
>> >>> (repeated 6 times, kldload retries?)
>> >>>
>> >>> compiled into kernel:
>> >>> ----->8----->8----->8-----
>> >>> ...
>> >>> fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
>> >>> uart1: <ns8250> failed to probe at port 0x2f8-0x2ff irq 3 on isa0
>> >>> isa_probe_children: probing PnP devices
>> >>> coretemp0: <CPU On-Die Thermal Sensors> on cpu0
>> >>> coretemp0: Setting TjMax=104
>> >>> p4tcc0: <CPU Frequency Thermal Control> on cpu0
>> >>> est0: <Enhanced SpeedStep Frequency Control> on cpu0
>> >>> coretemp1: <CPU On-Die Thermal Sensors> on cpu1
>> >>> coretemp1: Setting TjMax=104
>> >>> p4tcc1: <CPU Frequency Thermal Control> on cpu1
>> >>> est1: <Enhanced SpeedStep Frequency Control> on cpu1
>> >>> Device configuration finished.
>> >>> procfs registered
>> >>> ...
>> >>> -----8<-----8<-----8<-----
>> >>>
>> >>> Jia-Shiun.
>> >>
>> >>
>> >> --
>> >> a13x
>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cpufreq-module.patch
Type: application/octet-stream
Size: 5106 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20130704/b9496532/attachment.obj>

More information about the freebsd-hackers mailing list