Re: cpufreq not working as module on i386/amd64

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
...
_at__at_ -158,17 +158,11 _at__at_
 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