From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 14 02:38:47 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 161F416A41F for ; Sun, 14 Aug 2005 02:38:47 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal4.es.net (postal4.es.net [198.124.252.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB99F43D48 for ; Sun, 14 Aug 2005 02:38:46 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal4.es.net (Postal Node 4) with ESMTP (SSL) id IBA74465 for ; Sat, 13 Aug 2005 19:38:44 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C0D845D07 for ; Sat, 13 Aug 2005 19:38:42 -0700 (PDT) To: acpi@freebsd.org Date: Sat, 13 Aug 2005 19:38:42 -0700 From: "Kevin Oberman" Message-Id: <20050814023842.C0D845D07@ptavv.es.net> Cc: Subject: Annoyances with passive thermal code (acpi_thermal) 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, 14 Aug 2005 02:38:47 -0000 I've noted an unpleasant mis-behavior in acpi_thermal. 1. Killed powerd 2. Set dev.cpu.0.freq to 1200 (I was on batteries and wanted to stretch them) 3. Started a BIG build...openoffice The temp went up over _PSV and the CPU was slowed to 1050. The CPU cooled for a while and the freq was reset to 1800 which started draining my battery way too fast. Ideally, acpi_thermal should store the frequency when it cuts speed and restore that speed when the CPU cools, not the maximum speed. Not a huge problem as I caught it before my battery was too badly impacted, but it would have been really annoying if I had had the battery die before I noticed. Since I run with write cache on my disks, this could have been a disaster with all of the file activity the build of openoffice was generating. (OK. Building openoffice under these circumstances my be a bad idea, but it takes many hours to build and I try to get it built when I can.) -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Sun Aug 14 19:07:00 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3131816A41F for ; Sun, 14 Aug 2005 19:07:00 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97A7643D45 for ; Sun, 14 Aug 2005 19:06:58 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:KYACz5kflEAdNHCrkmMSUVaJ9WueqzIV+Tk9yPHKEzKkYnjcabj3KhL5zJDMsbyh@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7EJ5xZG019596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Aug 2005 04:06:11 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 15 Aug 2005 04:05:52 +0900 Message-ID: From: Hajimu UMEMOTO To: "Kevin Oberman" In-Reply-To: <20050814023842.C0D845D07@ptavv.es.net> References: <20050814023842.C0D845D07@ptavv.es.net> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Mon_Aug_15_04:05:51_2005-1" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Mon, 15 Aug 2005 04:06:13 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 14 Aug 2005 19:07:00 -0000 --Multipart_Mon_Aug_15_04:05:51_2005-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Sat, 13 Aug 2005 19:38:42 -0700 >>>>> "Kevin Oberman" said: oberman> I've noted an unpleasant mis-behavior in acpi_thermal. oberman> 1. Killed powerd oberman> 2. Set dev.cpu.0.freq to 1200 (I was on batteries and wanted to stretch oberman> them) oberman> 3. Started a BIG build...openoffice oberman> The temp went up over _PSV and the CPU was slowed to 1050. The CPU oberman> cooled for a while and the freq was reset to 1800 which started draining oberman> my battery way too fast. It's curious that even when CPU speed is slowed, the temperature go up over _PSV. oberman> Ideally, acpi_thermal should store the frequency when it cuts speed and oberman> restore that speed when the CPU cools, not the maximum speed. CPUFREQ_SET() does it, actually. However, since CPU speed is restored by degrees, we couldn't use the facility effectively. Please try the attached patch. Sincerely, --Multipart_Mon_Aug_15_04:05:51_2005-1 Content-Type: text/x-patch; charset=US-ASCII Content-Disposition: attachment; filename="acpi_thermal.c-saved_level.diff" Content-Transfer-Encoding: 7bit Index: sys/dev/acpica/acpi_thermal.c diff -u -p sys/dev/acpica/acpi_thermal.c.orig sys/dev/acpica/acpi_thermal.c --- sys/dev/acpica/acpi_thermal.c.orig Fri Aug 5 03:02:39 2005 +++ sys/dev/acpica/acpi_thermal.c Mon Aug 15 03:29:30 2005 @@ -116,6 +116,7 @@ struct acpi_tz_softc { int tz_cooling_enabled; int tz_cooling_active; int tz_cooling_updated; + int tz_cooling_saved_level; }; #define CPUFREQ_MAX_LEVELS 64 /* XXX cpufreq should export this */ @@ -202,6 +203,7 @@ acpi_tz_attach(device_t dev) sc->tz_cooling_proc_running = FALSE; sc->tz_cooling_active = FALSE; sc->tz_cooling_updated = FALSE; + sc->tz_cooling_saved_level = 0; /* * Always attempt to enable passive cooling for tz0. Users can enable @@ -853,11 +855,13 @@ acpi_tz_cpufreq_restore(struct acpi_tz_s if ((dev = devclass_get_device(devclass_find("cpufreq"), 0)) == NULL) return (ENXIO); ACPI_VPRINT(sc->tz_dev, acpi_device_get_parent_softc(sc->tz_dev), - "temperature %d.%dC: resuming previous clock speed\n", - TZ_KELVTOC(sc->tz_temperature)); + "temperature %d.%dC: resuming previous clock speed (%d)\n", + TZ_KELVTOC(sc->tz_temperature), sc->tz_cooling_saved_level); error = CPUFREQ_SET(dev, NULL, CPUFREQ_PRIO_KERN); - if (error == 0) + if (error == 0) { + sc->tz_cooling_saved_level = 0; sc->tz_cooling_updated = FALSE; + } return (error); } @@ -914,18 +918,20 @@ acpi_tz_cpufreq_update(struct acpi_tz_so if (i == num_levels) i--; } else { + /* If we didn't decrease frequency yet, don't increase it. */ + if (!sc->tz_cooling_updated) { + sc->tz_cooling_active = FALSE; + goto out; + } + /* Find the closest available frequency, rounding up. */ - for (i = num_levels - 1; i >= 0; i--) + for (i = num_levels - 1; i >= sc->tz_cooling_saved_level; i--) if (levels[i].total_set.freq >= desired_freq) break; - - /* If we didn't find a relevant setting, use the highest. */ - if (i == -1) - i++; } /* If we're going to the highest frequency, restore the old setting. */ - if (i == 0) { + if (i <= sc->tz_cooling_saved_level) { error = acpi_tz_cpufreq_restore(sc); if (error == 0) sc->tz_cooling_active = FALSE; @@ -941,8 +947,14 @@ acpi_tz_cpufreq_update(struct acpi_tz_so (freq > levels[i].total_set.freq) ? "de" : "in", freq, levels[i].total_set.freq); error = CPUFREQ_SET(dev, &levels[i], CPUFREQ_PRIO_KERN); - if (error == 0) + if (error == 0 && !sc->tz_cooling_updated) { + /* Use saved cpu level as maximum value. */ + for (i = num_levels - 1; i >= 0; i--) + if (levels[i].total_set.freq >= freq) + break; + sc->tz_cooling_saved_level = (i < 0) ? 0 : i; sc->tz_cooling_updated = TRUE; + } } out: --Multipart_Mon_Aug_15_04:05:51_2005-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Mon_Aug_15_04:05:51_2005-1-- From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 15 07:20:05 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B628416A41F for ; Mon, 15 Aug 2005 07:20:05 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C78A43D45 for ; Mon, 15 Aug 2005 07:20:04 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:e8rN3dolVy/RgmdGIKilN4jWICHnHja5WJjQ2sgU1JI3VFED/8zUMktyBKNpYCwp@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7F7Ji8n023935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Aug 2005 16:19:50 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 15 Aug 2005 16:19:35 +0900 Message-ID: From: Hajimu UMEMOTO To: "Kevin Oberman" In-Reply-To: References: <20050814023842.C0D845D07@ptavv.es.net> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Mon_Aug_15_16:19:35_2005-1" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Mon, 15 Aug 2005 16:19:53 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 15 Aug 2005 07:20:05 -0000 --Multipart_Mon_Aug_15_16:19:35_2005-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Mon, 15 Aug 2005 04:05:52 +0900 >>>>> Hajimu UMEMOTO said: oberman> Ideally, acpi_thermal should store the frequency when it cuts speed and oberman> restore that speed when the CPU cools, not the maximum speed. ume> CPUFREQ_SET() does it, actually. However, since CPU speed is restored ume> by degrees, we couldn't use the facility effectively. Please try the ume> attached patch. It seems CPUFREQ_SET(NULL) doesn't restore previous setting correctly. So, I changed to make sure to restore previous setting for workaround. Please try this patch instead. Sincerely, --Multipart_Mon_Aug_15_16:19:35_2005-1 Content-Type: text/x-patch; charset=US-ASCII Content-Disposition: attachment; filename="acpi_thermal.c-saved_level.diff" Content-Transfer-Encoding: 7bit Index: sys/dev/acpica/acpi_thermal.c diff -u -p sys/dev/acpica/acpi_thermal.c.orig sys/dev/acpica/acpi_thermal.c --- sys/dev/acpica/acpi_thermal.c.orig Fri Aug 5 03:02:39 2005 +++ sys/dev/acpica/acpi_thermal.c Mon Aug 15 15:05:17 2005 @@ -116,6 +116,7 @@ struct acpi_tz_softc { int tz_cooling_enabled; int tz_cooling_active; int tz_cooling_updated; + int tz_cooling_saved_level; }; #define CPUFREQ_MAX_LEVELS 64 /* XXX cpufreq should export this */ @@ -202,6 +203,7 @@ acpi_tz_attach(device_t dev) sc->tz_cooling_proc_running = FALSE; sc->tz_cooling_active = FALSE; sc->tz_cooling_updated = FALSE; + sc->tz_cooling_saved_level = 0; /* * Always attempt to enable passive cooling for tz0. Users can enable @@ -853,11 +855,28 @@ acpi_tz_cpufreq_restore(struct acpi_tz_s if ((dev = devclass_get_device(devclass_find("cpufreq"), 0)) == NULL) return (ENXIO); ACPI_VPRINT(sc->tz_dev, acpi_device_get_parent_softc(sc->tz_dev), - "temperature %d.%dC: resuming previous clock speed\n", - TZ_KELVTOC(sc->tz_temperature)); + "temperature %d.%dC: resuming previous clock speed (%d)\n", + TZ_KELVTOC(sc->tz_temperature), sc->tz_cooling_saved_level); error = CPUFREQ_SET(dev, NULL, CPUFREQ_PRIO_KERN); - if (error == 0) + if (error == 0) { + struct cf_level *levels; + int num_levels; + + /* XXX: It seems cpu level is not saved/restored correctly. */ + levels = malloc(CPUFREQ_MAX_LEVELS * sizeof(*levels), M_TEMP, + M_NOWAIT); + if (levels == NULL) + return (ENOMEM); + num_levels = CPUFREQ_MAX_LEVELS; + error = CPUFREQ_LEVELS(dev, levels, &num_levels); + if (error == 0) + CPUFREQ_SET(dev, &levels[sc->tz_cooling_saved_level], + CPUFREQ_PRIO_USER); + free(levels, M_TEMP); + + sc->tz_cooling_saved_level = 0; sc->tz_cooling_updated = FALSE; + } return (error); } @@ -914,18 +933,24 @@ acpi_tz_cpufreq_update(struct acpi_tz_so if (i == num_levels) i--; } else { + /* If we didn't decrease frequency yet, don't increase it. */ + if (!sc->tz_cooling_updated) { + sc->tz_cooling_active = FALSE; + goto out; + } + /* Find the closest available frequency, rounding up. */ - for (i = num_levels - 1; i >= 0; i--) + for (i = num_levels - 1; i >= sc->tz_cooling_saved_level; i--) if (levels[i].total_set.freq >= desired_freq) break; /* If we didn't find a relevant setting, use the highest. */ - if (i == -1) - i++; + if (i < sc->tz_cooling_saved_level) + i = sc->tz_cooling_saved_level; } /* If we're going to the highest frequency, restore the old setting. */ - if (i == 0) { + if (i == sc->tz_cooling_saved_level) { error = acpi_tz_cpufreq_restore(sc); if (error == 0) sc->tz_cooling_active = FALSE; @@ -941,8 +966,14 @@ acpi_tz_cpufreq_update(struct acpi_tz_so (freq > levels[i].total_set.freq) ? "de" : "in", freq, levels[i].total_set.freq); error = CPUFREQ_SET(dev, &levels[i], CPUFREQ_PRIO_KERN); - if (error == 0) + if (error == 0 && !sc->tz_cooling_updated) { + /* Use saved cpu level as maximum value. */ + for (i = num_levels - 1; i >= 0; i--) + if (levels[i].total_set.freq >= freq) + break; + sc->tz_cooling_saved_level = (i < 0) ? 0 : i; sc->tz_cooling_updated = TRUE; + } } out: --Multipart_Mon_Aug_15_16:19:35_2005-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Mon_Aug_15_16:19:35_2005-1-- From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 15 11:01:42 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B37416A41F for ; Mon, 15 Aug 2005 11:01:42 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68EF443D49 for ; Mon, 15 Aug 2005 11:01:42 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j7FB1g5i007402 for ; Mon, 15 Aug 2005 11:01:42 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j7FB1fOW007396 for freebsd-acpi@freebsd.org; Mon, 15 Aug 2005 11:01:41 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 15 Aug 2005 11:01:41 GMT Message-Id: <200508151101.j7FB1fOW007396@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-acpi@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 15 Aug 2005 11:01:42 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/22] i386/54756 acpi ACPI suspend/resume problem on CF-W2 lapt o [2003/08/17] i386/55661 acpi ACPI suspend/resume problem on ARMADA M70 o [2003/08/20] kern/55822 acpi No ACPI power off with SMP kernel o [2003/08/27] kern/56024 acpi ACPI suspend drains battery while in S3 o [2003/09/03] i386/56372 acpi acpi don't work on TYAN tiger100 M/B o [2004/03/09] i386/64002 acpi acpi problem o [2004/05/27] i386/67273 acpi [hang] system hangs with acpi and Xfree o [2004/10/12] i386/72566 acpi ACPI, FreeBSD disables fan on Compaq Arma o [2005/03/21] i386/79080 acpi acpi thermal changes freezes HP nx6110 o [2005/03/21] i386/79081 acpi ACPI suspend/resume not working on HP nx6 10 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/03/17] kern/64365 acpi ACPI problems o [2004/05/28] kern/67309 acpi zzz reboot computer (ACPI S3) o [2004/07/29] i386/69750 acpi Boot without ACPI failed on ASUS L5 o [2004/11/11] i386/73822 acpi [request] add thermal support to ACPI o [2004/11/11] kern/73823 acpi acpi / power-on by timer support o [2004/11/17] kern/74030 acpi Unplugging AC causes battery % to stay lo o [2004/11/21] kern/74215 acpi [request] add ACPI headers to /usr/includ o [2005/05/09] kern/80815 acpi ACPI(pci_link) problem in 5.4-STABLE: TIM 8 problems total. From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 15 16:42:23 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB7CD16A41F for ; Mon, 15 Aug 2005 16:42:23 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AF1443D6D for ; Mon, 15 Aug 2005 16:42:21 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j7FGgBo5013861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Aug 2005 09:42:12 -0700 Message-ID: <4300C5DF.40409@root.org> Date: Mon, 15 Aug 2005 09:42:07 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20050814023842.C0D845D07@ptavv.es.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 15 Aug 2005 16:42:23 -0000 Hajimu UMEMOTO wrote: >>>>>>On Mon, 15 Aug 2005 04:05:52 +0900 >>>>>>Hajimu UMEMOTO said: > > > oberman> Ideally, acpi_thermal should store the frequency when it cuts speed and > oberman> restore that speed when the CPU cools, not the maximum speed. > > ume> CPUFREQ_SET() does it, actually. However, since CPU speed is restored > ume> by degrees, we couldn't use the facility effectively. Please try the > ume> attached patch. > > It seems CPUFREQ_SET(NULL) doesn't restore previous setting correctly. > So, I changed to make sure to restore previous setting for workaround. > Please try this patch instead. Would you mind checking the implementation of CPUFREQ_SET in kern_cpu.c? I'm wondering what doesn't work about it and it's the right place to solve this problem. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 15 16:51:47 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD6CF16A41F for ; Mon, 15 Aug 2005 16:51:47 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F92B43D49 for ; Mon, 15 Aug 2005 16:51:47 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j7FGpmo5013924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Aug 2005 09:51:49 -0700 Message-ID: <4300C821.6000803@root.org> Date: Mon, 15 Aug 2005 09:51:45 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wesley Gentine References: <42FCFFAB.9060006@gmail.com> <42FD1079.3020607@root.org> <42FDF2C0.8040100@gmail.com> <42FDF3CF.9060605@gmail.com> In-Reply-To: <42FDF3CF.9060605@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_fujitsu doesnt work 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, 15 Aug 2005 16:51:48 -0000 Wesley Gentine wrote: > Wesley Gentine wrote: > >> Nate Lawson wrote: >> >>> Wesley Gentine wrote: >>> >>>> I have a Fujitsu FmV Biblo MG50H (japanese) and I tried to compile >>>> acpi_fujitsu inside kernel and nothing happened. But loading kernel >>>> module I have the following output: >>>> >>>> acpi_fujitsu0: on acpi0 >>>> acpi_fujitsu0: Couldn't query volume level >>>> acpi_fujitsu0: Couldn't init button states >>>> acpi_fujitsu0: Couldn't initialize button states! >>> >>> >>> >>> >>> It appears your system has a different version of the fujitsu button >>> hardware. Post the url of your ASL, acpidump -t -d > fmv-mg50h.asl >>> > > Use this file: http://crystalwall.sites.uol.com.br/fmv-mg50h.asl.html I don't see what's wrong. Your system has a FUJ02B1 device and that's what acpi_fujitsu looks for. Perhaps someone who has such a laptop can look at this further. You can also try inserting printfs in acpi_fujitsu_probe/attach() to see where the function is returning. Device (FJEX) { Name (_HID, "FUJ02B1") Method (_STA, 0, NotSerialized) { Return (0x0F) } -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 15 17:00:59 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DD3B16A41F for ; Mon, 15 Aug 2005 17:00:59 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67DF943D49 for ; Mon, 15 Aug 2005 17:00:57 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:d6gIqwAVNzspBtvDg4EEC6YE5uW6L8jfHnkLIK96jCizGxk65oKug48fhH4CgN5+@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7FH0hQN065284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2005 02:00:49 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 16 Aug 2005 02:00:34 +0900 Message-ID: From: Hajimu UMEMOTO To: Nate Lawson In-Reply-To: <4300C5DF.40409@root.org> References: <20050814023842.C0D845D07@ptavv.es.net> <4300C5DF.40409@root.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 16 Aug 2005 02:00:51 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 15 Aug 2005 17:00:59 -0000 Hi, >>>>> On Mon, 15 Aug 2005 09:42:07 -0700 >>>>> Nate Lawson said: nate> Would you mind checking the implementation of CPUFREQ_SET in kern_cpu.c? nate> I'm wondering what doesn't work about it and it's the right place to nate> solve this problem. I turned debug.cpufreq.verbose on. It seems that maximum frequency is always saved even after I set lower frequency (1050) by sysctl(8). Aug 15 04:51:05 kasuga kernel: cpufreq: saving level, freq 1200 prio 0 Where, 1200 is a maximum frequency of my box. I'm now tracking CPUFREQ_SET. However, I cannot detect what is going on. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 15 18:10:50 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3155D16A41F; Mon, 15 Aug 2005 18:10:50 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED66443D45; Mon, 15 Aug 2005 18:10:49 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Mon, 15 Aug 2005 11:10:48 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 5B2385D07; Mon, 15 Aug 2005 11:10:48 -0700 (PDT) To: Hajimu UMEMOTO In-reply-to: Your message of "Mon, 15 Aug 2005 04:05:52 +0900." Date: Mon, 15 Aug 2005 11:10:48 -0700 From: "Kevin Oberman" Message-Id: <20050815181048.5B2385D07@ptavv.es.net> Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 15 Aug 2005 18:10:50 -0000 > Date: Mon, 15 Aug 2005 04:05:52 +0900 > From: Hajimu UMEMOTO > Hi, > > >>>>> On Sat, 13 Aug 2005 19:38:42 -0700 > >>>>> "Kevin Oberman" said: > > oberman> I've noted an unpleasant mis-behavior in acpi_thermal. > > oberman> 1. Killed powerd > oberman> 2. Set dev.cpu.0.freq to 1200 (I was on batteries and wanted to stretch > oberman> them) > oberman> 3. Started a BIG build...openoffice > > oberman> The temp went up over _PSV and the CPU was slowed to 1050. The CPU > oberman> cooled for a while and the freq was reset to 1800 which started draining > oberman> my battery way too fast. > > It's curious that even when CPU speed is slowed, the temperature go up > over _PSV. Yes, it is. I have seen that a fully loaded CPU will top out at 73C. At 1.35 GHz it reached 85C. I did this testing with a totally loaded CPU and no real I/O using 'dd if-/dev/zero count=1000 bs=1m | md5'. This loads the CPU and should push temperature to the max possible, but I was seeing the system running at 86C while building OpenOffice.org late last week and it was triggering passive thermal management which is set at 86.5C. I have no idea why building OpenOffice.org (port editors/openoffice-2.0-devel) causes the system to run hotter than the md5 test. By the way, I have noticed that dev.acpi_ibm.0.thermal returns temperatures that are more current than hw.acpi.thermal.tz0.temperature. The former seems to be immediate while the latter lags up to several seconds. Odd. > oberman> Ideally, acpi_thermal should store the frequency when it cuts speed and > oberman> restore that speed when the CPU cools, not the maximum speed. > > CPUFREQ_SET() does it, actually. However, since CPU speed is restored > by degrees, we couldn't use the facility effectively. Please try the > attached patch. I'll give it a shot as soon as I can, but I'd rather not rebuild it until I can back up my system which won't be until tomorrow. Thanks very much for looking at this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 15 18:37:13 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08BAB16A41F for ; Mon, 15 Aug 2005 18:37:13 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A999E43D45 for ; Mon, 15 Aug 2005 18:37:12 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.50] (adsl-64-171-187-230.dsl.snfc21.pacbell.net [64.171.187.230]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j7FIbDo5014781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Aug 2005 11:37:14 -0700 Message-ID: <4300E0D5.5090409@root.org> Date: Mon, 15 Aug 2005 11:37:09 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wesley Gentine References: <42FCFFAB.9060006@gmail.com> <42FD1079.3020607@root.org> <42FDF2C0.8040100@gmail.com> <42FDF3CF.9060605@gmail.com> <4300C821.6000803@root.org> In-Reply-To: <4300C821.6000803@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_fujitsu doesnt work 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, 15 Aug 2005 18:37:13 -0000 Nate Lawson wrote: >>>> Wesley Gentine wrote: >>>> >>>>> I have a Fujitsu FmV Biblo MG50H (japanese) and I tried to compile >>>>> acpi_fujitsu inside kernel and nothing happened. But loading kernel >>>>> module I have the following output: >>>>> >>>>> acpi_fujitsu0: on acpi0 >>>>> acpi_fujitsu0: Couldn't query volume level >>>>> acpi_fujitsu0: Couldn't init button states >>>>> acpi_fujitsu0: Couldn't initialize button states! >> >> Use this file: http://crystalwall.sites.uol.com.br/fmv-mg50h.asl.html > > I don't see what's wrong. Your system has a FUJ02B1 device and that's > what acpi_fujitsu looks for. Perhaps someone who has such a laptop can > look at this further. You can also try inserting printfs in > acpi_fujitsu_probe/attach() to see where the function is returning. > > Device (FJEX) > { > Name (_HID, "FUJ02B1") > Method (_STA, 0, NotSerialized) > { > Return (0x0F) > } I looked a little more. It appears that your device is detected properly but acpi_fujitsu_update() is failing for some reason. Your system doesn't support the GVOL method (volume control). Just remove the first "return (FALSE)" line from acpi_fujitsu_update() and it will continue to probe other things even if it can't find volume control. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Mon Aug 15 19:09:20 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A1F516A41F; Mon, 15 Aug 2005 19:09:20 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id D800C43D46; Mon, 15 Aug 2005 19:09:19 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:1E5bA+ck+kkVpoQhVobgtf8mznH931YKZLMpGshIaMfc5Nw/AWgDVWt2P3Wm7/qF@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7FJ96W9080447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2005 04:09:13 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 16 Aug 2005 04:08:51 +0900 Message-ID: From: Hajimu UMEMOTO To: Hajimu UMEMOTO In-Reply-To: References: <20050814023842.C0D845D07@ptavv.es.net> <4300C5DF.40409@root.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 16 Aug 2005 04:09:15 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 15 Aug 2005 19:09:20 -0000 Hi, >>>>> On Tue, 16 Aug 2005 02:00:34 +0900 >>>>> Hajimu UMEMOTO said: nate> Would you mind checking the implementation of CPUFREQ_SET in kern_cpu.c? nate> I'm wondering what doesn't work about it and it's the right place to nate> solve this problem. ume> I turned debug.cpufreq.verbose on. It seems that maximum frequency is ume> always saved even after I set lower frequency (1050) by sysctl(8). ume> Aug 15 04:51:05 kasuga kernel: cpufreq: saving level, freq 1200 prio 0 ume> Where, 1200 is a maximum frequency of my box. ume> I'm now tracking CPUFREQ_SET. However, I cannot detect what is going ume> on. I found the cause. The saved_level is not stackable. So, an initial cpu level was saved, then a cpu level at CPUFREQ_PRIO_USER was not saved. Here is a patch to solve this problem: Index: sys/kern/kern_cpu.c diff -u -p sys/kern/kern_cpu.c.orig sys/kern/kern_cpu.c --- sys/kern/kern_cpu.c.orig Mon Apr 11 04:11:23 2005 +++ sys/kern/kern_cpu.c Tue Aug 16 03:31:55 2005 @@ -336,6 +336,7 @@ cf_set_method(device_t dev, const struct */ if (sc->curr_level.total_set.freq != CPUFREQ_VAL_UNKNOWN && sc->saved_level.total_set.freq == CPUFREQ_VAL_UNKNOWN && + sc->curr_priority > CPUFREQ_PRIO_LOWEST && priority > sc->curr_priority) { CF_DEBUG("saving level, freq %d prio %d\n", sc->curr_level.total_set.freq, sc->curr_priority); I think it is enough to solve CPUFREQ_PRIO_USER v.s. CPUFREQ_PRIO_KERN issue. However, it may better to have saved_level at each priority, IMHO. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 16 01:08:40 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6871F16A41F; Tue, 16 Aug 2005 01:08:40 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB4E543D6B; Tue, 16 Aug 2005 01:08:35 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j7G18bo5018694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Aug 2005 18:08:37 -0700 Message-ID: <43013C90.7040901@root.org> Date: Mon, 15 Aug 2005 18:08:32 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20050814023842.C0D845D07@ptavv.es.net> <4300C5DF.40409@root.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 16 Aug 2005 01:08:40 -0000 Hajimu UMEMOTO wrote: > I found the cause. The saved_level is not stackable. So, an initial > cpu level was saved, then a cpu level at CPUFREQ_PRIO_USER was not > saved. Here is a patch to solve this problem: > > Index: sys/kern/kern_cpu.c > diff -u -p sys/kern/kern_cpu.c.orig sys/kern/kern_cpu.c > --- sys/kern/kern_cpu.c.orig Mon Apr 11 04:11:23 2005 > +++ sys/kern/kern_cpu.c Tue Aug 16 03:31:55 2005 > @@ -336,6 +336,7 @@ cf_set_method(device_t dev, const struct > */ > if (sc->curr_level.total_set.freq != CPUFREQ_VAL_UNKNOWN && > sc->saved_level.total_set.freq == CPUFREQ_VAL_UNKNOWN && > + sc->curr_priority > CPUFREQ_PRIO_LOWEST && > priority > sc->curr_priority) { > CF_DEBUG("saving level, freq %d prio %d\n", > sc->curr_level.total_set.freq, sc->curr_priority); > > I think it is enough to solve CPUFREQ_PRIO_USER v.s. CPUFREQ_PRIO_KERN > issue. However, it may better to have saved_level at each priority, > IMHO. The original intention was that we would save a stack of values and that a CPUFREQ_SET(NULL, prio) would restore the last setting for the priority before "prio". Example: freq = 1000 Mhz CPUFREQ_SET(1200, PRIO_USER) -- saves 1000 Mhz @PRIO_LOWEST freq = 1200 CPUFREQ_SET(1800, PRIO_LOWEST) -- EPERM since prio too low freq = 1200 CPUFREQ_SET(1700, PRIO_KERN) -- saves 1200 Mhz @PRIO_USER freq = 1700 CPUFREQ_SET(1900, PRIO_KERN) -- no saves since prio same as before freq = 1900 CPUFREQ_SET(NULL, PRIO_KERN) -- restores 1200 Mhz @PRIO_USER freq = 1200 CPUFREQ_SET(NULL, PRIO_USER) -- restores 1000 Mhz @PRIO_LOWEST freq = 1000 Implementing this as a simple array would make sense. Would you be willing to do this? If not, your patch should be fine for now. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 16 05:43:18 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B753216A41F for ; Tue, 16 Aug 2005 05:43:18 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 369B943D45 for ; Tue, 16 Aug 2005 05:43:17 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:u+3n7+2RVXGO8Fc0UwC9cFExqZO/MWZnRHNLkpBeicnkpg8mbNY/D1hvtYh2TAEr@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7G5h98T033727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Aug 2005 14:43:11 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 16 Aug 2005 14:42:00 +0900 Message-ID: From: Hajimu UMEMOTO To: Nate Lawson In-Reply-To: <43013C90.7040901@root.org> References: <20050814023842.C0D845D07@ptavv.es.net> <4300C5DF.40409@root.org> <43013C90.7040901@root.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Tue, 16 Aug 2005 14:43:13 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 16 Aug 2005 05:43:18 -0000 Hi, >>>>> On Mon, 15 Aug 2005 18:08:32 -0700 >>>>> Nate Lawson said: nate> The original intention was that we would save a stack of values and that nate> a CPUFREQ_SET(NULL, prio) would restore the last setting for the nate> priority before "prio". nate> Example: nate> freq = 1000 Mhz nate> CPUFREQ_SET(1200, PRIO_USER) -- saves 1000 Mhz @PRIO_LOWEST nate> freq = 1200 nate> CPUFREQ_SET(1800, PRIO_LOWEST) -- EPERM since prio too low nate> freq = 1200 nate> CPUFREQ_SET(1700, PRIO_KERN) -- saves 1200 Mhz @PRIO_USER nate> freq = 1700 nate> CPUFREQ_SET(1900, PRIO_KERN) -- no saves since prio same as before nate> freq = 1900 nate> CPUFREQ_SET(NULL, PRIO_KERN) -- restores 1200 Mhz @PRIO_USER nate> freq = 1200 nate> CPUFREQ_SET(NULL, PRIO_USER) -- restores 1000 Mhz @PRIO_LOWEST nate> freq = 1000 nate> Implementing this as a simple array would make sense. Would you be nate> willing to do this? If not, your patch should be fine for now. No, I need to save a cpu level only when raising prio to PRIO_KERN from lower prio. But, I realized that my privious patch was insufficient. If dev.cpu.0.freq was not set by sysctl(8), cpu level was never saved. Index: sys/kern/kern_cpu.c diff -u -p sys/kern/kern_cpu.c.orig sys/kern/kern_cpu.c --- sys/kern/kern_cpu.c.orig Mon Apr 11 04:11:23 2005 +++ sys/kern/kern_cpu.c Tue Aug 16 14:22:10 2005 @@ -336,7 +336,7 @@ cf_set_method(device_t dev, const struct */ if (sc->curr_level.total_set.freq != CPUFREQ_VAL_UNKNOWN && sc->saved_level.total_set.freq == CPUFREQ_VAL_UNKNOWN && - priority > sc->curr_priority) { + priority > CPUFREQ_PRIO_USER && priority > sc->curr_priority) { CF_DEBUG("saving level, freq %d prio %d\n", sc->curr_level.total_set.freq, sc->curr_priority); sc->saved_level = sc->curr_level; In anyway, we should make this as stack some day. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 16 17:59:49 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77D4016A41F; Tue, 16 Aug 2005 17:59:49 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B0543D46; Tue, 16 Aug 2005 17:59:49 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j7GHxoo5026695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Aug 2005 10:59:51 -0700 Message-ID: <4302298F.6080407@root.org> Date: Tue, 16 Aug 2005 10:59:43 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20050814023842.C0D845D07@ptavv.es.net> <4300C5DF.40409@root.org> <43013C90.7040901@root.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 16 Aug 2005 17:59:49 -0000 Hajimu UMEMOTO wrote: > No, I need to save a cpu level only when raising prio to PRIO_KERN > from lower prio. But, I realized that my privious patch was > insufficient. If dev.cpu.0.freq was not set by sysctl(8), cpu level > was never saved. > > Index: sys/kern/kern_cpu.c > diff -u -p sys/kern/kern_cpu.c.orig sys/kern/kern_cpu.c > --- sys/kern/kern_cpu.c.orig Mon Apr 11 04:11:23 2005 > +++ sys/kern/kern_cpu.c Tue Aug 16 14:22:10 2005 > @@ -336,7 +336,7 @@ cf_set_method(device_t dev, const struct > */ > if (sc->curr_level.total_set.freq != CPUFREQ_VAL_UNKNOWN && > sc->saved_level.total_set.freq == CPUFREQ_VAL_UNKNOWN && > - priority > sc->curr_priority) { > + priority > CPUFREQ_PRIO_USER && priority > sc->curr_priority) { > CF_DEBUG("saving level, freq %d prio %d\n", > sc->curr_level.total_set.freq, sc->curr_priority); > sc->saved_level = sc->curr_level; I'm ok with you committing this. > In anyway, we should make this as stack some day. That would be nice for the future. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Tue Aug 16 20:11:25 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63CD916A41F for ; Tue, 16 Aug 2005 20:11:25 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7EFE43D45 for ; Tue, 16 Aug 2005 20:11:24 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:+EAPtau1GzXWcLt47WRWq1oRquZQmzdat6qGrJGL8QN/rZsITSXoI21ANHNhaj3g@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7GKAvuj058394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Aug 2005 05:11:14 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 17 Aug 2005 05:10:42 +0900 Message-ID: From: Hajimu UMEMOTO To: Nate Lawson In-Reply-To: <4302298F.6080407@root.org> References: <20050814023842.C0D845D07@ptavv.es.net> <4300C5DF.40409@root.org> <43013C90.7040901@root.org> <4302298F.6080407@root.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Wed, 17 Aug 2005 05:11:16 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 16 Aug 2005 20:11:25 -0000 Hi, >>>>> On Tue, 16 Aug 2005 10:59:43 -0700 >>>>> Nate Lawson said: > No, I need to save a cpu level only when raising prio to PRIO_KERN > from lower prio. But, I realized that my privious patch was > insufficient. If dev.cpu.0.freq was not set by sysctl(8), cpu level > was never saved. > > Index: sys/kern/kern_cpu.c > diff -u -p sys/kern/kern_cpu.c.orig sys/kern/kern_cpu.c > --- sys/kern/kern_cpu.c.orig Mon Apr 11 04:11:23 2005 > +++ sys/kern/kern_cpu.c Tue Aug 16 14:22:10 2005 > @@ -336,7 +336,7 @@ cf_set_method(device_t dev, const struct > */ > if (sc->curr_level.total_set.freq != CPUFREQ_VAL_UNKNOWN && > sc->saved_level.total_set.freq == CPUFREQ_VAL_UNKNOWN && > - priority > sc->curr_priority) { > + priority > CPUFREQ_PRIO_USER && priority > sc->curr_priority) { > CF_DEBUG("saving level, freq %d prio %d\n", > sc->curr_level.total_set.freq, sc->curr_priority); > sc->saved_level = sc->curr_level; nate> I'm ok with you committing this. Thanks! I've just committed it. > In anyway, we should make this as stack some day. nate> That would be nice for the future. Okay, I'll implement this when I have a time. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 17 03:01:47 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A614316A41F for ; Wed, 17 Aug 2005 03:01:47 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D3AC43D48 for ; Wed, 17 Aug 2005 03:01:47 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so54876nzo for ; Tue, 16 Aug 2005 20:01:44 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=G6uQ4Xw9NXi/benkFE1hOFD3VHIYEz3ak7qFFbuzFZcRa9CKW644NgigQ1UK+766I1ki5Ii3fAQeaplGsYuEH7HPCGVccnVninF2pNlyLswfNBXub8l9lzhHRWpN3Hi0meiGfnj3AKElp3A1DXTtkFP+18FR7AbBetMb05cBDWc= Received: by 10.36.146.20 with SMTP id t20mr128797nzd; Tue, 16 Aug 2005 20:01:44 -0700 (PDT) Received: by 10.37.20.11 with HTTP; Tue, 16 Aug 2005 20:01:44 -0700 (PDT) Message-ID: Date: Wed, 17 Aug 2005 00:01:44 -0300 From: Wesley Gentine To: Nate Lawson In-Reply-To: <4300E0D5.5090409@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42FCFFAB.9060006@gmail.com> <42FD1079.3020607@root.org> <42FDF2C0.8040100@gmail.com> <42FDF3CF.9060605@gmail.com> <4300C821.6000803@root.org> <4300E0D5.5090409@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_fujitsu doesnt work 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: Wed, 17 Aug 2005 03:01:47 -0000 Thank you Nate! But, my acpi is FUJ FJNB18B as above: acpi0: on motherboard acpi0: Power Button (fixed) Thanks for all! Wesley On 8/15/05, Nate Lawson wrote: > Nate Lawson wrote: > >>>> Wesley Gentine wrote: > >>>> > >>>>> I have a Fujitsu FmV Biblo MG50H (japanese) and I tried to compile > >>>>> acpi_fujitsu inside kernel and nothing happened. But loading kernel > >>>>> module I have the following output: > >>>>> > >>>>> acpi_fujitsu0: on acpi0 > >>>>> acpi_fujitsu0: Couldn't query volume level > >>>>> acpi_fujitsu0: Couldn't init button states > >>>>> acpi_fujitsu0: Couldn't initialize button states! > >> > >> Use this file: http://crystalwall.sites.uol.com.br/fmv-mg50h.asl.html > > > > I don't see what's wrong. Your system has a FUJ02B1 device and that's > > what acpi_fujitsu looks for. Perhaps someone who has such a laptop can > > look at this further. You can also try inserting printfs in > > acpi_fujitsu_probe/attach() to see where the function is returning. > > > > Device (FJEX) > > { > > Name (_HID, "FUJ02B1") > > Method (_STA, 0, NotSerialized) > > { > > Return (0x0F) > > } >=20 > I looked a little more. It appears that your device is detected > properly but acpi_fujitsu_update() is failing for some reason. Your > system doesn't support the GVOL method (volume control). Just remove > the first "return (FALSE)" line from acpi_fujitsu_update() and it will > continue to probe other things even if it can't find volume control. >=20 > -- > Nate > From owner-freebsd-acpi@FreeBSD.ORG Wed Aug 17 17:20:59 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88E6116A41F for ; Wed, 17 Aug 2005 17:20:59 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA04A43D49 for ; Wed, 17 Aug 2005 17:20:58 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:TgEn3oYWUVaNgtbGhfXk8WE0/6X0MOHC4JvqBYjsYTi1naeDsaOSZD8uMw0ddMna@[IPv6:3ffe:501:185b:801a:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7HHKnMs055887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Aug 2005 02:20:52 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 18 Aug 2005 02:20:35 +0900 Message-ID: From: Hajimu UMEMOTO To: Nate Lawson In-Reply-To: References: <20050814023842.C0D845D07@ptavv.es.net> <4300C5DF.40409@root.org> <43013C90.7040901@root.org> <4302298F.6080407@root.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Thu, 18 Aug 2005 02:20:55 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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: Wed, 17 Aug 2005 17:20:59 -0000 Hi, >>>>> On Wed, 17 Aug 2005 05:10:42 +0900 >>>>> Hajimu UMEMOTO said: > In anyway, we should make this as stack some day. nate> That would be nice for the future. ume> Okay, I'll implement this when I have a time. How about this? The original code allowed to restore a cpu level from CPUFREQ_SET(NULL, prio) with any prio. I tought it is not intentional. So, I changed to check if prio is at same one. Index: sys/kern/kern_cpu.c diff -u -p sys/kern/kern_cpu.c.orig sys/kern/kern_cpu.c --- sys/kern/kern_cpu.c.orig Tue Aug 16 14:22:10 2005 +++ sys/kern/kern_cpu.c Wed Aug 17 12:37:24 2005 @@ -57,12 +57,17 @@ __FBSDID("$FreeBSD: src/sys/kern/kern_cp */ #define CF_MAX_LEVELS 64 +struct cf_saved_freq { + struct cf_level level; + int priority; + SLIST_ENTRY(cf_saved_freq) link; +}; + struct cpufreq_softc { struct sx lock; struct cf_level curr_level; int curr_priority; - struct cf_level saved_level; - int saved_priority; + SLIST_HEAD(, cf_saved_freq) saved_freq; struct cf_level_lst all_levels; int all_count; int max_mhz; @@ -149,7 +154,7 @@ cpufreq_attach(device_t dev) TAILQ_INIT(&sc->all_levels); CF_MTX_INIT(&sc->lock); sc->curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; - sc->saved_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; + SLIST_INIT(&sc->saved_freq); sc->max_mhz = CPUFREQ_VAL_UNKNOWN; /* @@ -181,12 +186,18 @@ static int cpufreq_detach(device_t dev) { struct cpufreq_softc *sc; + struct cf_saved_freq *saved_freq; int numdevs; CF_DEBUG("shutdown %s\n", device_get_nameunit(dev)); sc = device_get_softc(dev); sysctl_ctx_free(&sc->sysctl_ctx); + while ((saved_freq = SLIST_FIRST(&sc->saved_freq)) != NULL) { + SLIST_REMOVE_HEAD(&sc->saved_freq, link); + free(saved_freq, M_TEMP); + } + /* Only clean up these resources when the last device is detaching. */ numdevs = devclass_get_count(cpufreq_dc); if (numdevs == 1) { @@ -208,12 +219,14 @@ cf_set_method(device_t dev, const struct { struct cpufreq_softc *sc; const struct cf_setting *set; + struct cf_saved_freq *saved_freq, *curr_freq; struct pcpu *pc; int cpu_id, error, i; sc = device_get_softc(dev); error = 0; set = NULL; + saved_freq = NULL; /* * Check that the TSC isn't being used as a timecounter. @@ -223,29 +236,34 @@ cf_set_method(device_t dev, const struct if (strcmp(timecounter->tc_name, "TSC") == 0) return (EBUSY); + CF_MTX_LOCK(&sc->lock); + + /* + * If the requested level has a lower priority, don't allow + * the new level right now. + */ + if (priority < sc->curr_priority) { + CF_DEBUG("ignoring, curr prio %d less than %d\n", priority, + sc->curr_priority); + error = EPERM; + goto out; + } + /* * If the caller didn't specify a level and one is saved, prepare to * restore the saved level. If none has been saved, return an error. - * If they did specify one, but the requested level has a lower - * priority, don't allow the new level right now. */ - CF_MTX_LOCK(&sc->lock); if (level == NULL) { - if (sc->saved_level.total_set.freq != CPUFREQ_VAL_UNKNOWN) { - level = &sc->saved_level; - priority = sc->saved_priority; - CF_DEBUG("restoring saved level, freq %d prio %d\n", - level->total_set.freq, priority); - } else { + saved_freq = SLIST_FIRST(&sc->saved_freq); + if (saved_freq == NULL) { CF_DEBUG("NULL level, no saved level\n"); error = ENXIO; goto out; } - } else if (priority < sc->curr_priority) { - CF_DEBUG("ignoring, curr prio %d less than %d\n", priority, - sc->curr_priority); - error = EPERM; - goto out; + level = &saved_freq->level; + priority = saved_freq->priority; + CF_DEBUG("restoring saved level, freq %d prio %d\n", + level->total_set.freq, priority); } /* Reject levels that are below our specified threshold. */ @@ -322,28 +340,34 @@ cf_set_method(device_t dev, const struct } } - /* If we were restoring a saved state, reset it to "unused". */ - if (level == &sc->saved_level) { - CF_DEBUG("resetting saved level\n"); - sc->saved_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; - sc->saved_priority = 0; - } - /* * Before recording the current level, check if we're going to a - * higher priority and have not saved a level yet. If so, save the - * previous level and priority. + * higher priority. If so, save the previous level and priority. */ if (sc->curr_level.total_set.freq != CPUFREQ_VAL_UNKNOWN && - sc->saved_level.total_set.freq == CPUFREQ_VAL_UNKNOWN && - priority > CPUFREQ_PRIO_USER && priority > sc->curr_priority) { + priority > sc->curr_priority) { CF_DEBUG("saving level, freq %d prio %d\n", sc->curr_level.total_set.freq, sc->curr_priority); - sc->saved_level = sc->curr_level; - sc->saved_priority = sc->curr_priority; + curr_freq = malloc(sizeof(*curr_freq), M_TEMP, M_NOWAIT); + if (curr_freq == NULL) { + error = ENOMEM; + goto out; + } + curr_freq->level = sc->curr_level; + curr_freq->priority = sc->curr_priority; + SLIST_INSERT_HEAD(&sc->saved_freq, curr_freq, link); } sc->curr_level = *level; sc->curr_priority = priority; + + /* If we were restoring a saved state, reset it to "unused". */ + if (saved_freq != NULL) { + CF_DEBUG("resetting saved level\n"); + sc->curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; + SLIST_REMOVE_HEAD(&sc->saved_freq, link); + free(saved_freq, M_TEMP); + } + error = 0; out: Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 18 14:15:44 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F5C916A41F for ; Thu, 18 Aug 2005 14:15:44 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from ns.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4D8C43D55 for ; Thu, 18 Aug 2005 14:15:43 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost [127.0.0.1]) by ns.init-main.com (8.13.3/8.13.1) with ESMTP id j7IEFEXY016065 for ; Thu, 18 Aug 2005 23:15:15 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200508181415.j7IEFEXY016065@ns.init-main.com> To: freebsd-acpi@freebsd.org Date: Thu, 18 Aug 2005 23:15:14 +0900 From: Takanori Watanabe Subject: Radeontool 1.5 for FreeBSD 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, 18 Aug 2005 14:15:44 -0000 Hi, I ported Radeontool-1.5 for FreeBSD. (http://fdd.com/software/radeon/) If you have laptops with radeon and entering S3 will sleep with backlight keeping on, worth trying. The patch is at http://www.init-main.com/radeontool.patch From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 18 15:24:41 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42D2A16A41F for ; Thu, 18 Aug 2005 15:24:41 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id D190A43D45 for ; Thu, 18 Aug 2005 15:24:40 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so338160rne for ; Thu, 18 Aug 2005 08:24:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NB1oKeuru4vpaKSIEmBhNOM1Rgj5aQx8H575r6LuCTlSY/dV8LFxD+28UCSoGqLEcH6nnON7JNIYGS9heo6U4AkCRtyGywLzSJfXXsXy4i0SqcG+6X9qgIkJnmZBIOM6+1FtBgrxvz2aoxHqrmygN9QJIdcBPnNbG4pknYZaHBk= Received: by 10.38.75.29 with SMTP id x29mr642580rna; Thu, 18 Aug 2005 08:24:37 -0700 (PDT) Received: by 10.38.101.34 with HTTP; Thu, 18 Aug 2005 08:24:37 -0700 (PDT) Message-ID: Date: Fri, 19 Aug 2005 00:24:37 +0900 From: Eric Kjeldergaard To: Takanori Watanabe In-Reply-To: <200508181415.j7IEFEXY016065@ns.init-main.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200508181415.j7IEFEXY016065@ns.init-main.com> Cc: freebsd-acpi@freebsd.org Subject: Re: Radeontool 1.5 for FreeBSD 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, 18 Aug 2005 15:24:41 -0000 On 8/18/05, Takanori Watanabe wrote: > Hi, I ported Radeontool-1.5 for FreeBSD. >=20 > (http://fdd.com/software/radeon/) > If you have laptops with radeon=20 > and entering S3 will sleep with backlight keeping on, > worth trying. >=20 > The patch is at=20 > http://www.init-main.com/radeontool.patch Works perfectly here. Now all I have to do is get it bound to Fn+F3.=20 Any chance you want to make this into a port? --=20 If I write a signature, my emails will appear more personalised. From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 18 22:20:39 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39D7716A41F for ; Thu, 18 Aug 2005 22:20:39 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3DD943D45 for ; Thu, 18 Aug 2005 22:20:38 +0000 (GMT) (envelope-from colazelli@gmail.com) Received: by wproxy.gmail.com with SMTP id i4so460246wra for ; Thu, 18 Aug 2005 15:20:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:cc:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=TLaVk/kb7h7WelfQ9tgVnGWz9D84gpjXv6uChS5KN65Z0Ip02R8+Wjdt8J6KLUpaNS9sKVUpPQrzRUTm6ueR2BzZqVm9PNLMshRsFw2zAVPgFmureH427+Kj5gsCcHbyc9Rfx2y/qfO5dnMRJckJquZtlzGthBCw7E3laYZpKQE= Received: by 10.54.43.63 with SMTP id q63mr1503837wrq; Thu, 18 Aug 2005 15:20:38 -0700 (PDT) Received: from localhost.localdomain ([200.158.148.119]) by mx.gmail.com with ESMTP id 6sm5709156wrl.2005.08.18.15.20.36; Thu, 18 Aug 2005 15:20:38 -0700 (PDT) From: Wesley Gentine To: Anish Mistry In-Reply-To: <200508181046.08517.amistry@am-productions.biz> References: <42FCFFAB.9060006@gmail.com> <4300E0D5.5090409@root.org> <200508181046.08517.amistry@am-productions.biz> Content-Type: text/plain Date: Thu, 18 Aug 2005 19:10:09 -0300 Message-Id: <1124403009.760.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_fujitsu doesnt work 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, 18 Aug 2005 22:20:39 -0000 Hello Anish! Unfortunally nothing works. Thanks, Wesley Gentine On Thu, 2005-08-18 at 10:46 -0400, Anish Mistry wrote: > On Tuesday 16 August 2005 11:01 pm, Wesley Gentine wrote: > > Thank you Nate! > > > > But, my acpi is FUJ FJNB18B as above: > > > > acpi0: on motherboard > > acpi0: Power Button (fixed) > > > > Thanks for all! > > > So is this working now for you? What functions work (eg. Backlight, > pointer enable,etc.)? What functions do not work? Let me know and > I'll try to fix the driver to handle your laptop. > > > Wesley > > > > On 8/15/05, Nate Lawson wrote: > > > Nate Lawson wrote: > > > >>>> Wesley Gentine wrote: > > > >>>>> I have a Fujitsu FmV Biblo MG50H (japanese) and I tried to > > > >>>>> compile acpi_fujitsu inside kernel and nothing happened. > > > >>>>> But loading kernel module I have the following output: > > > >>>>> > > > >>>>> acpi_fujitsu0: on acpi0 > > > >>>>> acpi_fujitsu0: Couldn't query volume level > > > >>>>> acpi_fujitsu0: Couldn't init button states > > > >>>>> acpi_fujitsu0: Couldn't initialize button states! > > > >> > > > >> Use this file: > > > >> http://crystalwall.sites.uol.com.br/fmv-mg50h.asl.html > > > > > > > > I don't see what's wrong. Your system has a FUJ02B1 device and > > > > that's what acpi_fujitsu looks for. Perhaps someone who has > > > > such a laptop can look at this further. You can also try > > > > inserting printfs in acpi_fujitsu_probe/attach() to see where > > > > the function is returning. > > > > > > > > Device (FJEX) > > > > { > > > > Name (_HID, "FUJ02B1") > > > > Method (_STA, 0, NotSerialized) > > > > { > > > > Return (0x0F) > > > > } > > > > > > I looked a little more. It appears that your device is detected > > > properly but acpi_fujitsu_update() is failing for some reason. > > > Your system doesn't support the GVOL method (volume control). > > > Just remove the first "return (FALSE)" line from > > > acpi_fujitsu_update() and it will continue to probe other things > > > even if it can't find volume control. > > > > > > -- > > > Nate > > > > _______________________________________________ > > 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" > From owner-freebsd-acpi@FreeBSD.ORG Thu Aug 18 22:28:30 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 946E816A41F for ; Thu, 18 Aug 2005 22:28:30 +0000 (GMT) (envelope-from nate@root.org) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AA1743D49 for ; Thu, 18 Aug 2005 22:28:27 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.33] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j7IMSMo5031350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Aug 2005 15:28:23 -0700 Message-ID: <43050B82.3000607@root.org> Date: Thu, 18 Aug 2005 15:28:18 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wesley Gentine References: <42FCFFAB.9060006@gmail.com> <4300E0D5.5090409@root.org> <200508181046.08517.amistry@am-productions.biz> <1124403009.760.2.camel@localhost> In-Reply-To: <1124403009.760.2.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, Anish Mistry Subject: Re: acpi_fujitsu doesnt work 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, 18 Aug 2005 22:28:30 -0000 Wesley Gentine wrote: > On Thu, 2005-08-18 at 10:46 -0400, Anish Mistry wrote: >>On Tuesday 16 August 2005 11:01 pm, Wesley Gentine wrote: >> >>>Thank you Nate! >>> >>>But, my acpi is FUJ FJNB18B as above: >>> >>>acpi0: on motherboard >>>acpi0: Power Button (fixed) >>> >>>Thanks for all! >>> >> >>So is this working now for you? What functions work (eg. Backlight, >>pointer enable,etc.)? What functions do not work? Let me know and >>I'll try to fix the driver to handle your laptop. >> >> > Unfortunally nothing works. > > Thanks, > > Wesley Gentine My suggestion only fixes the initial attach. I suspect something farther on during runtime operation is looking for the volume support and bailing out because it's not present. Anish, the problem is that his system doesn't have the volume methods (at least GVOL) so acpi_fujitsu_update() returns an error instead of just operating without volume control. A complete fix should make the rest of the driver operate even if volume control (or ideally any other) component is missing. -- Nate From owner-freebsd-acpi@FreeBSD.ORG Fri Aug 19 00:55:26 2005 Return-Path: X-Original-To: freebsd-acpi@freebsd.org Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BD7716A41F for ; Fri, 19 Aug 2005 00:55:26 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AC5743D45 for ; Fri, 19 Aug 2005 00:55:24 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.23] (andersonbox3.centtech.com [192.168.42.23]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j7J0tNxE047329; Thu, 18 Aug 2005 19:55:23 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <43052E0C.3050404@centtech.com> Date: Thu, 18 Aug 2005 19:55:40 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.10) Gecko/20050815 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Takanori Watanabe References: <200508181415.j7IEFEXY016065@ns.init-main.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/1034/Thu Aug 18 15:07:58 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-acpi@freebsd.org Subject: Re: Radeontool 1.5 for FreeBSD 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, 19 Aug 2005 00:55:26 -0000 Eric Kjeldergaard wrote: > On 8/18/05, Takanori Watanabe wrote: > >>Hi, I ported Radeontool-1.5 for FreeBSD. >> >>(http://fdd.com/software/radeon/) >>If you have laptops with radeon >>and entering S3 will sleep with backlight keeping on, >>worth trying. >> >>The patch is at >>http://www.init-main.com/radeontool.patch > > > Works perfectly here. Now all I have to do is get it bound to Fn+F3. > Any chance you want to make this into a port? Works great here too! Thanks Takanori! A port would be great.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-acpi@FreeBSD.ORG Sat Aug 20 10:26:32 2005 Return-Path: X-Original-To: acpi@freebsd.org Delivered-To: freebsd-acpi@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2BE516A41F for ; Sat, 20 Aug 2005 10:26:32 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D37443D48 for ; Sat, 20 Aug 2005 10:26:32 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:xczosiLDMGDfE5rnMn3MGJXBIxPofzEZVGOYeycdrfBBWEltOvyajCjTx1/Ybqe6@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j7KAQRn5091707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Aug 2005 19:26:27 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 20 Aug 2005 19:26:26 +0900 Message-ID: From: Hajimu UMEMOTO To: Nate Lawson In-Reply-To: References: <20050814023842.C0D845D07@ptavv.es.net> <4300C5DF.40409@root.org> <43013C90.7040901@root.org> <4302298F.6080407@root.org> User-Agent: xcite1.38> Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 6.0-BETA2 X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sat, 20 Aug 2005 19:26:27 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: acpi@freebsd.org Subject: Re: Annoyances with passive thermal code (acpi_thermal) 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, 20 Aug 2005 10:26:32 -0000 Hi, >>>>> On Thu, 18 Aug 2005 02:20:35 +0900 >>>>> Hajimu UMEMOTO said: > In anyway, we should make this as stack some day. nate> That would be nice for the future. ume> Okay, I'll implement this when I have a time. ume> How about this? ume> The original code allowed to restore a cpu level from ume> CPUFREQ_SET(NULL, prio) with any prio. I tought it is not ume> intentional. So, I changed to check if prio is at same one. I updated my patch to reflect recent fix to kern_cpu.c. Index: sys/kern/kern_cpu.c diff -u -p sys/kern/kern_cpu.c.orig sys/kern/kern_cpu.c --- sys/kern/kern_cpu.c.orig Fri Aug 19 01:45:53 2005 +++ sys/kern/kern_cpu.c Fri Aug 19 01:48:27 2005 @@ -57,12 +57,17 @@ __FBSDID("$FreeBSD: src/sys/kern/kern_cp */ #define CF_MAX_LEVELS 64 +struct cf_saved_freq { + struct cf_level level; + int priority; + SLIST_ENTRY(cf_saved_freq) link; +}; + struct cpufreq_softc { struct sx lock; struct cf_level curr_level; int curr_priority; - struct cf_level saved_level; - int saved_priority; + SLIST_HEAD(, cf_saved_freq) saved_freq; struct cf_level_lst all_levels; int all_count; int max_mhz; @@ -149,7 +154,7 @@ cpufreq_attach(device_t dev) TAILQ_INIT(&sc->all_levels); CF_MTX_INIT(&sc->lock); sc->curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; - sc->saved_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; + SLIST_INIT(&sc->saved_freq); sc->max_mhz = CPUFREQ_VAL_UNKNOWN; /* @@ -181,12 +186,18 @@ static int cpufreq_detach(device_t dev) { struct cpufreq_softc *sc; + struct cf_saved_freq *saved_freq; int numdevs; CF_DEBUG("shutdown %s\n", device_get_nameunit(dev)); sc = device_get_softc(dev); sysctl_ctx_free(&sc->sysctl_ctx); + while ((saved_freq = SLIST_FIRST(&sc->saved_freq)) != NULL) { + SLIST_REMOVE_HEAD(&sc->saved_freq, link); + free(saved_freq, M_TEMP); + } + /* Only clean up these resources when the last device is detaching. */ numdevs = devclass_get_count(cpufreq_dc); if (numdevs == 1) { @@ -208,12 +219,14 @@ cf_set_method(device_t dev, const struct { struct cpufreq_softc *sc; const struct cf_setting *set; + struct cf_saved_freq *saved_freq, *curr_freq; struct pcpu *pc; int cpu_id, error, i; sc = device_get_softc(dev); error = 0; set = NULL; + saved_freq = NULL; /* * Check that the TSC isn't being used as a timecounter. @@ -223,29 +236,34 @@ cf_set_method(device_t dev, const struct if (strcmp(timecounter->tc_name, "TSC") == 0) return (EBUSY); + CF_MTX_LOCK(&sc->lock); + + /* + * If the requested level has a lower priority, don't allow + * the new level right now. + */ + if (priority < sc->curr_priority) { + CF_DEBUG("ignoring, curr prio %d less than %d\n", priority, + sc->curr_priority); + error = EPERM; + goto out; + } + /* * If the caller didn't specify a level and one is saved, prepare to * restore the saved level. If none has been saved, return an error. - * If they did specify one, but the requested level has a lower - * priority, don't allow the new level right now. */ - CF_MTX_LOCK(&sc->lock); if (level == NULL) { - if (sc->saved_level.total_set.freq != CPUFREQ_VAL_UNKNOWN) { - level = &sc->saved_level; - priority = sc->saved_priority; - CF_DEBUG("restoring saved level, freq %d prio %d\n", - level->total_set.freq, priority); - } else { + saved_freq = SLIST_FIRST(&sc->saved_freq); + if (saved_freq == NULL) { CF_DEBUG("NULL level, no saved level\n"); error = ENXIO; goto out; } - } else if (priority < sc->curr_priority) { - CF_DEBUG("ignoring, curr prio %d less than %d\n", priority, - sc->curr_priority); - error = EPERM; - goto out; + level = &saved_freq->level; + priority = saved_freq->priority; + CF_DEBUG("restoring saved level, freq %d prio %d\n", + level->total_set.freq, priority); } /* Reject levels that are below our specified threshold. */ @@ -323,28 +341,33 @@ cf_set_method(device_t dev, const struct } skip: - /* If we were restoring a saved state, reset it to "unused". */ - if (level == &sc->saved_level) { - CF_DEBUG("resetting saved level\n"); - sc->saved_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; - sc->saved_priority = 0; - } - /* * Before recording the current level, check if we're going to a - * higher priority and have not saved a level yet. If so, save the - * previous level and priority. + * higher priority. If so, save the previous level and priority. */ if (sc->curr_level.total_set.freq != CPUFREQ_VAL_UNKNOWN && - sc->saved_level.total_set.freq == CPUFREQ_VAL_UNKNOWN && - priority > CPUFREQ_PRIO_USER && priority > sc->curr_priority) { + priority > sc->curr_priority) { CF_DEBUG("saving level, freq %d prio %d\n", sc->curr_level.total_set.freq, sc->curr_priority); - sc->saved_level = sc->curr_level; - sc->saved_priority = sc->curr_priority; + curr_freq = malloc(sizeof(*curr_freq), M_TEMP, M_NOWAIT); + if (curr_freq == NULL) { + error = ENOMEM; + goto out; + } + curr_freq->level = sc->curr_level; + curr_freq->priority = sc->curr_priority; + SLIST_INSERT_HEAD(&sc->saved_freq, curr_freq, link); } sc->curr_level = *level; sc->curr_priority = priority; + + /* If we were restoring a saved state, reset it to "unused". */ + if (saved_freq != NULL) { + CF_DEBUG("resetting saved level\n"); + sc->curr_level.total_set.freq = CPUFREQ_VAL_UNKNOWN; + SLIST_REMOVE_HEAD(&sc->saved_freq, link); + free(saved_freq, M_TEMP); + } out: CF_MTX_UNLOCK(&sc->lock); Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/