Bug 8570

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.