Most recent kernel where this bug did *NOT* occur: none Distribution: Ubuntu, Centos, Fedora Hardware Environment: HP ML110 G4, Xeon 3040, 4GB RAM, newest available BIOS Software Environment: no self-compiled tools, only the kernel Problem Description: CPU Scaling isn't working When I am trying to load the acpi_cpufreq module i get FATAL: Error inserting acpi_cpufreq (...): No such device Also in the dmesg out i found the following line twice: ACPI Exception (acpi_processor-0677): AE_NOT_FOUND, Processor Device is not present [20060707] Steps to reproduce: Load acpi_cpufreq kernel module.
Created attachment 11643 [details] cat /proc/cpuinfo
Created attachment 11644 [details] acpidump output
Created attachment 11645 [details] DSDT disassembled with iasl
Created attachment 11646 [details] dmesg output
Created attachment 11647 [details] lspci output
Hi, Marc, Neither processor c-state nor p-state is supported on your platform. IMO, as Xeon is designed for servers, it's reasonable that Xeon doesn't have too much ACPI support. But I can't promise it's right. :p Len and Venki, could you confirm on it please? :)
It doesn't appear that this is a regression in 2.6.22-rc3 Indeed, the dmesg attached is from 2.6.20: Linux version 2.6.20-15-generic (root@yellow) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Sun Apr 15 06:17:24 UTC 2007 (Ubuntu 2.6.20-15.27-generic) The root-cause appears to be that this system doesn't support P-states. Curiously, the spec on intel.com for the Xeon 3040 advertises Enhanced Intel Speedstep
Created attachment 11687 [details] dmesg output Sorry! I mixed up the logs from the original kernel with the ones from my custom kernl.
In the BIOS SETUP i have enabled an option called "Enhanced SpeedStep Technology".
Thanks for the latest dmesg ACPI Exception (processor_core-0781): AE_NOT_FOUND, Processor Device is not present [20070126] This doesn't change the disposition of this bug, however. It appears that this has never worked with any version of Linux, and so this one shouldn't be on the 2.6.22 regression list. > an option called "Enhanced SpeedStep Technology". I assume that this was always enabled, including when you captured the acpidump and the dmesg? Can you check for a BIOS upgrade? Please paste the contents of /proc/cpuinfo
Created attachment 11688 [details] cat /proc/cpuinfo I already installed the latest bios and the speedstep option has always been enabled. Somehow i think that it also could be a bios bug but i am not sure about that. cat /proc/cpuinfo returns the following: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU 3040 @ 1.86GHz stepping : 2 cpu MHz : 1862.039 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips : 3727.03 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: (same for second core)
Created attachment 11706 [details] return 1 if processor exists while it doesn't have an _STA method Hi, Marc, I think the problem is that P-state is not supported on your platform. At the same time, cprfreq driver should not show out "ACPI Exception (acpi_processor-0677): AE_NOT_FOUND, Processor Device is not present [20060707]". Would you please try this patch please? :)
Created attachment 11715 [details] dmesg output for rc4 Hi, Rui, i have attached a new output from dmesg under rc4 using your patch. Unfortunately the acpi exception still shows up.
Created attachment 11726 [details] dmesg from 2.6.22-rc4
Created attachment 11727 [details] acpidump from L1N64-SLI WS MB and 2.6.22-rc4
Having the same problem. This system is using ASUS's 1207FX MB. I have 1 dual core CPU installed. The MB packaging does claim to support AMD's CoolNQuiet tech. Checked the BIOS and everything seems to be in order. Let me know if you would like me to test anything.
Created attachment 11737 [details] Debug patch >i have attached a new output from dmesg under rc4 using your patch. >Unfortunately the acpi exception still shows up. Well, this is really weird. Marc, would you please try this odditional debug patch? Christopher: Seems to be the same problem, processor device doesn't have an _STA method. Please try the patch in comment #12.
Created attachment 11850 [details] dmesg output with debug patch Sorry for the late reply. The latest dmesg output shows this: [ 53.726054] ACPI processor: status is 5 [ 53.726066] ACPI processor: status is 5
I have the same problem with a Core2 Duo processor. on windows is cpu scaling is ok. so bios is ok (last installed) on linux, it worked in the past but with 2.6.21 and .22 doesn't.
for me reset to default bios values and re configure fixed the issue with linux kernel.
Created attachment 12047 [details] return 1 if processor exists while it doesn't have an _STA object Len, I think this patch should go upstream.
Patch works so far (exceptions are gone), but acpi-cpufreq is still unloadable.
re #16: Hi Christopher, I don't know how AMD CoolNQuiet works, but it seems to require the cpufreq driver support. Please recompile your kernel with CONFIG_ACPI_DEBUG=y CONFIG_CPU_FREQ_DEBUG=y. Boot with acpi.debug_level=0x1f cpufreq.debug=7 and attach the dmesg output please. Thanks, Rui
Hi, Patrizio Will you please upload the acpidump info ? And please confirm whether the cpu scaling frequency is enabled in the kernel configuration. Thanks.
Hi, Marc thanks for your info. From the above info there are two sides about your system. 1. CPUfreq module can' work. What Rui and Len said is very right. From the acpidump we can know that c-states and p-states can't be supported on your system. Scope (_PR) { Processor (CPU0, 0x00, 0x00001010, 0x06) {} Processor (CPU1, 0x01, 0x00001010, 0x06) {} Processor (CPU2, 0x02, 0x00001010, 0x06) {} Processor (CPU3, 0x03, 0x00001010, 0x06) {} } There are no definitions of C-states(CST,CSD) and P-states(PSS). In the initialization of cpufreq module the cpufreq will check whether P-state is supported. If the check fails , the cpufreq can't be loaded. Unfortunately there is no definiton of P-states, so the cpufreq module can't be loaded. Will you please update the bios ? Maybe the latest bios has solved this problem. 2. AE_NOT_FOUND message (this error message should be ignored.) Four cpus are defined in the DSDT table. And Two cpus are defined and eanbled in the APIC table. In the initialization the system will check whether the cpu defined in DSDT table exists. If it exists it will attch the cpu to the driver of acpi_process_driver. There are two steps to check whether CPU exists. A. check whether the cpu is defined and enabled in the APIC table. B. check whether the cpu is hotplugged using the _STA method of CPU, which is defined in the DSDT table. Because there is no detailed info about CPU in the DSDT table, the system will report the error message of AE_NOT_FOUND. Please ignore the info. It has no effect on your system.
Hi, Christopher From the acpidump it seems that P-state is supported on your CPU. Will you please enable the debug function of acpi and cpufreq in the kernel configuration? Please try to boot the system with boot option of apic=debug initcall_debug and upload the following files. a. dmesg b. more /proc/cpuinfo c. more /proc/acpi/processor/CPU0/performance d. .config Thanks.
Created attachment 12998 [details] acpi dump
attached my acpi dump /usr/sbin/acpidump -o dump Wrong checksum for generic table! scary error! i have the latest bios for my Asus P5B Deluxe
Hi, Patrizio Please ignore the wrong checksum in the comment #28. Will you please get the info using the following commands? ./acpidump --addr 0x7ff9e0c0 --length 0x1c6 -o cpu1ist ./acpidump --addr 0x7ff9e290 --length 0x13a -o cpu2ist Thanks.
root@blight patrizio # acpidump --addr 0x7ff9e0c0 --length 0x1c6 -o cpu1ist root@blight patrizio # acpidump --addr 0x7ff9e290 --length 0x13a -o cpu2ist root@blight patrizio # seems empty.....
Hi, Patrizio There is no defintion in the DSDT table and it should be loaded dynamically from the address of 0x7ff9e0c0 /0x7ff9e290. But unfortunately it is empty at the address of 0x7ff9e0c0/0x7ff9e290 . So the cpu scaling can't work . Please try it using the latest stable kernel and upload the following the info. a. dmesg b. acpidump info (had better use the latest acpidump tool and it can found on http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20070714-debugs.tar.gz) Thanks.
i will try with 2.6.23 however cpu scaling is working for me...
(In reply to comment #32) > i will try with 2.6.23 > > however cpu scaling is working for me... Please upload the acpidump info using the acpidump tools. http://www.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools-20070714-debug.tar.gz Thanks.
Created attachment 13114 [details] acpi dump
Created attachment 13115 [details] cpu1ist
Created attachment 13116 [details] cpu2ist
i added the 2 cpu dumps and the acpi dump as requested. with new acpidump i get 2 warnings. and dmesg shows ACPI Warning (tbutils-0217): Incorrect checksum in table [OEMB] - E5, should be DC [20070126] should i report to asus? can i override by using a custom acpi table?
Thanks for the info. Please report this problem to ASUS. (The OEMB table has some problems). From the acpidump it seems that P-stats is supported on your system. Can you confirm whether CPU scaling works in linux? Thanks.
yes it's working perfectly now.
The patch in comment #21 looks right to me for making this message go away when it should -- has anybody tested it?
*** Bug 8630 has been marked as a duplicate of this bug. ***
patch in comment #21 applied to acpi test
Thanks for the patch. However when I tried to OC the CPU by increasing the FSB, cpufreq (patched) immediately stopped working (No such device). Kernel 2.6.23.13. Mobo/CPU/arch is GA-P35-DS3R/Q6600/x86_64. I suppose you guys don't want to hear about the details, but if you do, I can upload related info.
Hi, bessel Will you please open a new bug and attach the output of acpidump and dmesg? Thanks.
*** Bug 9794 has been marked as a duplicate of this bug. ***
AE_NOT_FOUND message still exists in 2.6.24-rc8. Shouldn't it be deleted if it creates only misunderstanding.
Artem, can you test the patch in comment #21?
Created attachment 14554 [details] patch: ignore non-hot-pluggable processors Many bioses enumerate processor devices that will never exist in this system, ie, they don't exist before system boot and they can not be hot plugged. This patch ignores this kind of device, and only exports debug messages for the processors that support hot plug. Len, I think this is the right proposal for this bug. Please review.
Created attachment 14555 [details] patch: ignore processors that don't support hotplug Add the subject of this patch.
patch from comment #49 is tested on 2.6.24 - everything is fine, no more AE_NOT_FOUND message. @Len, I dind't test patch from comment #21, as both patches do the same.
In which kernel version will the patch from comment #49 be included ? I have seen the AE_NOT_FOUND message appear on two different systems (one server and one desktop system), both with the 2.6.24 and with the 2.6.24.1 kernels.
the patch in comment #21 shipped in Linux-2.6.25-rc1 today it was updated to be the patch in comment #49 in the acpi test tree.
Created attachment 14955 [details] patch vs 2.6.25-rc1 just for the record, here is the incremental patch vs 2.6.25-rc1
Thanks for the update -- I just retested with 2.6.25-rc3, and the AE_NOT_FOUND message indeed does not appear anymore.
incremental patch d0ce46f550ebbd765881e8c48f43b66285d798b0 shipped in 2.6.25-rc5-git4 closed.