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 3000 INTL 20051117)
-ACPI: Dynamic OEM Table Load:
-ACPI: SSDT 0 00223 (v01 PmRef Cpu0Ist 3000 INTL 20051117)
ACPI: SSDT 0xbfd8b598 00537 (v01 PmRef Cpu0Cst 3001 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 00537 (v01 PmRef Cpu0Cst 3001 INTL 20051117)
cpu1: Processor \\_PR_.CPU1 (ACPI ID 2) - APIC ID 1
cpu1: ACPI CPU on acpi0
-ACPI: SSDT 0xbfd8ce18 001CF (v01 PmRefApIst 3000 INTL 20051117)
-ACPI: Dynamic OEM Table Load:
-ACPI: SSDT 0 001CF (v01 PmRefApIst 3000 INTL 20051117)
ACPI: SSDT 0xbfd8df18 0008D (v01 PmRefApCst 3000 INTL 20051117)
ACPI: Dynamic OEM Table Load:
ACPI: SSDT 0 0008D (v01 PmRefApCst 3000 INTL 20051117
On Sat, Jan 29, 2011 at 4:41 PM, Alexander Best arun...@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-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org