powerd on Gericom Webgine XL not running quite well
Bruno Ducrot
ducrot at poupinou.org
Wed May 3 13:14:25 UTC 2006
On Wed, May 03, 2006 at 09:34:23AM +0200, ales.rom at kabelnet.net wrote:
> Bruno Ducrot pravi:
> >On Fri, Apr 28, 2006 at 07:39:58PM +0000, Ales wrote:
> >>Nate Lawson pravi:
> >>>Ales wrote:
> >>>>Powerd is running, but when it comes to maximum frequency speed it
> >>>stays
> >>>>there. The example of powerd -v is here:
> >>>>
> >>>># powerd -v
> >>>>idle time < 65%, increasing clock speed from 798 MHz to 931 MHz
> >>>>idle time > 90%, decreasing clock speed from 1064 MHz to 997 MHz
> >>>>idle time > 90%, decreasing clock speed from 931 MHz to 864 MHz
> >>>>idle time < 65%, increasing clock speed from 931 MHz to 1064 MHz
> >>>>idle time > 90%, decreasing clock speed from 1197 MHz to 1197 MHz
> >>>>idle time > 90%, decreasing clock speed from 1197 MHz to 1197 MHz
> >>>>idle time > 90%, decreasing clock speed from 1197 MHz to 1197 MHz
> >>>>idle time > 90%, decreasing clock speed from 1197 MHz to 1197 MHz
> >>>>.
> >>>>.
> >>>>.
> >>>>So, it looks that powerd can increase and decrease CPU speed until it
> >>>>reaches maximum. If I manualy change frequency with sysctl, frequency
> >>>>can go down again.
> >>>>
> >>>>sysctl dev.cpu.0.freq=800
> >>>>dev.cpu.0.freq: 1197 -> 798
> >>>>dev.cpu.0.%desc: ACPI CPU
> >>>>dev.cpu.0.%driver: cpu
> >>>>dev.cpu.0.%location: handle=\_PR_.CPU1
> >>>>dev.cpu.0.%pnpinfo: _HID=none _UID=0
> >>>>dev.cpu.0.%parent: acpi0
> >>>>dev.cpu.0.freq: 1197
> >>>>dev.cpu.0.freq_levels: 1197/35004 1197/35004 1197/35004 1197/35004
> >>>>1197/35004 1064/29004 997/25291 931/23595 864/21910 798/20224
> >>>>
> >>>>dev.powernow.0.%desc: PowerNow! K7
> >>>>dev.powernow.0.%driver: powernow
> >>>>dev.powernow.0.%parent: cpu0
> >>>>dev.powernow.0.freq_settings: 1197/35004 1197/35004 1197/35004
> >>>>1197/35004 1197/35004 1064/29004 997/25291 931/23595 864/21910
> >>>>798/20224
> >>>Something is really screwy with your powernow settings. It's
> >>>reporting 5 settings with all the same freq (1197, see above). So
> >>>powerd is decreasing your frequency, it's just decreasing from 1197 to
> >>>1197 (no change).
> >
> >Indeed.
> >
> >>The way to figure this out is to add some debugging prints to the
> >>powernow table detection algorithm to see why this is occurring. Also,
> >>you could try not loading cpufreq.ko and see if acpi_perf gives more
> >>accurate settings. Just make sure acpi is loaded to get acpi_perf.
> >
> >I'm unaware of any athlon systems starting with K7 cores for which
> >acpi_perf alone will work. But since the power comsuption is displayed,
> >I believe powernow will use acpi tables in order to get p-states.
> >I think therefore the AML is a little bogus, more specifically that
> >there is duplicate entries for 1197MHz.
> >
> >If the OP could give an URL to Gericom_Webgine_XL.asl, generated by
> >acpidump -d -t > Gericom_Webgine_XL.asl
> >
> >then I should be able to verify if that statement is true.
> >
> >>
> The file is here: http://www.p-rom.si/Gericom_Webgine_XL.asl
Thanks. As I supposed, there are duplicate entries for the max p-state:
Scope (\_PR)
{
Processor (CPU1, 0x01, 0x00000810, 0x06)
{
...
Name (_PSS, Package (0x0A)
{
Package (0x06)
{
0x000004B0,
0x000088BC,
0x0000007D,
0x0000007D,
0x009C416C,
0x0000016C
},
Package (0x06)
{
0x000004B0,
0x000088BC,
0x0000007D,
0x0000007D,
0x009C416C,
0x0000016C
},
Package (0x06)
{
0x000004B0,
0x000088BC,
0x0000007D,
0x0000007D,
0x009C416C,
0x0000016C
},
This package is duplicated 5 times and correspond to
the max one.
...
...
}
our acpi_perf driver does not handle this situation. I think
this patch (can not compile test, I don't have a FreeBSD
handy ATM) should fix your issue (minus stupid mistake I may
introduce).
>
> As I said in one of my previus messages:
> If I change POWERNOW_MAX_STATES in powernow.c from 16 to 7 (I belive it
> is the number of states on my proc) everything works fine!!! I know it
> is stupid solution, but I do not know anything about C/C++ programming.
> Sorry.
The method CPUFREQ_DRV_SETTINGS() from acpi_perf give
10 p-states, not 7, therefore it failed, and pn_decode_acpi()
fail. Legacy bios tables are used instead of those
given by ACPI via pn_decode_pst() which return only 6
p-states.
You can see the power consuption for each states is "-1"
in that case because I dont know how to compute them.
> dev.powernow.0.freq_settings: 1197/-1 1064/-1 997/-1 931/-1 864/-1 798/-1
>
> Another thing. I belive that 1 frequency here is missing.
> (8,5x133MHz=1133MHz) It should be there because we have FSB=133, multi=6
> to 9 in 0.5 step.
Aparently the bios writer tell you 8.5 multiplier is not supported.
You should always trust the bios writer (ahem) :)
--- src/sys/dev/acpica/acpi_perf.c~ 2006-05-03 14:49:35.000000000 +0200
+++ src/sys/dev/acpica/acpi_perf.c 2006-05-03 14:50:37.000000000 +0200
@@ -299,6 +299,12 @@ acpi_perf_evaluate(device_t dev)
sc->px_states[count].core_freq >= 0xffff)
continue;
+ /* Check for duplicate entries */
+ if (count > 0 &&
+ sc->px_states[count - 1].core_freq ==
+ sc->px_states[count].core_freq)
+ continue;
+
count++;
}
sc->px_count = count;
--
Bruno Ducrot
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
More information about the freebsd-acpi
mailing list