Re: cpufreq not working as module on i386/amd64
On Thu, Jul 4, 2013 at 1:37 PM, Jia-Shiun Li jiash...@gmail.com wrote: 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. I submitted the patch as PR kern/180588. Could anyone help review and get this committed? Thanks, Jia-Shiun. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cpufreq not working as module on i386/amd64
on 04/07/2013 08:37 Jia-Shiun Li said the following: ok anyone can help test and review this patch? I can not bless this change, but I won't argue against it either. My opinion is still that OS should advertise to ACPI the capabilities that it actually has not those that it potentially may have. So I prefer the status quo. I think that this is a minor issue and cpufreq should just be in kernel, and that's it. 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. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cpufreq not working as module on i386/amd64
On Fri, Jul 5, 2013 at 5:00 PM, Andriy Gapon a...@freebsd.org wrote: I can not bless this change, but I won't argue against it either. My opinion is still that OS should advertise to ACPI the capabilities that it actually has not those that it potentially may have. So I prefer the status quo. I think that this is a minor issue and cpufreq should just be in kernel, and that's it. May I know your concern? My understanding is that ACPI may export different interfaces according to _PDC evaluation. I think though ACPI may export more than actually used, as long as nobody is playing with the additional interfaces, there should be no side effects. Or these interfaces may have dependencies or interactions I am not aware of? Flexibility is good as long as it does not introduce too much complexicity. It could have benefit of less compile time, smaller size, less boot up time, etc. Regards, Jia-Shiun. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cpufreq not working as module on i386/amd64
04.07.2013 08:37, Jia-Shiun Li wrote: 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. Works here at AMD X4 750K: # kldload cpufreq Jul 4 16:00:11 ar1l0u kernel: hwpstate0: Cool`n'Quiet 2.0 on cpu0 # sysctl -a | grep cpufreq debug.cpufreq.lowest: 0 debug.cpufreq.verbose: 0 dev.cpufreq.0.%driver: cpufreq dev.cpufreq.0.%parent: cpu0 # kldunload cpufreq Jul 4 16:48:26 ar1l0u kernel: hwpstate0: detached -- Sphinx of black quartz, judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: cpufreq not working as module on i386/amd64
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 kostik...@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 jiash...@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 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
Re: cpufreq not working as module on i386/amd64
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 jiash...@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 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:
Re: cpufreq not working as module on i386/amd64
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 jiash...@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 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
