Bug 7880 - cpufreq detects wrong frequency on VIA Esther CPU (C7-1500)
Summary: cpufreq detects wrong frequency on VIA Esther CPU (C7-1500)
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Processor (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Zhang Rui
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-24 13:22 UTC by Claas Langbehn
Modified: 2008-01-01 12:28 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.20-rc5
Tree: Mainline
Regression: ---


Attachments
acpidump (73.30 KB, text/plain)
2007-01-24 13:33 UTC, Claas Langbehn
Details
debug output as requested by rui.zhang (4.85 KB, text/plain)
2007-01-29 23:19 UTC, Claas Langbehn
Details
discard invalid element in _PSS package (835 bytes, patch)
2007-01-30 03:43 UTC, Zhang Rui
Details | Diff
dmesg after applying the petch by rui.zhang (4.80 KB, text/plain)
2007-01-30 04:00 UTC, Claas Langbehn
Details
contents of /sys/devices/system/cpu/cpu0/cpufreq/ after applying the patch (909 bytes, text/plain)
2007-01-30 04:03 UTC, Claas Langbehn
Details
patch-discard-invalid-elements-in-_PSS-package (901 bytes, patch)
2007-01-30 19:42 UTC, Zhang Rui
Details | Diff
patch with signed-off-by (1.09 KB, patch)
2007-06-06 22:00 UTC, Zhang Rui
Details | Diff
via c3 epia 5000 acpi output, on request of len brown for 2.6.23-rc1 (53 bytes, text/plain)
2007-07-30 18:11 UTC, Danny ter Haar
Details

Description Claas Langbehn 2007-01-24 13:22:41 UTC
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
Comment 1 Claas Langbehn 2007-01-24 13:33:32 UTC
Created attachment 10171 [details]
acpidump
Comment 2 Claas Langbehn 2007-01-28 01:25:17 UTC
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.
Comment 3 Len Brown 2007-01-28 18:25:33 UTC
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.

Comment 4 Claas Langbehn 2007-01-28 23:21:10 UTC
Does that mean, that it is an ACPI bug of the used mainboard/bios?
What do you suggest doing?
Comment 5 Zhang Rui 2007-01-29 01:15:22 UTC
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?
Comment 6 Rafał Bilski 2007-01-29 10:36:29 UTC
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
Comment 7 Zhang Rui 2007-01-29 17:36:03 UTC
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.
Comment 8 Claas Langbehn 2007-01-29 23:19:01 UTC
Created attachment 10226 [details]
debug output as requested by rui.zhang
Comment 9 Zhang Rui 2007-01-30 03:11:33 UTC
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 
Comment 10 Zhang Rui 2007-01-30 03:43:11 UTC
Created attachment 10227 [details]
discard invalid element in _PSS package

Claas, please have a try with this patch. :)
Comment 11 Claas Langbehn 2007-01-30 04:00:28 UTC
Created attachment 10228 [details]
dmesg after applying the petch by rui.zhang
Comment 12 Claas Langbehn 2007-01-30 04:03:59 UTC
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.
Comment 13 Zhang Rui 2007-01-30 19:42:03 UTC
Created attachment 10231 [details]
patch-discard-invalid-elements-in-_PSS-package
Comment 14 Zhang Rui 2007-06-06 22:00:52 UTC
Created attachment 11700 [details]
patch with signed-off-by
Comment 15 Claas Langbehn 2007-06-07 23:11:45 UTC
It's fixed, i close the bug.
Comment 16 Len Brown 2007-07-23 09:41:31 UTC
shipped in 2.6.23-rc1 (and now the bug can rightfully be remain closed)
Comment 17 Danny ter Haar 2007-07-30 18:11:23 UTC
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
Comment 18 Zhang Rui 2007-11-18 18:33:17 UTC
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.
Comment 19 Zhang Rui 2007-11-18 18:40:37 UTC
Oops, it seems that I missed some emails in LKML.
Please ignore the comments #18.
Comment 20 Zhang Rui 2007-11-18 19:13:50 UTC
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.
Comment 21 Len Brown 2008-01-01 12:28:13 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.