Date: Wed, 3 May 2006 15:14:07 +0200 From: Bruno Ducrot <ducrot@poupinou.org> To: ales.rom@kabelnet.net Cc: freebsd-acpi@FreeBSD.org Subject: Re: powerd on Gericom Webgine XL not running quite well Message-ID: <20060503131407.GA31815@poupinou.org> In-Reply-To: <44585CFF.50305@kabelnet.net> References: <44524200.8050504@kabelnet.net> <44525C0B.8090802@root.org> <44526F8E.70502@kabelnet.net> <20060502115433.GD16180@poupinou.org> <44585CFF.50305@kabelnet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 03, 2006 at 09:34:23AM +0200, ales.rom@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060503131407.GA31815>