From owner-freebsd-acpi@FreeBSD.ORG Sun Dec 23 05:13:21 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D86816A419 for ; Sun, 23 Dec 2007 05:13:21 +0000 (UTC) (envelope-from tkgeomap@mac.com) Received: from eastrmpop111.cox.net (eastrmpop111.cox.net [68.230.240.53]) by mx1.freebsd.org (Postfix) with ESMTP id E4BEA13C43E for ; Sun, 23 Dec 2007 05:13:20 +0000 (UTC) (envelope-from tkgeomap@mac.com) Received: from eastrmimpo02.cox.net ([68.1.16.120]) by eastrmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20071223045105.BMWW23675.eastrmmtao104.cox.net@eastrmimpo02.cox.net> for ; Sat, 22 Dec 2007 23:51:05 -0500 Received: from localhost.my.domain ([68.97.41.207]) by eastrmimpo02.cox.net with bizsmtp id U4qe1Y00F4UAjD80000000; Sat, 22 Dec 2007 23:50:39 -0500 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.14.2/8.14.2) with ESMTP id lBN4p91A086152 for ; Sat, 22 Dec 2007 22:51:09 -0600 (CST) (envelope-from tkgeomap@mac.com) Received: (from tkgeomap@localhost) by localhost.my.domain (8.14.2/8.14.2/Submit) id lBN4p93o086151 for freebsd-acpi@freebsd.org; Sat, 22 Dec 2007 22:51:09 -0600 (CST) (envelope-from tkgeomap@mac.com) X-Authentication-Warning: localhost.my.domain: tkgeomap set sender to tkgeomap@mac.com using -f Date: Sat, 22 Dec 2007 22:51:09 -0600 From: Gordon work To: freebsd-acpi@freebsd.org Message-ID: <20071223045109.GA86130@localhost.ok.cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: No acpi.thermal on ASUS M2A-VM HDMI X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 05:13:21 -0000 Hi all, I have an ASUS M2A-VM HDMI motherboard running the latest BIOS. All power management features, in particular AMD "Cool and Quiet" and Q-Fan control are enabled, but the system seems oblivious to temperature and the fans always runs at the same (noisy) speed. The temperature is always given as 40C, which I have read elsewhere is a default value. I would like to control the fan speed. I am not concerned with other ACPI features. Does anyone happen to know of any kernel or APM tweaks that might get ACPI thermal working on this board? System particulars follow: % uname -a FreeBSD localhost 7.0-BETA3 FreeBSD 7.0-BETA3 #4: Sun Dec 16 12:45:34 CST 2007 root@localhost:/usr/obj/usr/src/sys/CUSTOM amd64 % kldstat Id Refs Address Size Name 1 5 0xffffffff80100000 7600d8 kernel 2 1 0xffffffff80861000 1a570 snd_hda.ko 3 2 0xffffffff8087c000 673b8 sound.ko 4 1 0xffffffff808e4000 5fd0 acpi_asus.ko % sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 40.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 73.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 75.0C hw.acpi.thermal.tz0._ACx: 73.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > Verbose dmesg output is at: http://tkgeomap.org/acpi/dmesg.boot acpidump -dt output is at: http://tkgeomap.org/acpi/acpidump.out Thanks in advance! Gordon in Oklahoma From owner-freebsd-acpi@FreeBSD.ORG Sun Dec 23 16:30:54 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AA2C16A417 for ; Sun, 23 Dec 2007 16:30:54 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by mx1.freebsd.org (Postfix) with ESMTP id 9D51B13C4CE for ; Sun, 23 Dec 2007 16:30:53 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so1829543fka.11 for ; Sun, 23 Dec 2007 08:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:subject:content-type:from; bh=8eorWfvOVjoK7Qg37Lk4CsSZIP1NmuqA38jWQkqZCeE=; b=Gdj3n97CRE9zNs9lcP96tOZjLD3TMnkJjfDnf9Zz1SowfB8GZOPHQH+BzqEtbwsBq5xd1vXFa1muy0+QgMrXJCLCbHrpS2HzjxYWDW6A3poAAYduzhMiPgLsfBUEpom/QNpxxrRPiBWQQ6+BfTFTS5XY+bWonV3HIb3jeeyrAIk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:subject:content-type:from; b=HjGbPpTL6DPe5yK33Lppd5Dgq/dSxMlcvfBItF5fO9X1NcLexj1kkYrxZgx7SKNuXNfE8tcV8pl2Roq5bsgiwosuIl0j+v9XIf6h2p+2qPEh8u0BlUWQonzbXQzVQujK/c5BHEXaaDJKJL+FUDy51xQz7bQPtMwnPcaBk0Ui8wU= Received: by 10.78.204.20 with SMTP id b20mr4441170hug.33.1198425775462; Sun, 23 Dec 2007 08:02:55 -0800 (PST) Received: from beastie.lan ( [195.60.174.21]) by mx.google.com with ESMTPS id g17sm3040055nfd.10.2007.12.23.08.02.52 (version=SSLv3 cipher=RC4-MD5); Sun, 23 Dec 2007 08:02:54 -0800 (PST) Message-ID: <476E8674.5000303@gmail.com> Date: Sun, 23 Dec 2007 18:01:56 +0200 User-Agent: Thunderbird 2.0.0.9 (X11/20071129) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org Content-Type: multipart/mixed; boundary="------------050801090600030805090806" From: Andrey Cc: Subject: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 16:30:54 -0000 This is a multi-part message in MIME format. --------------050801090600030805090806 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Good time of the day. I've noticed that powerd isn't able to decrease CPU frequency on my laptop (HP Compaq 6710b) as soon as frequency gets highest level. I've pottered a bit in the sources and it seems found the root of the issue. So those who are interested in the subject let consider it. For instance my system reports the following frequency levels: [silent@beastie][/home/silent]sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2001/35000 2000/35000 1750/30625 1600/25000 1400/21875 1200/16000 1050/14000 900/12000 800/14000 700/12250 600/10500 500/8750 400/7000 300/5250 If I try to adjust current frequency to 2000 MHz then I'll get: [silent@beastie][/home/silent]sudo sysctl dev.cpu.0.freq=2000 dev.cpu.0.freq: 300 -> 2001 Let check: [silent@beastie][/home/silent]sysctl dev.cpu.0.freq dev.cpu.0.freq: 2001 Thus, as you can see, I have level "2000" which system reports me but actually I can't to adjust those one exactly because it silently becomes "2001" Well... If I'm not mistaken powerd calculates the current "CPU idle mark" and if it is more then adopted value (by default 90%) then it shifts CPU frequency value 1 step down. In my case powerd sticks at "2001". It is obvious because when powerd decreases CPU frequency from the highest frequency level we'll get the following scenario: +-----------------------+ | dev.cpu.0.freq=2001 +--<-+ +-----------+-----------+ | | | Y | +-----------+-----------+ | | "CPU idle" > 90% | | +-----------+-----------+ | | | Y ^ +-----------+-----------+ ^ | powerd shifts freq. | ^ | 1 step down: | | | "2001" -> "2000" | | +-----------+-----------+ | | | Y | +-----------+-----------+ | | actually we have here | | | dev.cpu.0.freq == 2001+-->-+ +-----------------------+ According to the things mentioned above I've came to conclusion that in my case it is not a good idea to rely on frequency levels reported by the system. (Also I saw many sysctl mibs (dev.cpu.0.freq) of many other people. And there were "strange" frequency levels like "2000" and "2001". Of course I can't state that their systems' behaviors fit my case. But still...) So the simple way out I see is to teach powerd recognize "fake" frequency levels. Here I suggest a very simple workaround (and may be quite ugly... sorry I'm not sure if it is my cup of tee) which allows me to overcome the issue. And I hope it can be useful for smb. else. Also I'd like to hear opinions of others. May be there exists another and simpler way to overcome an issue or even I've missed something or not aware of something. Thank you. -- Sincerely, Andrey Kosachenko --------------050801090600030805090806 Content-Type: text/plain; name="powerd.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="powerd.c.diff" --- /usr/src/usr.sbin/powerd/powerd.c 2007-06-13 22:05:11.000000000 +0300 +++ /home/silent/Data/powerd/powerd.c 2007-12-23 16:52:50.000000000 +0200 @@ -79,6 +79,8 @@ static int read_usage_times(long *idle, long *total); static int read_freqs(int *numfreqs, int **freqs, int **power); +static int reduct_freqs(int *numfreqs, int **freqs, int **power); +static int get_freq(void); static int set_freq(int freq); static void acline_init(void); static void acline_read(void); @@ -189,6 +191,68 @@ return (0); } + +static int +reduct_freqs(int *numfreqs, int **freqs, int **power) +{ + int i = 0; + int k = 0; + int curfreq = 0; + int mem_frequency = get_freq(); + for (i = 0; i < *numfreqs; i++) { + if (vflag) { + printf("Checking frequency %5d - ", (*freqs)[i]); + } + + if (set_freq((*freqs)[i]) == 0) { + curfreq = get_freq(); + if (curfreq > 0 && curfreq == (*freqs)[i]) { + if (vflag) { + printf("[ OK ]\n"); + } + } + else { + if (vflag) { + printf("[FAIL] -> excluding frequency from levels list\n"); + } + + --(*numfreqs); + for (k = i; k < (*numfreqs); k++) { + (*freqs)[k] = (*freqs)[k + 1]; + (*power)[k] = (*power)[k + 1]; + } + + (*freqs)[(*numfreqs)] = 0; + (*power)[(*numfreqs)] = 0; + } + } + } + + if (mem_frequency > 0) { + set_freq(mem_frequency); + } + + return (0); +} + + +static int +get_freq(void) +{ + int curfreq = 0; + size_t len; + + len = sizeof(curfreq); + if (sysctl(freq_mib, 4, &curfreq, &len, NULL, 0) != 0) { + if (vflag) + warn("error reading current CPU frequency"); + return 0; + } + + return (curfreq); +} + + static int set_freq(int freq) { @@ -452,7 +516,11 @@ err(1, "read_usage_times"); if (read_freqs(&numfreqs, &freqs, &mwatts)) err(1, "error reading supported CPU frequencies"); - + + if (reduct_freqs(&numfreqs, &freqs, &mwatts) != 0) { + warn("cannot exclude lame frequencies from list"); + } + /* Run in the background unless in verbose mode. */ if (!vflag) { pid_t otherpid; --------------050801090600030805090806-- From owner-freebsd-acpi@FreeBSD.ORG Sun Dec 23 17:21:27 2007 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA6F116A417; Sun, 23 Dec 2007 17:21:27 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A3E1E13C467; Sun, 23 Dec 2007 17:21:27 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBNHLRpX067381; Sun, 23 Dec 2007 17:21:27 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lBNHLREh067377; Sun, 23 Dec 2007 17:21:27 GMT (envelope-from remko) Date: Sun, 23 Dec 2007 17:21:27 GMT Message-Id: <200712231721.lBNHLREh067377@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-acpi@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: bin/118973: [acpi]: Kernel panic with acpi boot X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 17:21:27 -0000 Old Synopsis: Kernel panic with acpi boot New Synopsis: [acpi]: Kernel panic with acpi boot Responsible-Changed-From-To: freebsd-i386->freebsd-acpi Responsible-Changed-By: remko Responsible-Changed-When: Sun Dec 23 17:21:06 UTC 2007 Responsible-Changed-Why: reassign to acpi group http://www.freebsd.org/cgi/query-pr.cgi?pr=118973 From owner-freebsd-acpi@FreeBSD.ORG Sun Dec 23 18:07:48 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B68216A418 for ; Sun, 23 Dec 2007 18:07:48 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.231]) by mx1.freebsd.org (Postfix) with ESMTP id 24BBC13C457 for ; Sun, 23 Dec 2007 18:07:47 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by hu-out-0506.google.com with SMTP id 28so1675273hub.8 for ; Sun, 23 Dec 2007 10:07:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; bh=Vitkww5pKzE7Zitl7dxjO05plFH5Kf4z6Lpu/lZgjyk=; b=Yzegc7fzod4SicdmrMacKBYi2o7T4e4j2sUXX3Dyow7BUwtR3wNCgpb2MMGO00fQz2J9+bQ4Il+AGithmB50d6zKmcxVTBq97Ky6iiy7xzKmy8MZPbYTewbkwnEYrvyj0KuGl01y3D5cCpW1PeEzYj8ubN0v1vlYvg5I5Pmau/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; b=rQw0YpiJV5jsFMfnLhukGqn8UB+ph0Z7Ju+p65ZlWtvKdnqGjWhY0o122mYiv75VVpWPqg6CrtXxqMHHvPnBFIwGy89F6FaDM9AxQDf2JREpgtm2T2q9/33ja2V/xf0E15r0gsFw8M+gwOQco2JsfZ5NPVFM7ef4olH3La2l0Iw= Received: by 10.82.181.7 with SMTP id d7mr6632208buf.8.1198432289263; Sun, 23 Dec 2007 09:51:29 -0800 (PST) Received: from epsilon.local.gmail.com ( [83.144.140.64]) by mx.google.com with ESMTPS id z34sm5248479ikz.8.2007.12.23.09.51.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 23 Dec 2007 09:51:28 -0800 (PST) Date: Sun, 23 Dec 2007 17:50:57 +0000 Message-ID: <86sl1tl2pq.wl%rpaulo@fnop.net> From: Rui Paulo To: Andrey In-Reply-To: <476E8674.5000303@gmail.com> References: <476E8674.5000303@gmail.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: Rui Cc: freebsd-acpi@FreeBSD.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 18:07:48 -0000 At Sun, 23 Dec 2007 18:01:56 +0200, Andrey wrote: > > Good time of the day. > > I've noticed that powerd isn't able to decrease CPU frequency on my > laptop (HP Compaq 6710b) as soon as frequency gets highest level. > > I've pottered a bit in the sources and it seems found the root of the issue. > So those who are interested in the subject let consider it. > > For instance my system reports the following frequency levels: > > [silent@beastie][/home/silent]sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 2001/35000 2000/35000 1750/30625 1600/25000 > 1400/21875 1200/16000 1050/14000 900/12000 800/14000 700/12250 600/10500 > 500/8750 400/7000 300/5250 > > If I try to adjust current frequency to 2000 MHz then I'll get: > [silent@beastie][/home/silent]sudo sysctl dev.cpu.0.freq=2000 > dev.cpu.0.freq: 300 -> 2001 > Let check: > [silent@beastie][/home/silent]sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2001 > > Thus, as you can see, I have level "2000" which system reports me but > actually I can't to adjust those one exactly because it silently becomes > "2001" > > Well... If I'm not mistaken powerd calculates the current "CPU idle > mark" and if it is more then adopted value (by default 90%) then it > shifts CPU frequency value 1 step down. In my case powerd sticks at > "2001". It is obvious because when powerd decreases CPU frequency from > the highest frequency level we'll get the following scenario: > > +-----------------------+ > | dev.cpu.0.freq=2001 +--<-+ > +-----------+-----------+ | > | | > Y | > +-----------+-----------+ | > | "CPU idle" > 90% | | > +-----------+-----------+ | > | | > Y ^ > +-----------+-----------+ ^ > | powerd shifts freq. | ^ > | 1 step down: | | > | "2001" -> "2000" | | > +-----------+-----------+ | > | | > Y | > +-----------+-----------+ | > | actually we have here | | > | dev.cpu.0.freq == 2001+-->-+ > +-----------------------+ > > > According to the things mentioned above I've came to conclusion that in > my case it is not a good idea to rely on frequency levels reported by > the system. (Also I saw many sysctl mibs (dev.cpu.0.freq) of many other > people. And there were "strange" frequency levels like "2000" and > "2001". Of course I can't state that their systems' behaviors fit my > case. But still...) > > So the simple way out I see is to teach powerd recognize "fake" > frequency levels. Here I suggest a very simple workaround (and may be > quite ugly... sorry I'm not sure if it is my cup of tee) which allows me > to overcome the issue. And I hope it can be useful for smb. else. > > Also I'd like to hear opinions of others. May be there exists another > and simpler way to overcome an issue or even I've missed something or > not aware of something. > > > Thank you. > > > -- > Sincerely, > Andrey Kosachenko I think this is all due to the fact that freq_levels mixes p4tcc, est and others. Try adding: hint.p4tcc.0.disabled=1 hint.acpi_throttle.0.disabled=1 to your /boot/loader.conf Regards. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Sun Dec 23 18:20:03 2007 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72D2316A419 for ; Sun, 23 Dec 2007 18:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7476613C4DB for ; Sun, 23 Dec 2007 18:20:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBNIK2Qp006811 for ; Sun, 23 Dec 2007 18:20:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lBNIK2qq006810; Sun, 23 Dec 2007 18:20:02 GMT (envelope-from gnats) Date: Sun, 23 Dec 2007 18:20:02 GMT Message-Id: <200712231820.lBNIK2qq006810@freefall.freebsd.org> To: freebsd-acpi@FreeBSD.org From: Rui Paulo Cc: Subject: Re: i386/118973: Kernel panic with acpi boot X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rui Paulo List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 18:20:03 -0000 The following reply was made to PR bin/118973; it has been noted by GNATS. From: Rui Paulo To: Gabor Molnar Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: i386/118973: Kernel panic with acpi boot Date: Sun, 23 Dec 2007 18:02:45 +0000 At Sun, 23 Dec 2007 17:13:12 GMT, Gabor Molnar wrote: > > > >Number: 118973 > >Category: i386 > >Synopsis: Kernel panic with acpi boot > >Confidential: no > >Severity: critical > >Priority: low > >Responsible: freebsd-i386 > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Sun Dec 23 17:20:01 UTC 2007 > >Closed-Date: > >Last-Modified: > >Originator: Gabor Molnar > >Release: 7.0-BETA4 > >Organization: > >Environment: > >Description: > Kernel panic if I booting the GENERIC kernel with ACPI. > > Here is a picture: > http://195.228.66.5/pic/panic.jpg (Sorry, not good quality, create > with mobile phone) This seems to be a problem with the acpi_hpet driver. Could you please try booting with "hint.acpi_hpet.0.disabled=1" ? This way, you should be able to boot with ACPI enabled. Escape to the boot loader prompt and type: setenv hint.acpi_hpet.0.disabled=1 I believe your hardware must have some problem that's causing a divide-by-zero trap. If possible, could you please provide us a backtrace from where the panic has originated? See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Sun Dec 23 19:48:35 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84C8816A417 for ; Sun, 23 Dec 2007 19:48:35 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: from mu-out-0910.google.com (mu-out-0910.google.com [209.85.134.190]) by mx1.freebsd.org (Postfix) with ESMTP id 21A2113C461 for ; Sun, 23 Dec 2007 19:48:34 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: by mu-out-0910.google.com with SMTP id w9so864171mue.6 for ; Sun, 23 Dec 2007 11:48:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=DxqHGGomOC1DUjxtIX/xWTNa2ZXL8rbVJlHuUoaxj0w=; b=xmYJbUa6T0i3sGy+9psYqV3zwiHFprumr6LdZZmm86GO+8NNrTmgWKH4r/r9scrSoZ4I6lN9T0ot+zPkufLO7H8arZ8sZeUIDMLVvCVVv9WmMy2SAqyA4pFnOjrmgssHkaKkkScu1EYn1uItZkTUFDhvm92pcAJS4r3SVitPaZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=ZJa2MOFyMhhDm+kdnFzRA+NZxd2OLGMtDo6ouB/N4fgxyU68GOPZ4wB/isjcWgMaQfP9Y1kXmxWYVZ65GcvP1TjrpFtDYp+1Wx574stx3mQ2Yp0fJVuqfyUPU9SF6i28erXXjGZ2fvniJR97pWsDrnYlotOOVOgNtwsNADu3wI0= Received: by 10.78.168.1 with SMTP id q1mr4809433hue.76.1198439313589; Sun, 23 Dec 2007 11:48:33 -0800 (PST) Received: from beastie.lan ( [195.60.174.21]) by mx.google.com with ESMTPS id k5sm1957333nfh.18.2007.12.23.11.48.31 (version=SSLv3 cipher=RC4-MD5); Sun, 23 Dec 2007 11:48:32 -0800 (PST) Message-ID: <476EBB54.1080102@gmail.com> Date: Sun, 23 Dec 2007 21:47:32 +0200 User-Agent: Thunderbird 2.0.0.9 (X11/20071129) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org References: <476E8674.5000303@gmail.com> <86sl1tl2pq.wl%rpaulo@fnop.net> In-Reply-To: <86sl1tl2pq.wl%rpaulo@fnop.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Andrey Cc: Rui Paulo Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2007 19:48:35 -0000 Thank you for your opinion :o) I've tried to follow your advice. The only thing I've managed to achieve is cutting range of frequency levels from the bottom. Now I've: # sysctl dev.cpu.0.freq_levels dev.cpu.0.freq_levels: 2001/35000 2000/35000 1600/25000 1200/16000 800/14000 But the issue itself remained. Look, I mean: # sysctl dev.cpu.0.freq=2000 dev.cpu.0.freq: 800 -> 2001 and # sysctl dev.cpu.0.freq dev.cpu.0.freq: 2001 (should be 2000). In order to assure myself completely I moved appart all my modification from powerd.c and recompiled it. Then I had the following picture: # cat /etc/rc.conf | grep powerd powerd_enable="YES" powerd_flags="-a adaptive -b minimum -v" # sysctl dev.cpu.0.freq=1600 dev.cpu.0.freq: 1600 # /etc/rc.d/powerd start idle time > 90%, decreasing clock speed from 1600 MHz to 1200 MHz idle time > 90%, decreasing clock speed from 1200 MHz to 800 MHz .... >> Everything was OK here. >> Then I loaded my laptop a bit (started compilation) .... idle time < 65%, increasing clock speed from 800 MHz to 1600 MHz idle time < 65%, increasing clock speed from 1600 MHz to 2001 MHz .... >> here I aborted compilation .... idle time > 90%, decreasing clock speed from 2001 MHz to 2000 MHz idle time > 90%, decreasing clock speed from 2001 MHz to 2000 MHz idle time > 90%, decreasing clock speed from 2001 MHz to 2000 MHz idle time > 90%, decreasing clock speed from 2001 MHz to 2000 MHz ... and here it stuck forever So, I think the issue should be investigated/discussed further... Rui Paulo wrote: > I think this is all due to the fact that freq_levels mixes p4tcc, est > and others. > Try adding: > > hint.p4tcc.0.disabled=1 > hint.acpi_throttle.0.disabled=1 > > to your /boot/loader.conf > > Regards. > -- > Rui Paulo > > -- Sincerely, Andrey Kosachenko From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 24 09:43:08 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D434116A41B for ; Mon, 24 Dec 2007 09:43:08 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 9D29013C4CE for ; Mon, 24 Dec 2007 09:43:07 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: by mail.geek.sh (Postfix, from userid 1000) id 3DAAA24D29; Mon, 24 Dec 2007 11:15:11 +0200 (SAST) Date: Mon, 24 Dec 2007 11:15:11 +0200 From: Aragon Gouveia To: Andrey Message-ID: <20071224091511.GA25786@phat.za.net> References: <476E8674.5000303@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <476E8674.5000303@gmail.com> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.10-RELEASE-p2 i386 Cc: freebsd-acpi@FreeBSD.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 09:43:08 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I recently experienced the exact same behaviour as you are experiencing. I'm running an HP Pavilion dv2610ei. In my case, dev.cpu.0.freq_levels shows frequencies 2201 and 2200 (2.2 GHz Core2Duo CPU), and setting frequency to 2200 jumps to 2201. This was completely messing with powerd as it does not expect a frequency change to jump to another level. I wrote a powerd patch a while ago which adds a check condition and removes a frequency level if it fails to get set. It's attached. Please feel free to test it and report back. :) Regards, Aragon | By Andrey | [ 2007-12-23 18:31 +0200 ] > Good time of the day. > > I've noticed that powerd isn't able to decrease CPU frequency on my > laptop (HP Compaq 6710b) as soon as frequency gets highest level. > > I've pottered a bit in the sources and it seems found the root of the issue. > So those who are interested in the subject let consider it. > > For instance my system reports the following frequency levels: > > [silent@beastie][/home/silent]sysctl dev.cpu.0.freq_levels > dev.cpu.0.freq_levels: 2001/35000 2000/35000 1750/30625 1600/25000 > 1400/21875 1200/16000 1050/14000 900/12000 800/14000 700/12250 600/10500 > 500/8750 400/7000 300/5250 > > If I try to adjust current frequency to 2000 MHz then I'll get: > [silent@beastie][/home/silent]sudo sysctl dev.cpu.0.freq=2000 > dev.cpu.0.freq: 300 -> 2001 > Let check: > [silent@beastie][/home/silent]sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2001 > > Thus, as you can see, I have level "2000" which system reports me but > actually I can't to adjust those one exactly because it silently becomes > "2001" > > Well... If I'm not mistaken powerd calculates the current "CPU idle > mark" and if it is more then adopted value (by default 90%) then it > shifts CPU frequency value 1 step down. In my case powerd sticks at > "2001". It is obvious because when powerd decreases CPU frequency from > the highest frequency level we'll get the following scenario: > > +-----------------------+ > | dev.cpu.0.freq=2001 +--<-+ > +-----------+-----------+ | > | | > Y | > +-----------+-----------+ | > | "CPU idle" > 90% | | > +-----------+-----------+ | > | | > Y ^ > +-----------+-----------+ ^ > | powerd shifts freq. | ^ > | 1 step down: | | > | "2001" -> "2000" | | > +-----------+-----------+ | > | | > Y | > +-----------+-----------+ | > | actually we have here | | > | dev.cpu.0.freq == 2001+-->-+ > +-----------------------+ > > > According to the things mentioned above I've came to conclusion that in > my case it is not a good idea to rely on frequency levels reported by > the system. (Also I saw many sysctl mibs (dev.cpu.0.freq) of many other > people. And there were "strange" frequency levels like "2000" and > "2001". Of course I can't state that their systems' behaviors fit my > case. But still...) > > So the simple way out I see is to teach powerd recognize "fake" > frequency levels. Here I suggest a very simple workaround (and may be > quite ugly... sorry I'm not sure if it is my cup of tee) which allows me > to overcome the issue. And I hope it can be useful for smb. else. > > Also I'd like to hear opinions of others. May be there exists another > and simpler way to overcome an issue or even I've missed something or > not aware of something. > > > Thank you. > > > -- > Sincerely, > Andrey Kosachenko > --- /usr/src/usr.sbin/powerd/powerd.c 2007-06-13 22:05:11.000000000 +0300 > +++ /home/silent/Data/powerd/powerd.c 2007-12-23 16:52:50.000000000 +0200 > @@ -79,6 +79,8 @@ > > static int read_usage_times(long *idle, long *total); > static int read_freqs(int *numfreqs, int **freqs, int **power); > +static int reduct_freqs(int *numfreqs, int **freqs, int **power); > +static int get_freq(void); > static int set_freq(int freq); > static void acline_init(void); > static void acline_read(void); > @@ -189,6 +191,68 @@ > return (0); > } > > + > +static int > +reduct_freqs(int *numfreqs, int **freqs, int **power) > +{ > + int i = 0; > + int k = 0; > + int curfreq = 0; > + int mem_frequency = get_freq(); > + for (i = 0; i < *numfreqs; i++) { > + if (vflag) { > + printf("Checking frequency %5d - ", (*freqs)[i]); > + } > + > + if (set_freq((*freqs)[i]) == 0) { > + curfreq = get_freq(); > + if (curfreq > 0 && curfreq == (*freqs)[i]) { > + if (vflag) { > + printf("[ OK ]\n"); > + } > + } > + else { > + if (vflag) { > + printf("[FAIL] -> excluding frequency from levels list\n"); > + } > + > + --(*numfreqs); > + for (k = i; k < (*numfreqs); k++) { > + (*freqs)[k] = (*freqs)[k + 1]; > + (*power)[k] = (*power)[k + 1]; > + } > + > + (*freqs)[(*numfreqs)] = 0; > + (*power)[(*numfreqs)] = 0; > + } > + } > + } > + > + if (mem_frequency > 0) { > + set_freq(mem_frequency); > + } > + > + return (0); > +} > + > + > +static int > +get_freq(void) > +{ > + int curfreq = 0; > + size_t len; > + > + len = sizeof(curfreq); > + if (sysctl(freq_mib, 4, &curfreq, &len, NULL, 0) != 0) { > + if (vflag) > + warn("error reading current CPU frequency"); > + return 0; > + } > + > + return (curfreq); > +} > + > + > static int > set_freq(int freq) > { > @@ -452,7 +516,11 @@ > err(1, "read_usage_times"); > if (read_freqs(&numfreqs, &freqs, &mwatts)) > err(1, "error reading supported CPU frequencies"); > - > + > + if (reduct_freqs(&numfreqs, &freqs, &mwatts) != 0) { > + warn("cannot exclude lame frequencies from list"); > + } > + > /* Run in the background unless in verbose mode. */ > if (!vflag) { > pid_t otherpid; > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="powerd-rmfreq.diff" --- powerd.c.orig 2007-06-13 21:05:11.000000000 +0200 +++ powerd.c 2007-11-10 23:59:09.000000000 +0200 @@ -79,6 +79,7 @@ static int read_usage_times(long *idle, long *total); static int read_freqs(int *numfreqs, int **freqs, int **power); +static void rm_freq(int *numfreqs, int rmfreq, int **freqs, int **power); static int set_freq(int freq); static void acline_init(void); static void acline_read(void); @@ -189,6 +190,41 @@ return (0); } +static void +rm_freq(int *numfreqs, int rmfreq, int **freqs, int **power) +{ + int i, j=0, newfreqs[(*numfreqs)-1], newpower[(*numfreqs)-1]; + + if (*numfreqs < 2) { + // nothing more we can do + free(*freqs); + free(*power); + errx(1, "No more CPU frequencies to set"); + } + + for (i=0; i<*numfreqs; i++) { + if (i == rmfreq) continue; + newfreqs[j] = (*freqs)[i]; + newpower[j] = (*power)[i]; + j++; + } + + free(*freqs); + free(*power); + (*numfreqs)--; + if ((*freqs = malloc(*numfreqs * sizeof(int))) == NULL) + err(1, "error removing CPU frequency"); + if ((*power = malloc(*numfreqs * sizeof(int))) == NULL) { + free(*freqs); + err(1, "error removing CPU frequency"); + } + + for (i=0; i<=j; i++) { + (*freqs)[i] = newfreqs[i]; + (*power)[i] = newpower[i]; + } +} + static int set_freq(int freq) { @@ -555,6 +591,13 @@ freqs[numfreqs - 1]); continue; } + if (sysctl(freq_mib, 4, &curfreq, &len, NULL, 0) == 0) { + if (curfreq != freqs[numfreqs-1]) { + if (vflag) + printf("error setting CPU frequency %d, removing from list\n", freqs[numfreqs-1]); + rm_freq(&numfreqs, numfreqs-1, &freqs, &mwatts); + } + } } continue; } @@ -573,6 +616,13 @@ freqs[0]); continue; } + if (sysctl(freq_mib, 4, &curfreq, &len, NULL, 0) == 0) { + if (curfreq != freqs[0]) { + if (vflag) + printf("error setting CPU frequency %d, removing from list\n", freqs[0]); + rm_freq(&numfreqs, 0, &freqs, &mwatts); + } + } } continue; } @@ -605,6 +655,15 @@ if (set_freq(freqs[i])) warn("error setting CPU frequency %d", freqs[i]); + // Check if it actually got set + len = sizeof(curfreq); + if (sysctl(freq_mib, 4, &curfreq, &len, NULL, 0) == 0) { + if (curfreq != freqs[i]) { + if (vflag) + printf("error setting CPU frequency %d, removing from list\n", freqs[i]); + rm_freq(&numfreqs, i, &freqs, &mwatts); + } + } } else if (idle > (total * cpu_idle_mark) / 100 && curfreq > freqs[numfreqs - 1]) { i++; @@ -616,6 +675,15 @@ if (set_freq(freqs[i]) != 0) warn("error setting CPU frequency %d", freqs[i]); + // Check if it actually got set + len = sizeof(curfreq); + if (sysctl(freq_mib, 4, &curfreq, &len, NULL, 0) == 0) { + if (curfreq != freqs[i]) { + if (vflag) + printf("error setting CPU frequency %d, removing from list\n", freqs[i]); + rm_freq(&numfreqs, i, &freqs, &mwatts); + } + } } } free(freqs); --17pEHd4RhPHOinZp-- From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 24 11:06:53 2007 Return-Path: Delivered-To: freebsd-acpi@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC39816A420 for ; Mon, 24 Dec 2007 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D145A13C507 for ; Mon, 24 Dec 2007 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBOB6qmb031842 for ; Mon, 24 Dec 2007 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id lBOB6qYA031838 for freebsd-acpi@FreeBSD.org; Mon, 24 Dec 2007 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Dec 2007 11:06:52 GMT Message-Id: <200712241106.lBOB6qYA031838@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-acpi@FreeBSD.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 11:06:53 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/118973 acpi [acpi]: Kernel panic with acpi boot 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o i386/54756 acpi ACPI suspend/resume problem on CF-W2 laptop o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Armada 1750 s i386/79080 acpi acpi thermal changes freezes HP nx6110 o i386/79081 acpi ACPI suspend/resume not working on HP nx6110 o kern/81000 acpi [apic] Via 8235 sound card worked great with FreeBSD 5 s i386/91748 acpi acpi problem on Acer TravelMare 4652LMi (nvidia panic, o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/104625 acpi ACPI on ASUS A8N-32 SLI/ASUS P4P800 does not show ther o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/114113 acpi [patch] ACPI kernel panic during S3 suspend / resume o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o amd64/115011 acpi ACPI problem ,reboot system down. o kern/116169 acpi [PATCH] acpi_ibm => psm0 not found problem o kern/116939 acpi PCI-to-PCI misconfigured for bus three and can not see o i386/117918 acpi HP dc5750 will only boot with ACPI disabled o kern/118497 acpi [acpi][patch] Incorrectly determined device count in t 18 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/67309 acpi zzz reboot computer (ACPI S3) o i386/69750 acpi Boot without ACPI failed on ASUS L5 o i386/72179 acpi [acpi] [patch] Inconsistent apm(8) output regarding th o kern/73823 acpi [feature request] acpi / power-on by timer support o kern/76950 acpi ACPI wrongly blacklisted on Micron ClientPro 766Xi sys o kern/89411 acpi [acpi] acpiconf bug o kern/97383 acpi Volume buttons on IBM Thinkpad crash system with ACPI o kern/98171 acpi [acpi] ACPI 1304 / 0501 errors on Acer 5024WLMi Laptop o kern/103365 acpi [acpi] acpi poweroff doesn't work with geli device att o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/108017 acpi [acpi]: Acer Aspire 5600 o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/108581 acpi [sysctl] sysctl: hw.acpi.cpu.cx_lowest: Invalid argume o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o bin/109760 acpi [acpi]: [modules] kldunload acpi_video - crash o kern/111591 acpi [acpi] dev.acpi_ibm.0.events returns I/O error (regres o kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/114165 acpi Dell C810 - ACPI problem o kern/114649 acpi [patch][acpi] panic: recursed on non-recursive mutex o kern/114722 acpi [acpi] [patch] Nearly duplicate p-state entries report o kern/117605 acpi [acpi] request for debug.cpufreq.highest 21 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 24 11:07:08 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D858916A4ED for ; Mon, 24 Dec 2007 11:07:08 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4D13E13C474 for ; Mon, 24 Dec 2007 11:07:08 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1474933uge.37 for ; Mon, 24 Dec 2007 03:07:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=MV4GVyCgRFyoUV3q+aonwqx+lU+DxzL9YsoFg+AsRtE=; b=OmCY2vAcO+0GRC6wPRDveoguyAxMpJ946CXzaL895jgOvx7vHY11ISrMRM+G4WSzuZjb7qiYkn948c4WXq0Hqragw3qoKVmUG8tAtFi5xSg7frdD8H9in+9FC25HdQtpCfNojftdkDVeHQTltTnRaJrChMoqxQewMMCzPNDLBhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=Dg9Vefm9e64AfOwGXUHBkwQLZzAsO63ty7lrgg3cmjZRSYPq3sB/fSFNKKjgSNzVcQkIZIKfrt0WnCtn9AtdyWqvzGzsKkUi58gfGhqEpXBB5i079VMat7XrWZcjhGgkWFKXlGWuVwyC/FSBiwcoEEHaYx3Rsz3EUx7EGLUB2Bw= Received: by 10.67.20.3 with SMTP id x3mr2961378ugi.3.1198494427144; Mon, 24 Dec 2007 03:07:07 -0800 (PST) Received: from beastie.lan ( [194.9.14.78]) by mx.google.com with ESMTPS id b35sm19839973ugd.33.2007.12.24.03.07.04 (version=SSLv3 cipher=RC4-MD5); Mon, 24 Dec 2007 03:07:05 -0800 (PST) Message-ID: <476F929E.70006@gmail.com> Date: Mon, 24 Dec 2007 13:06:06 +0200 User-Agent: Thunderbird 2.0.0.9 (X11/20071129) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org References: <476E8674.5000303@gmail.com> <20071224091511.GA25786@phat.za.net> In-Reply-To: <20071224091511.GA25786@phat.za.net> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit From: Andrey Cc: Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 11:07:09 -0000 Hi, Thank you, Aragon. Actually, your patch does the same as mine (but in a different way). Thus we have at least 2 cases so far when the challenge is appeared. But I'm not sure if our solutions are the best way out. And... I believe, that it would be wonderful if Nate Lawson take a look here and evaluate the things we are talking through. Aragon Gouveia wrote: > Hi, > > I recently experienced the exact same behaviour as you are experiencing. > I'm running an HP Pavilion dv2610ei. In my case, dev.cpu.0.freq_levels > shows frequencies 2201 and 2200 (2.2 GHz Core2Duo CPU), and setting > frequency to 2200 jumps to 2201. This was completely messing with powerd as > it does not expect a frequency change to jump to another level. > > I wrote a powerd patch a while ago which adds a check condition and removes > a frequency level if it fails to get set. It's attached. Please feel free > to test it and report back. :) > > > Regards, > Aragon -- Sincerely, Andrey Kosachenko From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 24 11:43:26 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 849E016A419 for ; Mon, 24 Dec 2007 11:43:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 112D413C468 for ; Mon, 24 Dec 2007 11:43:24 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id WAA23354; Mon, 24 Dec 2007 22:43:17 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Mon, 24 Dec 2007 22:43:16 +1100 (EST) From: Ian Smith To: Andrey In-Reply-To: <476F929E.70006@gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 11:43:26 -0000 On Mon, 24 Dec 2007, Andrey wrote: > Hi, > > Thank you, Aragon. > > Actually, your patch does the same as mine (but in a different way). > Thus we have at least 2 cases so far when the challenge is appeared. > > But I'm not sure if our solutions are the best way out. > And... I believe, that it would be wonderful if Nate Lawson take a look > here and evaluate the things we are talking through. I've watched with amazement over the months seeing various problems with machines having such as 2201 and 2200, or 2001 and 2000MHz frequencies. It makes no sense to me at all that manufacturers would bother having a separate frequency just 1MHz higher. It seems ridiculous, and bogus. Just an observation .. Cheers, Ian > Aragon Gouveia wrote: > > Hi, > > > > I recently experienced the exact same behaviour as you are experiencing. > > I'm running an HP Pavilion dv2610ei. In my case, dev.cpu.0.freq_levels > > shows frequencies 2201 and 2200 (2.2 GHz Core2Duo CPU), and setting > > frequency to 2200 jumps to 2201. This was completely messing with powerd as > > it does not expect a frequency change to jump to another level. > > > > I wrote a powerd patch a while ago which adds a check condition and removes > > a frequency level if it fails to get set. It's attached. Please feel free > > to test it and report back. :) > > > > > > Regards, > > Aragon > > -- > Sincerely, > Andrey Kosachenko From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 24 12:21:34 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C930916A41A for ; Mon, 24 Dec 2007 12:21:34 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA0813C461 for ; Mon, 24 Dec 2007 12:21:33 +0000 (UTC) (envelope-from andrey.kosachenko@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1488230uge.37 for ; Mon, 24 Dec 2007 04:21:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; bh=gx8g9KAPHUKeffw5Pu4TN6HL/46/Iyi47EKHzh5of+A=; b=vTcHlhwtEZpQtM9tKe53+21/K+IG7oXl3AfVcPipBcaO3JN+29m7hvGqp01D6k9z280AgLoOBAerFHfPJzaOwQkIZpOigC182VYG/lOoO3hUVBkLy45rKHTD0QI1QlLVfUwUvSUuIkAfZWmUUojTasOB1vylzhQIhkugbFn213I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=GTm0mKIcbs0/MfGYyFKD3ETCSS1gcnRM7CbQbKsjYX697H7+mi23JHDlqUQHnORcdob56uBlSiaA5shj3aGZ4P54BbyRhnN9wDVHo3ps/g60XX20FCEKHPGnF1x9xc5Te/5f9z1HeMK0/SXDxEDvsS6LfrJPusdvQ6V7oOsTbj0= Received: by 10.67.22.14 with SMTP id z14mr3481693ugi.24.1198498893085; Mon, 24 Dec 2007 04:21:33 -0800 (PST) Received: from beastie.lan ( [194.9.14.78]) by mx.google.com with ESMTPS id m1sm20058271uge.85.2007.12.24.04.21.31 (version=SSLv3 cipher=RC4-MD5); Mon, 24 Dec 2007 04:21:32 -0800 (PST) Message-ID: <476FA40F.5070406@gmail.com> Date: Mon, 24 Dec 2007 14:20:31 +0200 User-Agent: Thunderbird 2.0.0.9 (X11/20071129) MIME-Version: 1.0 To: freebsd-acpi@FreeBSD.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From: Andrey Cc: Ian Smith Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 12:21:34 -0000 Yeah, I completely agree with you, Ian. Unfortunately too many things "are taken from the ceiling" in this world :o(. But what's to be done... We have to dial with it and handle it somehow... just to decrease fan noise or to save power or whatever else... Ian Smith wrote: > > I've watched with amazement over the months seeing various problems with > machines having such as 2201 and 2200, or 2001 and 2000MHz frequencies. > > It makes no sense to me at all that manufacturers would bother having a > separate frequency just 1MHz higher. It seems ridiculous, and bogus. > > Just an observation .. > > Cheers, Ian -- Sincerely, Andrey Kosachenko From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 24 12:43:51 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F33D16A417 for ; Mon, 24 Dec 2007 12:43:51 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 1126813C467 for ; Mon, 24 Dec 2007 12:43:50 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so1086395fgg.35 for ; Mon, 24 Dec 2007 04:43:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; bh=T5EvFxTN6Y1SgYUQ+9pg0wpJBjANX/KhlukbPVcYFR0=; b=xXLl+mSuTEGpNb4I0SYJCsl4BqSOoxq4oGhGMoHAIzWB7sisZ30y82GVwATBqpqek68r0nYRlck4VMESvdQk49yjlSplotEv1KK0k6K5c8DY69EbJCwSEfuu0KEZacvW6xNbvJKiNgfsthJmahtM2XMee4KiHRO+XKYmbcMTx48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; b=CkohnT9W/DNmg+I1gnl2ogNvlCjG0qsklgoUeIqBIAPLapoPXGLeYCpRdudZWzjvCk4P/+NyyNAMpToOZw88BlsBqPSg4COvBfz8JWfGP/sXlw3QJeheTfUAFU+OAEWIQf706ryqZUeIyMov2+nsDQazgumYJX5PhNNpaDRcnkA= Received: by 10.82.177.3 with SMTP id z3mr8291372bue.35.1198500229697; Mon, 24 Dec 2007 04:43:49 -0800 (PST) Received: from epsilon.local.gmail.com ( [83.144.140.64]) by mx.google.com with ESMTPS id b36sm6577262ika.2.2007.12.24.04.43.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2007 04:43:48 -0800 (PST) Date: Mon, 24 Dec 2007 12:43:19 +0000 Message-ID: <86hci8mffc.wl%rpaulo@fnop.net> From: Rui Paulo To: Aragon Gouveia In-Reply-To: <20071224091511.GA25786@phat.za.net> References: <476E8674.5000303@gmail.com> <20071224091511.GA25786@phat.za.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: Rui Cc: freebsd-acpi@FreeBSD.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 12:43:51 -0000 At Mon, 24 Dec 2007 11:15:11 +0200, Aragon Gouveia wrote: > > Hi, > > I recently experienced the exact same behaviour as you are experiencing. > I'm running an HP Pavilion dv2610ei. In my case, dev.cpu.0.freq_levels > shows frequencies 2201 and 2200 (2.2 GHz Core2Duo CPU), and setting > frequency to 2200 jumps to 2201. This was completely messing with powerd as > it does not expect a frequency change to jump to another level. > > I wrote a powerd patch a while ago which adds a check condition and removes > a frequency level if it fails to get set. It's attached. Please feel free > to test it and report back. :) Isn't it better to teach est(4) to ignore values that differ in, say, +/- 5Mhz ? -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 24 21:16:57 2007 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E41A16A418 for ; Mon, 24 Dec 2007 21:16:57 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id B81C113C448 for ; Mon, 24 Dec 2007 21:16:56 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: by mail.geek.sh (Postfix, from userid 1000) id CD92E24D29; Mon, 24 Dec 2007 23:16:54 +0200 (SAST) Date: Mon, 24 Dec 2007 23:16:54 +0200 From: Aragon Gouveia To: Rui Paulo Message-ID: <20071224211654.GA64050@phat.za.net> References: <476E8674.5000303@gmail.com> <20071224091511.GA25786@phat.za.net> <86hci8mffc.wl%rpaulo@fnop.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86hci8mffc.wl%rpaulo@fnop.net> User-Agent: Mutt/1.4i X-Operating-System: FreeBSD 4.10-RELEASE-p2 i386 Cc: freebsd-acpi@FreeBSD.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 21:16:57 -0000 Hi, | By Rui Paulo | [ 2007-12-24 14:43 +0200 ] > Isn't it better to teach est(4) to ignore values that differ in, say, > +/- 5Mhz ? I agree my patch isn't ideal. I was thinking about it today and it might be useful to implement something that ignores frequencies whose power ratings don't differ by more than X mW. In my case, both 2201 and 2200 are rated to draw 35000 mW. The question is, in these cases which one of the two should be ignored? Can't ignore both... Sorry Andrey, I missed your patch. Was a bit overly excited when I saw someone else finally experiencing the same problem as me after receiving zero response a month ago when I posted about it. :) Something I asked in my post a month ago was where does dev.cpu.X.freq_levels get its data? I was thinking it might be something that can be addressed with a patched ACPI DSDT? Regards, Aragon From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 24 23:46:23 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 213A616A417 for ; Mon, 24 Dec 2007 23:46:23 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id A484013C448 for ; Mon, 24 Dec 2007 23:46:22 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1598208uge.37 for ; Mon, 24 Dec 2007 15:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; bh=FF5ZywuCTHzDsPFOQc/i6N03ObcVeYgWlmtyBRj0tGo=; b=x2GKE/seeK9HCgtRFzwiuPyalf/kyc+nH+0UCQNGxzIUjCBINICHOin5KWIBkldZ2d2k4WBOf0E8d+Vh2Tyr+HrrOkhjFOa0sdoIrCJJw/mrPcqgAyvcLToSChXR2wQF/H3HgQ8E/bybA4qKLr5+wLVUDhouleHoKwLAc4xCXzI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; b=EpfoKfjriEG3tSq0rFQSV3Kvbw/LjABoK3qj5n2vS9ehQD5tSLRNanPbfNBB0PMVP11zprjGPVWLx4GwWtrWcY/R9VnWZNBEqh0d+WYoFPzPXmpPXA2xzZ/ghSvndegVeXsP5VUIwi1V92FSdn3QFp9cbC2T/AlbVn36ssrC0Kw= Received: by 10.67.30.6 with SMTP id h6mr3783886ugj.6.1198539981220; Mon, 24 Dec 2007 15:46:21 -0800 (PST) Received: from epsilon.local.gmail.com ( [83.144.140.64]) by mx.google.com with ESMTPS id c22sm7481655ika.3.2007.12.24.15.46.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2007 15:46:20 -0800 (PST) Date: Mon, 24 Dec 2007 23:45:46 +0000 Message-ID: <863atrfyhh.wl%rpaulo@fnop.net> From: Rui Paulo To: Aragon Gouveia In-Reply-To: <20071224211654.GA64050@phat.za.net> References: <476E8674.5000303@gmail.com> <20071224091511.GA25786@phat.za.net> <86hci8mffc.wl%rpaulo@fnop.net> <20071224211654.GA64050@phat.za.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: Rui Cc: Rui Paulo , freebsd-acpi@FreeBSD.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Dec 2007 23:46:23 -0000 At Mon, 24 Dec 2007 23:16:54 +0200, Aragon Gouveia wrote: > > Hi, > > | By Rui Paulo > | [ 2007-12-24 14:43 +0200 ] > > Isn't it better to teach est(4) to ignore values that differ in, say, > > +/- 5Mhz ? > > I agree my patch isn't ideal. I was thinking about it today and it might > be useful to implement something that ignores frequencies whose power > ratings don't differ by more than X mW. In my case, both 2201 and 2200 are > rated to draw 35000 mW. The question is, in these cases which one of the > two should be ignored? Can't ignore both... I think you can ignore one of them, which one doesn't really matter because the power levels are the same. I suspect that, in these cases, the 2001 comes after 2000 in the EST table, so if we ignore a value already present, 2000 will remain and 2001 will be ignored. > Sorry Andrey, I missed your patch. Was a bit overly excited when I saw > someone else finally experiencing the same problem as me after receiving > zero response a month ago when I posted about it. :) > > Something I asked in my post a month ago was where does > dev.cpu.X.freq_levels get its data? I was thinking it might be something > that can be addressed with a patched ACPI DSDT? dev.cpu.0.freq_levels is the combiation of several power/speed throttling sources, namely, est(4), acpi_throttle(4), etc. The API that deals with this is cpufreq(8). Regards. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Tue Dec 25 06:17:20 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEB5316A41A for ; Tue, 25 Dec 2007 06:17:20 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA4013C44B for ; Tue, 25 Dec 2007 06:17:18 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id RAA23594; Tue, 25 Dec 2007 17:16:59 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 25 Dec 2007 17:16:58 +1100 (EST) From: Ian Smith To: Rui Paulo In-Reply-To: <863atrfyhh.wl%rpaulo@fnop.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 06:17:20 -0000 On Mon, 24 Dec 2007, Rui Paulo wrote: > At Mon, 24 Dec 2007 23:16:54 +0200, > Aragon Gouveia wrote: > > > > Hi, > > > > | By Rui Paulo > > | [ 2007-12-24 14:43 +0200 ] > > > Isn't it better to teach est(4) to ignore values that differ in, say, > > > +/- 5Mhz ? > > > > I agree my patch isn't ideal. I was thinking about it today and it might > > be useful to implement something that ignores frequencies whose power > > ratings don't differ by more than X mW. In my case, both 2201 and 2200 are > > rated to draw 35000 mW. The question is, in these cases which one of the > > two should be ignored? Can't ignore both... > > I think you can ignore one of them, which one doesn't really matter > because the power levels are the same. I suspect that, in these cases, > the 2001 comes after 2000 in the EST table, so if we ignore a value > already present, 2000 will remain and 2001 will be ignored. I'm starting to wonder if this 2000/2001 thing isn't some sort of signal to a Certain OS to do Something Proprietary. As it makes no engineering sense, best we can do for powerd without Inside Knowledge is what both these patches offer, eliminating/ignoring frequencies that won't set. It seems it does matter which is chosen; Andrey demonstrated in his case that setting 2000 gave 2001 anyway, so the one that reads back wrong when set is the one to ignore. It'd be better to know _why_, though. > > Sorry Andrey, I missed your patch. Was a bit overly excited when I saw > > someone else finally experiencing the same problem as me after receiving > > zero response a month ago when I posted about it. :) > > > > Something I asked in my post a month ago was where does > > dev.cpu.X.freq_levels get its data? I was thinking it might be something > > that can be addressed with a patched ACPI DSDT? > > dev.cpu.0.freq_levels is the combiation of several power/speed > throttling sources, namely, est(4), acpi_throttle(4), etc. The API > that deals with this is cpufreq(8). s/8/4/ Trouble is, there exists no est(4), acpi_throttle(4) nor acpi_perf(4), checked again after seeing your message, up to 8-current. Trying to work out interdependencies and interactions between the various modules and drivers is, as far as I can tell, a matter of studying the code, which I've done a bit at times for interest, but certainly not deeply enough to try documenting, nor even making a decent dependency diagram. cpufreq(4) is about as good as it gets currently, and I gather cpufreq isn't dependent on ACPI as such. I can't find manuals for ANY of these: SUPPORTED DRIVERS The following device drivers offer absolute frequency control via the cpufreq interface. Usually, only one of these can be active at a time. acpi_perf ACPI CPU performance states est Intel Enhanced SpeedStep ichss Intel SpeedStep for ICH powernow AMD PowerNow! for K7 and K8 smist Intel SMI-based SpeedStep for PIIX4 The following device drivers offer relative frequency control and have an additive effect: acpi_throttle ACPI CPU throttling p4tcc Pentium 4 Thermal Control Circuitry Can anyone point to any out-of-band documentation for any of this? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Tue Dec 25 15:55:31 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21C7016A417 for ; Tue, 25 Dec 2007 15:55:31 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id A038D13C46B for ; Tue, 25 Dec 2007 15:55:30 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ug-out-1314.google.com with SMTP id y2so1733064uge.37 for ; Tue, 25 Dec 2007 07:55:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; bh=7qp153qZ40OQMM8Vp8au7xYoP3Du9v8ck7irnFhcZY4=; b=oTursR/BzwYa0xh9+jDDfWdxeGOzCGY9KeDBXkwApRQIY1EW5Jv9JeQr5NR+oDZkJdkRepGTY4HN3VUslDq6PGo8v6AfLsyOyVRRWComYsZkteyrCv/T50EvQofrxuA1QYeZ2KtzhqpyrKLIWOIzcplD/A7ZTPERXiymW38dw/0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:message-id:from:to:cc:subject:in-reply-to:references:user-agent:mime-version:content-type:sender; b=EkKHY8KgGbaJ2/2e25n0MeRZ7B56qAlV9Rl6koUBbpnVhhc1blnZ0uvYtQ+uZ0jub7ShdZFBHj+lHSxJLeIeaN03/4kLDw24o0YjJVXPx6U9m5WeglWZrTLErunV5kCBBrm+CMuh89eJ4LbbAq0msyHTO06741GfCPqekKh1me0= Received: by 10.67.196.4 with SMTP id y4mr4896982ugp.39.1198598129388; Tue, 25 Dec 2007 07:55:29 -0800 (PST) Received: from epsilon.local.gmail.com ( [83.144.140.64]) by mx.google.com with ESMTPS id y34sm8752743iky.6.2007.12.25.07.55.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Dec 2007 07:55:28 -0800 (PST) Date: Tue, 25 Dec 2007 15:54:54 +0000 Message-ID: <86ejdaepm9.wl%rpaulo@fnop.net> From: Rui Paulo To: Ian Smith In-Reply-To: References: <863atrfyhh.wl%rpaulo@fnop.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.1 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: Rui Cc: freebsd-acpi@freebsd.org Subject: Re: powerd doesn't decrease CPU frequency in some cases X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2007 15:55:31 -0000 At Tue, 25 Dec 2007 17:16:58 +1100 (EST), Ian Smith wrote: > > On Mon, 24 Dec 2007, Rui Paulo wrote: > > At Mon, 24 Dec 2007 23:16:54 +0200, > > Aragon Gouveia wrote: > > > > > > Hi, > > > > > > | By Rui Paulo > > > | [ 2007-12-24 14:43 +0200 ] > > > > Isn't it better to teach est(4) to ignore values that differ in, say, > > > > +/- 5Mhz ? > > > > > > I agree my patch isn't ideal. I was thinking about it today and it might > > > be useful to implement something that ignores frequencies whose power > > > ratings don't differ by more than X mW. In my case, both 2201 and 2200 are > > > rated to draw 35000 mW. The question is, in these cases which one of the > > > two should be ignored? Can't ignore both... > > > > I think you can ignore one of them, which one doesn't really matter > > because the power levels are the same. I suspect that, in these cases, > > the 2001 comes after 2000 in the EST table, so if we ignore a value > > already present, 2000 will remain and 2001 will be ignored. > > I'm starting to wonder if this 2000/2001 thing isn't some sort of signal > to a Certain OS to do Something Proprietary. As it makes no engineering > sense, best we can do for powerd without Inside Knowledge is what both > these patches offer, eliminating/ignoring frequencies that won't set. > > It seems it does matter which is chosen; Andrey demonstrated in his case > that setting 2000 gave 2001 anyway, so the one that reads back wrong > when set is the one to ignore. It'd be better to know _why_, > though. Well, the fact that "setting 2000 gave 2001 anyway" is most likely regarding to how est is programmed, I think. > > > Sorry Andrey, I missed your patch. Was a bit overly excited when I saw > > > someone else finally experiencing the same problem as me after receiving > > > zero response a month ago when I posted about it. :) > > > > > > Something I asked in my post a month ago was where does > > > dev.cpu.X.freq_levels get its data? I was thinking it might be something > > > that can be addressed with a patched ACPI DSDT? > > > > dev.cpu.0.freq_levels is the combiation of several power/speed > > throttling sources, namely, est(4), acpi_throttle(4), etc. The API > > that deals with this is cpufreq(8). > > s/8/4/ > > Trouble is, there exists no est(4), acpi_throttle(4) nor acpi_perf(4), > checked again after seeing your message, up to 8-current. Trying to > work out interdependencies and interactions between the various modules > and drivers is, as far as I can tell, a matter of studying the code, > which I've done a bit at times for interest, but certainly not deeply > enough to try documenting, nor even making a decent dependency diagram. > > cpufreq(4) is about as good as it gets currently, and I gather cpufreq > isn't dependent on ACPI as such. I can't find manuals for ANY of these: > > SUPPORTED DRIVERS > The following device drivers offer absolute frequency control via the > cpufreq interface. Usually, only one of these can be active at a time. > > acpi_perf ACPI CPU performance states > est Intel Enhanced SpeedStep > ichss Intel SpeedStep for ICH > powernow AMD PowerNow! for K7 and K8 > smist Intel SMI-based SpeedStep for PIIX4 > > The following device drivers offer relative frequency control and have an > additive effect: > > acpi_throttle ACPI CPU throttling > p4tcc Pentium 4 Thermal Control Circuitry > > Can anyone point to any out-of-band documentation for any of this? There are no man pages for them, I failed to check the man pages properly. Regards. -- Rui Paulo From owner-freebsd-acpi@FreeBSD.ORG Thu Dec 27 22:32:30 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA14616A420 for ; Thu, 27 Dec 2007 22:32:30 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.freebsd.org (Postfix) with ESMTP id 97CFA13C4CE for ; Thu, 27 Dec 2007 22:32:30 +0000 (UTC) (envelope-from nate@root.org) Received: (qmail 47338 invoked from network); 27 Dec 2007 22:32:31 -0000 Received: from adsl-71-141-123-117.dsl.snfc21.pacbell.net (HELO ?192.168.1.77?) (nate-mail@71.141.123.117) by root.org with ESMTPA; 27 Dec 2007 22:32:31 -0000 Message-ID: <477427FA.1060505@root.org> Date: Thu, 27 Dec 2007 14:32:26 -0800 From: Nate Lawson User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Gordon work References: <20071223045109.GA86130@localhost.ok.cox.net> In-Reply-To: <20071223045109.GA86130@localhost.ok.cox.net> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: No acpi.thermal on ASUS M2A-VM HDMI X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 22:32:30 -0000 Gordon work wrote: > Hi all, > > I have an ASUS M2A-VM HDMI motherboard running the latest BIOS. > All power management features, in particular AMD "Cool and Quiet" > and Q-Fan control are enabled, but the system seems oblivious to > temperature and the fans always runs at the same (noisy) speed. > The temperature is always given as 40C, which I have read elsewhere > is a default value. > > I would like to control the fan speed. I am not concerned with other > ACPI features. > > Does anyone happen to know of any kernel or APM tweaks that might get > ACPI thermal working on this board? > > System particulars follow: > > % uname -a > FreeBSD localhost 7.0-BETA3 FreeBSD 7.0-BETA3 #4: Sun Dec 16 12:45:34 CST 2007 root@localhost:/usr/obj/usr/src/sys/CUSTOM amd64 > > % kldstat > Id Refs Address Size Name > 1 5 0xffffffff80100000 7600d8 kernel > 2 1 0xffffffff80861000 1a570 snd_hda.ko > 3 2 0xffffffff8087c000 673b8 sound.ko > 4 1 0xffffffff808e4000 5fd0 acpi_asus.ko > > % sysctl hw.acpi.thermal > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 40.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 1 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: 73.0C > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 75.0C > hw.acpi.thermal.tz0._ACx: 73.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 If it's just returning a fixed value of 40C, you should try an external application that reads the temp directly. For instance, the lmsensors port. The ASL itself has the hardcoded value in it, meaning the BIOS vendor never intended to give ACPI access to the temperature. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Thu Dec 27 23:37:42 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 250AA16A417; Thu, 27 Dec 2007 23:37:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id BC65613C455; Thu, 27 Dec 2007 23:37:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 226288991-1834499 for multiple; Thu, 27 Dec 2007 18:23:50 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lBRNLYYb054103; Thu, 27 Dec 2007 18:21:35 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: acpi@freebsd.org Date: Thu, 27 Dec 2007 14:49:57 -0500 User-Agent: KMail/1.9.6 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712271449.58285.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 27 Dec 2007 18:21:35 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5270/Thu Dec 27 12:48:18 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: njl@freebsd.org Subject: An issue with powerd.. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2007 23:37:42 -0000 So I've had some issues where I get weird hangs when I run with powerd enabled on my laptop and I think I've finally tracked it down. Note that this is on an older current with the older EC code, but the design flaw in powerd is still relevant even if the new EC code makes my laptop happier (I'm trying to update my laptop to more recent HEAD, but there's some weird scheduling bug that I haven't fixed yet in newer stuff). Anyways, I was trying to debug the weird hangs I had when running with powerd (machine would go unresponsive and fans would spin up, and after a variable number of seconds it would come back and all the pending input (mouse movements, keypresses, etc.) would be processed). I added some code to track how long it takes for GPE's to run that would print out on the console if one took more than 750ms as I had a feeling that something with ACPI was making the system busy. It was also far worse in console mode than in X. In console mode I found that sometimes the system would never "come back". So I was running in console mode recently with my timing patches and noticed that when it hung it started warning about GPE events taking several _seconds_ to process, e.g. 2-3 seconds, or in some cases up to _30_ seconds. So, my theory is that powerd has lowered my CPU all the way down to 100mhz (easy to reproduce in non-X, just let the box sit with no apps running) and that for some reason the machine ends up in a "GPE storm" where it is spending all its time handling GPE's and never has any CPU left for userland apps (due to being at 100mhz). The problem then is that powerd never runs to bump my CPU up to some reasonable speed. In fact, anytime a completely idle box suddently gets a lot of kernel work (e.g. a sudden flow of packets) it could in theory end up trying to handle all this work at the reduced speed since the work has a higher priority than the powerd process. To that end, I think that at least part of powerd needs to be in the kernel, or at least that the kernel should be more proactive about bumping the speed up when it resumes from Cx due to an interrupt. A simple policy would be to bump up to full speed for any non-clock interrupt (possibly bumping up for a clock interrupt if we wake up softclock as well). Thoughts? -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 28 02:57:29 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4B7916A419; Fri, 28 Dec 2007 02:57:29 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3EB13C457; Fri, 28 Dec 2007 02:57:26 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id NAA14383; Fri, 28 Dec 2007 13:38:14 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 28 Dec 2007 13:38:13 +1100 (EST) From: Ian Smith To: John Baldwin In-Reply-To: <200712271449.58285.jhb@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: acpi@freebsd.org, njl@freebsd.org Subject: Re: An issue with powerd.. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 02:57:29 -0000 On Thu, 27 Dec 2007, John Baldwin wrote: > So I've had some issues where I get weird hangs when I run with powerd enabled > on my laptop and I think I've finally tracked it down. Note that this is on > an older current with the older EC code, but the design flaw in powerd is > still relevant even if the new EC code makes my laptop happier (I'm trying to > update my laptop to more recent HEAD, but there's some weird scheduling bug > that I haven't fixed yet in newer stuff). > > Anyways, I was trying to debug the weird hangs I had when running with powerd > (machine would go unresponsive and fans would spin up, and after a variable > number of seconds it would come back and all the pending input (mouse > movements, keypresses, etc.) would be processed). I added some code to track > how long it takes for GPE's to run that would print out on the console if one > took more than 750ms as I had a feeling that something with ACPI was making > the system busy. Fans spinning up is perhaps interesting? As noted in my recent whinge about lack of component documentation, I've yet to suss out interactions between acpi_thermal (wrt both fans and passive cooling itself modifying cpu freqs - could this fight with powerd?), devd and other subsystems. Yeah I'm slowly beating through the ACPI spec, up to page 46 of >600 pages, but it's reminiscent of reading govt legislation .. I'd love to find the ~50 page precis, then I may be better able to follow some code. > It was also far worse in console mode than in X. In console mode I found that > sometimes the system would never "come back". Presumably X itself keeps it busy enough to keep cpu freq 'reasonable'? I use gkrellm to keep an eye on cpu freq, temp, load avg .. but my T23 is only a two-speed, min 733MHZ, so I can't see what you're seeing (and that's my faster laptop :) > So I was running in console mode recently with my timing patches and noticed > that when it hung it started warning about GPE events taking several > _seconds_ to process, e.g. 2-3 seconds, or in some cases up to _30_ seconds. > So, my theory is that powerd has lowered my CPU all the way down to 100mhz > (easy to reproduce in non-X, just let the box sit with no apps running) and > that for some reason the machine ends up in a "GPE storm" where it is > spending all its time handling GPE's and never has any CPU left for userland > apps (due to being at 100mhz). The problem then is that powerd never runs to > bump my CPU up to some reasonable speed. One workaround some have noted using is to set debug.cpufreq.lowest to some value considerably higher than 100MHz, say >500MHz to maintain reasonable responsiveness, at a cost of higher power use when idle. > In fact, anytime a completely idle box suddently gets a lot of kernel work > (e.g. a sudden flow of packets) it could in theory end up trying to handle > all this work at the reduced speed since the work has a higher priority than > the powerd process. To that end, I think that at least part of powerd needs > to be in the kernel, or at least that the kernel should be more proactive > about bumping the speed up when it resumes from Cx due to an interrupt. A > simple policy would be to bump up to full speed for any non-clock interrupt > (possibly bumping up for a clock interrupt if we wake up softclock as well). > > Thoughts? Just humble grasshopper droppings, master .. but the default powerd polling interval is 500ms, which is a really long time on a fast box, so -p 100 or even less might make a considerable difference? Can't comment on any in-kernel component, but responding per any sort of single interrupt/s sounds way too triggerhappy compared to monitoring load, assuming that such as vm.loadavg and kern.cp_time are themselves updated promptly in high-stress times? AU$0.02, which rounds down to 0 since we abandoned coins less than 5c .. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 28 17:06:03 2007 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29B3316A419; Fri, 28 Dec 2007 17:06:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 9832F13C47E; Fri, 28 Dec 2007 17:06:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=deviant.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1J8INQ-0007wg-MQ; Fri, 28 Dec 2007 18:48:11 +0200 Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id lBSGm4dk038616; Fri, 28 Dec 2007 18:48:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id lBSGm4DD038615; Fri, 28 Dec 2007 18:48:04 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 28 Dec 2007 18:48:04 +0200 From: Kostik Belousov To: John Baldwin Message-ID: <20071228164804.GU57756@deviant.kiev.zoral.com.ua> References: <200712271449.58285.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WeyQLTZFbZxVv3E0" Content-Disposition: inline In-Reply-To: <200712271449.58285.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Scanner-Signature: 2d4f5d33491be47a8e8639414ad67c6d X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 1973 [Dec 28 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: acpi@freebsd.org, njl@freebsd.org Subject: Re: An issue with powerd.. X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 17:06:03 -0000 --WeyQLTZFbZxVv3E0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 27, 2007 at 02:49:57PM -0500, John Baldwin wrote: > So I've had some issues where I get weird hangs when I run with powerd en= abled=20 > on my laptop and I think I've finally tracked it down. Note that this is= on=20 > an older current with the older EC code, but the design flaw in powerd is= =20 > still relevant even if the new EC code makes my laptop happier (I'm tryin= g to=20 > update my laptop to more recent HEAD, but there's some weird scheduling b= ug=20 > that I haven't fixed yet in newer stuff). >=20 > Anyways, I was trying to debug the weird hangs I had when running with po= werd=20 > (machine would go unresponsive and fans would spin up, and after a variab= le=20 > number of seconds it would come back and all the pending input (mouse=20 > movements, keypresses, etc.) would be processed). I added some code to t= rack=20 > how long it takes for GPE's to run that would print out on the console if= one=20 > took more than 750ms as I had a feeling that something with ACPI was maki= ng=20 > the system busy. >=20 > It was also far worse in console mode than in X. In console mode I found= that=20 > sometimes the system would never "come back". >=20 > So I was running in console mode recently with my timing patches and noti= ced=20 > that when it hung it started warning about GPE events taking several=20 > _seconds_ to process, e.g. 2-3 seconds, or in some cases up to _30_ secon= ds. =20 > So, my theory is that powerd has lowered my CPU all the way down to 100mh= z=20 > (easy to reproduce in non-X, just let the box sit with no apps running) a= nd=20 > that for some reason the machine ends up in a "GPE storm" where it is=20 > spending all its time handling GPE's and never has any CPU left for userl= and=20 > apps (due to being at 100mhz). The problem then is that powerd never run= s to=20 > bump my CPU up to some reasonable speed. >=20 > In fact, anytime a completely idle box suddently gets a lot of kernel wor= k=20 > (e.g. a sudden flow of packets) it could in theory end up trying to handl= e=20 > all this work at the reduced speed since the work has a higher priority t= han=20 > the powerd process. To that end, I think that at least part of powerd ne= eds=20 > to be in the kernel, or at least that the kernel should be more proactive= =20 > about bumping the speed up when it resumes from Cx due to an interrupt. = A=20 > simple policy would be to bump up to full speed for any non-clock interru= pt=20 > (possibly bumping up for a clock interrupt if we wake up softclock as wel= l). >=20 > Thoughts? I have an issue that I believe is similar to what you described. In my case, running X (with a bunch of xterm and fvwm2) and powerd causes immediate hang when ath(4) interface is turned up and no AP is in air. When some AP is present, it takes much more time, but eventually the system still hung. Running powerd without X or X without powerd, or not running ath0 provides rock-solid machine. The laptop has no built-in com-port, neither it has a firewire. I would be glad to test the change. --WeyQLTZFbZxVv3E0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHdSjDC3+MBN1Mb4gRAk5DAJwMv+8HOop4LPj4/Dn+OJkLmavHPgCfZdfH mRixdXl+nyhqQhi2iONDgtE= =UbWg -----END PGP SIGNATURE----- --WeyQLTZFbZxVv3E0-- From owner-freebsd-acpi@FreeBSD.ORG Fri Dec 28 19:39:43 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5B4516A418 for ; Fri, 28 Dec 2007 19:39:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 6D1AE13C447 for ; Fri, 28 Dec 2007 19:39:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8q) with ESMTP id 226422873-1834499 for multiple; Fri, 28 Dec 2007 14:41:50 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id lBSJdX4A064130; Fri, 28 Dec 2007 14:39:33 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-acpi@freebsd.org Date: Fri, 28 Dec 2007 11:31:25 -0500 User-Agent: KMail/1.9.6 References: <20071223045109.GA86130@localhost.ok.cox.net> <477427FA.1060505@root.org> In-Reply-To: <477427FA.1060505@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712281131.25446.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 28 Dec 2007 14:39:33 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5278/Fri Dec 28 11:55:36 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Gordon work Subject: Re: No acpi.thermal on ASUS M2A-VM HDMI X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2007 19:39:43 -0000 On Thursday 27 December 2007 05:32:26 pm Nate Lawson wrote: > Gordon work wrote: > > Hi all, > > > > I have an ASUS M2A-VM HDMI motherboard running the latest BIOS. > > All power management features, in particular AMD "Cool and Quiet" > > and Q-Fan control are enabled, but the system seems oblivious to > > temperature and the fans always runs at the same (noisy) speed. > > The temperature is always given as 40C, which I have read elsewhere > > is a default value. > > > > I would like to control the fan speed. I am not concerned with other > > ACPI features. > > > > Does anyone happen to know of any kernel or APM tweaks that might get > > ACPI thermal working on this board? > > > > System particulars follow: > > > > % uname -a > > FreeBSD localhost 7.0-BETA3 FreeBSD 7.0-BETA3 #4: Sun Dec 16 12:45:34 CST 2007 root@localhost:/usr/obj/usr/src/sys/CUSTOM amd64 > > > > % kldstat > > Id Refs Address Size Name > > 1 5 0xffffffff80100000 7600d8 kernel > > 2 1 0xffffffff80861000 1a570 snd_hda.ko > > 3 2 0xffffffff8087c000 673b8 sound.ko > > 4 1 0xffffffff808e4000 5fd0 acpi_asus.ko > > > > % sysctl hw.acpi.thermal > > hw.acpi.thermal.min_runtime: 0 > > hw.acpi.thermal.polling_rate: 10 > > hw.acpi.thermal.user_override: 0 > > hw.acpi.thermal.tz0.temperature: 40.0C > > hw.acpi.thermal.tz0.active: -1 > > hw.acpi.thermal.tz0.passive_cooling: 1 > > hw.acpi.thermal.tz0.thermal_flags: 0 > > hw.acpi.thermal.tz0._PSV: 73.0C > > hw.acpi.thermal.tz0._HOT: -1 > > hw.acpi.thermal.tz0._CRT: 75.0C > > hw.acpi.thermal.tz0._ACx: 73.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 > > If it's just returning a fixed value of 40C, you should try an external > application that reads the temp directly. For instance, the lmsensors port. > > The ASL itself has the hardcoded value in it, meaning the BIOS vendor > never intended to give ACPI access to the temperature. Actually IIRC, some truly evil BIOSen will alter the AML at runtime via SMI# rather than making _TMP query the value. In that case, _TMP can still "work", but it would always appear as a constant in ASL dumps. -- John Baldwin From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 29 13:03:06 2007 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9346E16A419 for ; Sat, 29 Dec 2007 13:03:06 +0000 (UTC) (envelope-from ganael.laplanche@martymac.com) Received: from data.galacsys.net (data.galacsys.net [217.24.81.1]) by mx1.freebsd.org (Postfix) with ESMTP id 60C1213C447 for ; Sat, 29 Dec 2007 13:03:06 +0000 (UTC) (envelope-from ganael.laplanche@martymac.com) Received: from martymac.com (webmail.galacsys.net [217.24.81.215]) by data.galacsys.net (Postfix) with ESMTP id 1CBB220822 for ; Sat, 29 Dec 2007 13:41:31 +0100 (CET) From: "Ganael LAPLANCHE" To: freebsd-acpi@freebsd.org X-Openwebmail-Date: Sat, 29 Dec 2007 13:41:31 +0100 Message-Id: <20071229114656.M25580@martymac.com> X-Mailer: Open WebMail 2.01 20030425 X-OriginatingIP: 82.246.139.206 (ganael.laplanche@martymac.com) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Date: Sat, 29 Dec 2007 13:41:31 +0100 (CET) Subject: Fujitsu U1010 and PCI-PCI bridge X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2007 13:03:06 -0000 Hi everybody, I've recently bought a U1010 sub-laptop from Fujitsu. It is a nice machine, except that the PCI express port on which the atheros card is plugged does not work properly (and so the card). Here is what appears in a verbose dmesg : [...] pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x0-0x0 pcib1: no prefetched decode pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x168c, dev=0x001c, revid=0x01 domain=0, bus=1, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message MSI-X supports 1 message in map 0x10 map[10]: type Memory, range 64, base 0xf0000000, size 16, memory disabled pcib1: requested unsupported memory range 0xf0000000-0xf000ffff (decoding 0-0, 0-0) I think the problem is quite the same as previously described here : http://lists.freebsd.org/pipermail/freebsd-acpi/2007-July/003870.html say, no resource has been assigned for the bridge (base address of memory, topmost address of memory, base address of prefetchable memory and topmost address of prefetchable memory all equal zero !). Other errors make me think there may be missing (wrong ?) info in the DSDT : [...] pci_link0: BIOS IRQ 11 for 0.2.INTA is invalid [...] pci_link4: BIOS IRQ 11 for 0.29.INTB is invalid [...] pci_link2: BIOS IRQ 11 for 0.29.INTC is invalid [...] pci_link0: BIOS IRQ 11 for 0.29.INTD is invalid [...] pci_link6: BIOS IRQ 11 for 8.4.INTA is invalid I have emailed fujitsu to ask them to fix the DSDT, no answer yet. I've also looked for a fixed DSDT at http://acpi.sourceforge.net but haven't found any for the U1010. Does someone know how that DSDT could be fixed or if it would be easy to do ? Would you have another idea ? Links : - verbose dmesg : http://contribs.martymac.com/misc/U1010-acpi/dmesg.verbose.txt - ASL : http://contribs.martymac.com/misc/U1010-acpi/acpi.asl.txt Extra : - devinfo -v : http://contribs.martymac.com/misc/U1010-acpi/devinfo-v.txt - pciconf -vl : http://contribs.martymac.com/misc/U1010-acpi/pciconf-vl.txt Thanks a lot and happy end-of-year :) Ganaël LAPLANCHE ganael.laplanche@martymac.com http://www.martymac.com From owner-freebsd-acpi@FreeBSD.ORG Sat Dec 29 16:44:15 2007 Return-Path: Delivered-To: acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4E5516A46C for ; Sat, 29 Dec 2007 16:44:15 +0000 (UTC) (envelope-from mi@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.freebsd.org (Postfix) with ESMTP id 8994713C4F3 for ; Sat, 29 Dec 2007 16:44:15 +0000 (UTC) (envelope-from mi@aldan.algebra.com) Received: from aldan.algebra.com (localhost [127.0.0.1]) by aldan.algebra.com (8.14.1/8.14.1) with ESMTP id lBTGOixf002330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Dec 2007 11:24:44 -0500 (EST) (envelope-from mi@aldan.algebra.com) Received: (from mi@localhost) by aldan.algebra.com (8.14.1/8.14.1/Submit) id lBTGOiI1002329; Sat, 29 Dec 2007 11:24:44 -0500 (EST) (envelope-from mi) From: "Mikhail T." Message-Id: <200712291624.lBTGOiI1002329@aldan.algebra.com> To: acpi@FreeBSD.org, questions@FreeBSD.org Date: Sat, 29 Dec 2007 11:24:44 -0500 (EST) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2007 16:44:16 -0000 Hello! I managed to suspend some of my computers a few times (using either ``zzz'' or ``acpiconf -s 1''), but I could never successfully wake the system up after this, requiring a full reboot. What's the proper procedure? I tried the power-button (no effect) and hitting random keyboard keys (no effect). How is it supposed to work? Thanks! -mi