Date: Tue, 8 Jan 2013 13:15:59 +0800 From: Jia-Shiun Li <jiashiun@gmail.com> To: Alexander Best <arundel@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: cpufreq not working as module on i386/amd64 Message-ID: <CAHNYxxOCDMzumJS9S9=tmrwdjunrp6wsH5TOgLO6EEU9OAkhaQ@mail.gmail.com> In-Reply-To: <CAHNYxxPZMUMDMBo0tRSSjJZWqDD7BNR7BdadcVfZk5nDHS2c1A@mail.gmail.com> References: <AANLkTi=Ln7f9tWt=OqZa9eZ-ZAVBfQSC-y_=8c-6zwAd@mail.gmail.com> <20110129084125.GA54969@freebsd.org> <CAHNYxxPZMUMDMBo0tRSSjJZWqDD7BNR7BdadcVfZk5nDHS2c1A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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;
}
/*
----->8----->8----->8-----
Jia-Shiun
On Wed, Dec 26, 2012 at 2:10 AM, Jia-Shiun Li <jiashiun@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHNYxxOCDMzumJS9S9=tmrwdjunrp6wsH5TOgLO6EEU9OAkhaQ>