Bug 7880
| Summary: | cpufreq detects wrong frequency on VIA Esther CPU (C7-1500) | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Claas Langbehn (claas) |
| Component: | Power-Processor | Assignee: | Zhang Rui (rui.zhang) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | acpi-bugzilla, davej |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.20-rc5 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
acpidump
debug output as requested by rui.zhang discard invalid element in _PSS package dmesg after applying the petch by rui.zhang contents of /sys/devices/system/cpu/cpu0/cpufreq/ after applying the patch patch-discard-invalid-elements-in-_PSS-package patch with signed-off-by via c3 epia 5000 acpi output, on request of len brown for 2.6.23-rc1 |
||
|
Description
Claas Langbehn
2007-01-24 13:22:41 UTC
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. |