Most recent kernel where this bug did *NOT* occur: none known Distribution: Ubuntu Edgy, but the kernel is built from the sources Hardware Environment: VIA EPIA EX mini-ITX system EX15000g Software Environment: Ubuntu Linux 6.10 "Edgy Eft" Problem Description: cpufreq detects the CPU to also have 65.54 GHz! Apart from that, the CPU switches between 800 and 1500 correctly. See this: # cpufreq-info cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to linux@brodo.de, please. analyzing CPU 0: driver: acpi-cpufreq CPUs which need to switch frequency at the same time: 0 hardware limits: 800 MHz - 65.54 GHz available frequency steps: 1.50 GHz, 800 MHz, 65.54 GHz available cpufreq governors: userspace, ondemand, performance current policy: frequency should be within 800 MHz and 1.50 GHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency is 1.50 GHz. Steps to reproduce: # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 65535000 # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 1500000 800000 65535000 ### But this looks good: # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq 1500000 # cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 10 model name : VIA Esther processor 1500MHz stepping : 9 cpu MHz : 800.000 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 pni est rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en bogomips : 1600.96 clflush size : 64 and from the kernel .config: # # CPU Frequency scaling # CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=y CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=m # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # # CPUFreq processor drivers # CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_POWERNOW_K6 is not set # CONFIG_X86_POWERNOW_K7 is not set # CONFIG_X86_POWERNOW_K8 is not set # CONFIG_X86_GX_SUSPMOD is not set # CONFIG_X86_SPEEDSTEP_CENTRINO is not set # CONFIG_X86_SPEEDSTEP_ICH is not set # CONFIG_X86_SPEEDSTEP_SMI is not set # CONFIG_X86_P4_CLOCKMOD is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set # CONFIG_X86_LONGRUN is not set # CONFIG_X86_LONGHAUL is not set many regards, claas
Created attachment 10171 [details] acpidump
I am quoting rafalb from the Viaarena forum (http://forums.viaarena.com/messageview.aspx?catid=32&threadid=76030&forumid=1): I don't think it is ACPI problem. I'm not 100% sure, but executing \_PR_.CPU0._PSS returned only 2 states: [Package] Contains 2 Elements: [Package] Contains 6 Elements: [Integer] = 00000000000005DC = 1500MHz [Integer] = 0000000000003A98 = 15000mW [Integer] = 000000000000000A = 10us [Integer] = 000000000000000A = 10us [Integer] = 00000000000000B0 [Integer] = 00000000000000B0 [Package] Contains 6 Elements: [Integer] = 0000000000000320 = 800MHz [Integer] = 0000000000001F40 = 8000mW [Integer] = 000000000000000A = 10us [Integer] = 000000000000000A = 10us [Integer] = 00000000000000B1 [Integer] = 00000000000000B1 Looks like a bug in cpufreq driver to me.
65535000 isn't a random number, it is 0xFFFF * 1000 This is curious because... The DSDT has two possible _PSS structures, each with 8 packages, but only the 1st two packages used -- the following 6 are all F's: Name (PPS1, Package (0x02) { Package (0x06) { 0x05DC, 0x3A98, 0x0A, 0x0A, 0x0F13, 0x0F13 }, Package (0x06) { 0x0320, 0x1F40, 0x0A, 0x0A, 0x0810, 0x0810 }, Package (0x06) { 0xFFFF, 0xFFFF, 0xFF, 0xFF, 0xFFFF, 0xFFFF }, and Name (PPS2, Package (0x02) { Package (0x06) { 0x05DC, 0x3A98, 0x0A, 0x0A, 0x00B0, 0x00B0 }, Package (0x06) { 0x0320, 0x1F40, 0x0A, 0x0A, 0x00B1, 0x00B1 }, Package (0x06) { 0xFFFF, 0xFFFF, 0xFF, 0xFF, 0xFFFF, 0xFFFF }, Method (_PSS, 0, NotSerialized) { If (LEqual (PDCT, 0x00)) { Return (PPS2) } Else { Return (PPS1) } } This system has a hard-coded _PPC of 0, which means that PPC will always allow all states that PSS has to be exported. Method (_PPC, 0, NotSerialized) { Return (0x00) } So if there were some bug where the number of packages (2) above did not limit what the kernel saw, then it would pick up an entry for 65535000 KHz.
Does that mean, that it is an ACPI bug of the used mainboard/bios? What do you suggest doing?
Should the cpu-freq driver be able to handle the invalid information from BIOS? Cpu frequences of each elements in _PSS should be a decreasing array , this's why cpu-freq driver treat states[0].core_frequency as the max_freq. Then, should we add some error handling for cpu-freq driver to eliminate the invalid cpu P-state that breaks the rule? E.g. if (states[i].core_frequency > states[i-1].core_frequency) then discard states[i]. Or export some warnings to userspace at least?
What is incorrect here? I see that "Name (PPS1, Package (0x02)" is claiming that it contains only two packages. Why is third, place holder/incorrect, package ever read? states[0].core_frequency is max frequency here. I think that there are two different packages because one is for Centaur C7 with brand C3: 0x00B0, 0x00B0 0x00B1, 0x00B1 And second for Centaur C7 with brand C7 or C7-m or Eden. 0x0F13, = x15.0, 1004mV 0x0F13 0x0810, = x8.0, 956mV 0x0810
Claas: Maybe you can do this test: 1. recompile the kernel with CONFIG_CPU_FREQ_DEBUG=y and CONFIG_ACPI_DEBUG=y 2. remove module acpi_cpufreq after boot 2. #dmesg -c #echo 0x1f >/proc/acpi/debug_level #echo 7 >/sys/module/cpufreq/parameters/debug 3. load module acpi_cpufreq and attach the dmesg output then.
Created attachment 10226 [details] debug output as requested by rui.zhang
First of all, from ACPI spec 17.5.91, I can get "It is an error for NumElements to be less than the number of elements in the PackageList. It is an error for NumElements to exceed 255" , so getting 8 elements from _PSS package seems reaonable. Second, "The _PSS list is sorted in descending order by typical power dissipation. As a result, the zeroth entry describes the highest performance state and the
Created attachment 10227 [details] discard invalid element in _PSS package Claas, please have a try with this patch. :)
Created attachment 10228 [details] dmesg after applying the petch by rui.zhang
Created attachment 10229 [details] contents of /sys/devices/system/cpu/cpu0/cpufreq/ after applying the patch That looks good to me. The 65 GHz have gone, now.
Created attachment 10231 [details] patch-discard-invalid-elements-in-_PSS-package
Created attachment 11700 [details] patch with signed-off-by
It's fixed, i close the bug.
shipped in 2.6.23-rc1 (and now the bug can rightfully be remain closed)
Created attachment 12209 [details] via c3 epia 5000 acpi output, on request of len brown for 2.6.23-rc1 No problems using 2.6.22-git??, 2.6.23-rc1* will crash, posted on LKLM
Hi, Danny, Does the problem still exist with no acpi-cpufreq driver loaded? Can your linux work again by reverting the patch in comment #14? Please set CONFIG_ACPI_DEBUG and CONFIG_CPU_FREQ_DEBUG and attach the dmesg output with kernel parameter cpufreq.debug=7 acpi.debug_level=0x1f and acpi.debug_layer=0xffff0000. Both in kernel 2.6.22-git?? and 2.6.23-rc1.
Oops, it seems that I missed some emails in LKML. Please ignore the comments #18.
Hi, Danny, It seems that your problem has nothing to do with this bug. Close this bug again and Let's discuss your problem in bug #9061.
just for the record... Danny's DSDT in comment #17 shows that the via c3 box has no ACPI P-state control. Thus, presence or absence of the acpi-cpufreq driver, or a change to that driver, could have no effect on that system.