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 ... @@ -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
Re: cpufreq not working as module on i386/amd64
on 29/01/2011 10:41 Alexander Best said the following: 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. That's a little bit of misinformation. Primarily est uses ACPI interface to do its work. Hardcoded MSR tables are only the last resort mechanism, and indeed those support only a handful of models. -- Andriy Gapon ___ 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
Re: cpufreq not working as module on i386/amd64
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
cpufreq not working as module on i386/amd64
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? 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. ___ 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
