From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 4 08:55:14 2011 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 587171065679 for ; Mon, 4 Jul 2011 08:55:14 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BDDBB8FC1F for ; Mon, 4 Jul 2011 08:55:12 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA12770; Mon, 04 Jul 2011 11:55:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Qdevq-000P6S-Q8; Mon, 04 Jul 2011 11:55:06 +0300 Message-ID: <4E117FE8.9030703@FreeBSD.org> Date: Mon, 04 Jul 2011 11:55:04 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110626 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Ed VanderPloeg References: <4E0A50AA.5000003@agile.bc.ca> <4E0AF27B.3030600@FreeBSD.org> <4E0B6873.6010901@agile.bc.ca> <4E0B80BE.6080605@FreeBSD.org> <4E0CA533.5030104@agile.bc.ca> <4E0CE39C.5050307@FreeBSD.org> <4E0D4A15.6000904@agile.bc.ca> <4E0D5EA0.1020704@FreeBSD.org> <4E0E7F91.2050408@agile.bc.ca> In-Reply-To: <4E0E7F91.2050408@agile.bc.ca> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: Atom N270 - ACPI Error: [RTMP] Namespace lookup failure 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, 04 Jul 2011 08:55:14 -0000 on 02/07/2011 05:16 Ed VanderPloeg said the following: > > # egrep '(^| )est' dmesg.8-release > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 60f0c270600060f > device_attach: est0 attach returned 6 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 60f0c270600060f > device_attach: est1 attach returned 6 > > # egrep '(^| )est' dmesg.8-stable > est0: on cpu0 > est1: on cpu1 So this was improved. Thanks! -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Mon Jul 4 11:06:56 2011 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 D4BE8106567E for ; Mon, 4 Jul 2011 11:06:56 +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 C28AE8FC1F for ; Mon, 4 Jul 2011 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p64B6uLO040356 for ; Mon, 4 Jul 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p64B6uhC040352 for freebsd-acpi@FreeBSD.org; Mon, 4 Jul 2011 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 4 Jul 2011 11:06:56 GMT Message-Id: <201107041106.p64B6uhC040352@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, 04 Jul 2011 11:06:57 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/144045 acpi [acpi] [panic] kernel trap with acpi enabled o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142263 acpi [acpi] ACPI regression on Asus K8N7-E deluxe motherboa o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o amd64/140751 acpi [acpi] BIOS resource allocation and FreeBSD ACPI in TO o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o bin/137053 acpi [hang] FreeBSD 8.0 BETA2Compaq Mini 700 locks on boot o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not o kern/130683 acpi [ACPI] shutdown hangs after syncing disks - ACPI race? o i386/129953 acpi [acpi] ACPI timeout (CDROM) with Shuttle X27D p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o kern/124412 acpi [acpi] power off error on Toshiba M40 laptop o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot o kern/121504 acpi [patch] Correctly set hw.acpi.osname on certain machin f kern/119356 acpi [acpi]: i386 ACPI wakeup not work due resource exhaust o kern/119200 acpi [acpi] Lid close switch suspends CPU for 1 second on H o kern/116939 acpi [acpi] PCI-to-PCI misconfigured for bus three and can o i386/114562 acpi [acpi] cardbus is dead after s3 on Thinkpad T43 with a o kern/114165 acpi [acpi] Dell C810 - ACPI problem s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/108695 acpi [acpi]: Fatal trap 9: general protection fault when in o kern/108488 acpi [acpi] ACPI-1304: *** Error: Method execution failed o kern/106924 acpi [acpi] ACPI resume returns g_vfs_done() errors and ker o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/102252 acpi acpi thermal does not work on Abit AW8D (intel 975) o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o i386/83018 acpi [install] Installer will not boot on Asus P4S8X BIOS 1 o kern/73823 acpi [request] acpi / power-on by timer support o i386/69750 acpi Boot without ACPI failed on ASUS L5 o kern/56024 acpi ACPI suspend drains battery while in S3 o i386/55661 acpi ACPI suspend/resume problem on ARMADA M700 41 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 5 12:19:35 2011 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 9FAAD1065670 for ; Tue, 5 Jul 2011 12:19:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E7F328FC21 for ; Tue, 5 Jul 2011 12:19:34 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA09030; Tue, 05 Jul 2011 15:19:32 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E130154.9080809@FreeBSD.org> Date: Tue, 05 Jul 2011 15:19:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.18) Gecko/20110622 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Vitaly Magerya References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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, 05 Jul 2011 12:19:35 -0000 on 02/07/2011 23:30 Vitaly Magerya said the following: > Andriy Gapon wrote: >>> VDRV: 00 -> 01 >> >> Looks like this variable should tell if OS has ACPI Video driver, to be precise >> if _BCL method was invoked at least once. >> Looks like in your case the driver doesn't attach for some reason?.. > > I don't have acpi_video loaded (it's not loaded by default). If I > do load it, VDRV indeed becomes 1 (brightness controls that acpi_video > exposes don't work though; this appears to be a known problem with > Samsung laptops). This might warrant a separate investigation and a PR if we don't have one already. Not sure if I could be of help with it, though. >> Actually, it seems that they have them simply hardcoded: >> http://lxr.linux.no/#linux+v2.6.39/drivers/idle/intel_idle.c#L171 >> I am not sure how to check on Linux which cpuidle driver is being used. If you >> know, could please check that? And if the driver is intel_idle, then there is >> no mystery, they use those hardcoded values. > > I think the mystery is solved then: > > $ cat /sys/devices/system/cpu/cpuidle/current_driver > intel_idle Possible courses of action: 1. Do nothing and leave you with your workaround. 2. Provide intel_idle-like driver for FreeBSD. I don't like this approach for reasons I've stated before. 3. Try to make FreeBSD smarter with respect to dynamically changing C-states. I think it would be useful if we received a devd notifications about C-state reconfiguration. Then we could execute /etc/rc.d/power_profile to account for the new configuration. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Tue Jul 5 21:49:20 2011 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 5298D106566C; Tue, 5 Jul 2011 21:49:20 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id E5C478FC0A; Tue, 5 Jul 2011 21:49:19 +0000 (UTC) Received: by vxg33 with SMTP id 33so6207045vxg.13 for ; Tue, 05 Jul 2011 14:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VXAo4sG/7dqv0ybKRnaWTtpU8/B+hOmgCKK3wHpKWVI=; b=ZqxOQoPwZIVyp7MJ7prJNX5o0q7bQ9+R6KF5FbCqQPYdklDba+LjeL+6TQRVNf1QSZ xbOHU4UU1DNgyOFIqmPpCBAOEaZiIe0Y3v7fMw5ZfsGAVaYEw80RS2rNcaVMq1k3gXWb cP9AJgemcCnDGNhoeMfqqOsnppRjnjmorOEbg= MIME-Version: 1.0 Received: by 10.52.110.133 with SMTP id ia5mr1027478vdb.239.1309902558090; Tue, 05 Jul 2011 14:49:18 -0700 (PDT) Received: by 10.52.108.226 with HTTP; Tue, 5 Jul 2011 14:49:18 -0700 (PDT) In-Reply-To: <4E130154.9080809@FreeBSD.org> References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> <4E130154.9080809@FreeBSD.org> Date: Wed, 6 Jul 2011 00:49:18 +0300 Message-ID: From: Vitaly Magerya To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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, 05 Jul 2011 21:49:20 -0000 Andriy Gapon wrote: >> I don't have acpi_video loaded (it's not loaded by default). If I >> do load it, VDRV indeed becomes 1 (brightness controls that acpi_video >> exposes don't work though; this appears to be a known problem with >> Samsung laptops). > > This might warrant a separate investigation and a PR if we don't have one already. > Not sure if I could be of help with it, though. >From what I heard this isn't a problem with FreeBSD ACPI code, it's a problem with Samsung firmware. AFAIK to get brightness controls working on Windows you need to setup Samsung software that uses undocument BIOS interface for it's function. Linux has what appears to be a reverse-engineered driver [1] that does the same. Someone (probably me) needs to port it. > Possible courses of action: > > 1. Do nothing and leave you with your workaround. > > 2. Provide intel_idle-like driver for FreeBSD. I don't like this approach for > reasons I've stated before. > > 3. Try to make FreeBSD smarter with respect to dynamically changing C-states. I > think it would be useful if we received a devd notifications about C-state > reconfiguration. Then we could execute /etc/rc.d/power_profile to account for the > new configuration. This would be the most useful option. Here's what I tried (trivial diff, sending inline): --- acpi_cpu.c.orig 2011-07-05 19:50:31.000000000 +0000 +++ acpi_cpu.c 2011-07-05 21:44:56.000000000 +0000 @@ -988,12 +988,13 @@ { struct acpi_cpu_softc *sc = (struct acpi_cpu_softc *)context; struct acpi_cpu_softc *isc; - int i; + int prev_cx_count, i; if (notify != ACPI_NOTIFY_CX_STATES) return; /* Update the list of Cx states. */ + prev_cx_count = sc->cpu_cx_count; acpi_cpu_cx_cst(sc); acpi_cpu_cx_list(sc); @@ -1008,6 +1009,8 @@ if (sc->cpu_cx_lowest < cpu_cx_lowest) acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc->cpu_cx_count - 1)); ACPI_SERIAL_END(cpu); + if (prev_cx_count != sc->cpu_cx_count) + acpi_UserNotify("CPU_CX", h, sc->cpu_cx_count); } static int --- devd.conf.orig 2011-07-05 20:19:30.000000000 +0000 +++ devd.conf 2011-07-05 20:30:08.000000000 +0000 @@ -209,6 +209,13 @@ action "/etc/rc.d/power_profile $notify"; }; +# Update power profile when available CPU Cx states are updated. +notify 10 { + match "system" "ACPI"; + match "subsystem" "CPU_CX"; + action "/etc/rc.d/power_profile 0x0`sysctl -n hw.acpi.acline`"; +}; + # Notify all users before beginning emergency shutdown when we get # a _CRT or _HOT thermal event and we're going to power down the system # very soon. This generally works, except that power_profile is executed multiple times (the event is generated once per core, and when it is triggered by plugging the power cord, ACPI ACAD is reported at the same time thus resulting in one more power_profile execution). [1] http://lxr.linux.no/#/drivers/platform/x86/samsung-laptop.c From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 6 14:06:42 2011 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 610F51065673 for ; Wed, 6 Jul 2011 14:06:42 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A72478FC0C for ; Wed, 6 Jul 2011 14:06:41 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00622; Wed, 06 Jul 2011 17:06:38 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E146BEE.1060404@FreeBSD.org> Date: Wed, 06 Jul 2011 17:06:38 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Vitaly Magerya References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> <4E130154.9080809@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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, 06 Jul 2011 14:06:42 -0000 on 06/07/2011 00:49 Vitaly Magerya said the following: > Andriy Gapon wrote: >>> I don't have acpi_video loaded (it's not loaded by default). If I >>> do load it, VDRV indeed becomes 1 (brightness controls that acpi_video >>> exposes don't work though; this appears to be a known problem with >>> Samsung laptops). >> >> This might warrant a separate investigation and a PR if we don't have one already. >> Not sure if I could be of help with it, though. > > From what I heard this isn't a problem with FreeBSD ACPI code, it's > a problem with Samsung firmware. AFAIK to get brightness controls > working on Windows you need to setup Samsung software that uses > undocument BIOS interface for it's function. > > Linux has what appears to be a reverse-engineered driver [1] that > does the same. Someone (probably me) needs to port it. Maybe, maybe not... Can you please verify which driver Linux actually uses on your system? I see that ACPI does export all the necessary methods for brightness controls, although there seem to be some strangeness in the code (annotations are mine): Method (_BCL, 0, NotSerialized) { Or (VDRV, 0x01, VDRV) Return (Package (0x08) { 0x64, // 100 // level when machine has full power 0x05, // 5 // level when machine is on batteries // other supported levels: 0x0F, // 15 0x18, // 24 0x1E, // 30 0x2D, // 45 0x3C, // 50 0x50 // 80 }) } First, please note that the default levels are not among "other supported" levels. They are not required to be, but frequently they are. Method (_BCM, 1, NotSerialized) { // Local0 = Arg0 % 10; // Local1 = Arg0 / 10; Divide (Arg0, 0x0A, Local0, Local1) If (LEqual (Local0, 0x00)) { BRTW (Arg0) } } Note here that _BCM would accept only levels that multiple of 10, but levels listed by _BCL are not all multiples of 10. Bug? Method (_BQC, 0, NotSerialized) { // Local0 = Arg0 % 10; // Local1 = Arg0 / 10; Divide (BRTL, 0x0A, Local0, Local1) If (LEqual (Local0, 0x00)) { Return (BRTL) } Again, _BQC would return a current level value (in BRTL) only if it is a multiple of 10. There is no return statement for the other case, I assume that zero is returned in that case. So I can see how this behavior can easily confuse our acpi_video driver. I see that Linux acpi video driver has some quirks in it, but not sure if it is able to handle this kind of issues. I would doubt that. Maybe you would feel adventurous enough to experiment with hacking your DSDT some more. For a start I would just try to remove that level % 10 == 0 check. But wait... those acpi video methods are defined in Device DD04, but you reported that NDID=2 in GNVS, so only devices DD01 and DD02 should be reported via _DOD. But then DID2 == DID4, so DD02 and DD04 have the same address and acpi_video uses DD04 as well. And here I become totally confused as I haven't expected two devices to report the same address. But enough for me to talk about this :) -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 6 14:23:27 2011 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 992D0106566B for ; Wed, 6 Jul 2011 14:23:27 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id BB1FA8FC13 for ; Wed, 6 Jul 2011 14:23:26 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA00845; Wed, 06 Jul 2011 17:23:24 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E146FDB.2020602@FreeBSD.org> Date: Wed, 06 Jul 2011 17:23:23 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Vitaly Magerya References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> <4E130154.9080809@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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, 06 Jul 2011 14:23:27 -0000 on 06/07/2011 00:49 Vitaly Magerya said the following: > Andriy Gapon wrote: >> Possible courses of action: >> >> 1. Do nothing and leave you with your workaround. >> >> 2. Provide intel_idle-like driver for FreeBSD. I don't like this approach for >> reasons I've stated before. >> >> 3. Try to make FreeBSD smarter with respect to dynamically changing C-states. I >> think it would be useful if we received a devd notifications about C-state >> reconfiguration. Then we could execute /etc/rc.d/power_profile to account for the >> new configuration. > > This would be the most useful option. I agree! :) > Here's what I tried (trivial diff, sending inline): > > --- acpi_cpu.c.orig 2011-07-05 19:50:31.000000000 +0000 > +++ acpi_cpu.c 2011-07-05 21:44:56.000000000 +0000 > @@ -988,12 +988,13 @@ > { > struct acpi_cpu_softc *sc = (struct acpi_cpu_softc *)context; > struct acpi_cpu_softc *isc; > - int i; > + int prev_cx_count, i; > > if (notify != ACPI_NOTIFY_CX_STATES) > return; > > /* Update the list of Cx states. */ > + prev_cx_count = sc->cpu_cx_count; > acpi_cpu_cx_cst(sc); > acpi_cpu_cx_list(sc); > > @@ -1008,6 +1009,8 @@ > if (sc->cpu_cx_lowest < cpu_cx_lowest) > acpi_cpu_set_cx_lowest(sc, min(cpu_cx_lowest, sc->cpu_cx_count - 1)); > ACPI_SERIAL_END(cpu); > + if (prev_cx_count != sc->cpu_cx_count) > + acpi_UserNotify("CPU_CX", h, sc->cpu_cx_count); > } > > static int > --- devd.conf.orig 2011-07-05 20:19:30.000000000 +0000 > +++ devd.conf 2011-07-05 20:30:08.000000000 +0000 > @@ -209,6 +209,13 @@ > action "/etc/rc.d/power_profile $notify"; > }; > > +# Update power profile when available CPU Cx states are updated. > +notify 10 { > + match "system" "ACPI"; > + match "subsystem" "CPU_CX"; > + action "/etc/rc.d/power_profile 0x0`sysctl -n hw.acpi.acline`"; > +}; > + > # Notify all users before beginning emergency shutdown when we get > # a _CRT or _HOT thermal event and we're going to power down the system > # very soon. > > This generally works, except that power_profile is executed multiple > times (the event is generated once per core, and when it is triggered > by plugging the power cord, ACPI ACAD is reported at the same time > thus resulting in one more power_profile execution). At this time and for this purpose I would probably send the notification only if global cx_lowest value changes as we do not do per-CPU power profiles. Also, I think that cpu_cx_count is not the best parameter for notification. For per-cpu events I would rather use CPU ID. For global events, it may makes sense to use /subsystem/ value of "CPU" and then discriminate various types of CPU events via /notify/. E.g. notify=0 could be used to indicate Cx changes. Maybe we will have more ACPI CPU events in the future. Otherwise I really like this, thank you. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 6 19:20:25 2011 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 E3B6A1065672; Wed, 6 Jul 2011 19:20:24 +0000 (UTC) (envelope-from vmagerya@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 82AA48FC16; Wed, 6 Jul 2011 19:20:24 +0000 (UTC) Received: by vxg33 with SMTP id 33so244126vxg.13 for ; Wed, 06 Jul 2011 12:20:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iTHQVoLL7fhThrK5od9+5aEC8H21dXCSpiOIaLzYG+M=; b=o2a8v1R3fnuNm2euLp+Bkm58q3afaSEzXa2VGyG2hEE5lVvCPyi0wJm71vxUOJ4jJZ ttTpeVfBm3SiHUrBZE/3Do2+/ta83h+vqvS0BNhR8QXukbB+A/zHTzCOv3jmxWAdT+yR PNouY/281RYqMHcC1EhG61ly7lgY0Jd0wal9Y= MIME-Version: 1.0 Received: by 10.52.66.199 with SMTP id h7mr2119434vdt.119.1309980023584; Wed, 06 Jul 2011 12:20:23 -0700 (PDT) Received: by 10.52.108.226 with HTTP; Wed, 6 Jul 2011 12:20:22 -0700 (PDT) In-Reply-To: <4E146FDB.2020602@FreeBSD.org> References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> <4E130154.9080809@FreeBSD.org> <4E146FDB.2020602@FreeBSD.org> Date: Wed, 6 Jul 2011 22:20:22 +0300 Message-ID: From: Vitaly Magerya To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-acpi@freebsd.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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, 06 Jul 2011 19:20:25 -0000 Andriy Gapon wrote: >>> 3. Try to make FreeBSD smarter with respect to dynamically changing >>> C-states. I >>> think it would be useful if we received a devd notifications about >>> C-state >>> reconfiguration. Then we could execute /etc/rc.d/power_profile to >>> account for the >>> new configuration. >> >> This would be the most useful option. > > I agree! :) Actually, I have a simpler fix. We could allow setting hw.acpi.cx_lowest to any value, including states that are not currently present. Then, on updates to available Cx states, our ACPI code will automatically set dev.cpu.N.cx_lowest to the closest valid value without the need for a separate power_profile invocation. Here's the diff: --- acpi_cpu.c.orig 2011-07-05 19:50:31.000000000 +0000 +++ acpi_cpu.c 2011-07-06 17:23:16.000000000 +0000 @@ -1194,7 +1194,7 @@ if (strlen(state) < 2 || toupper(state[0]) != 'C') return (EINVAL); val = (int) strtol(state + 1, NULL, 10) - 1; - if (val < 0 || val > cpu_cx_count - 1) + if (val < 0) return (EINVAL); cpu_cx_lowest = val; You can even simplify power_profile with this change: --- power_profile.orig 2011-07-06 18:39:27.000000000 +0000 +++ power_profile 2011-07-06 18:40:20.000000000 +0000 @@ -81,8 +81,7 @@ # Set the various sysctls based on the profile's values. node="hw.acpi.cpu.cx_lowest" highest_value="C1" -lowest_value="`(sysctl -n dev.cpu.0.cx_supported | \ - awk '{ print "C" split($0, a) }' -) 2> /dev/null`" +lowest_value="C99" eval value=\$${profile}_cx_lowest sysctl_set >> Here's what I tried (trivial diff, sending inline): >> >> [...] >> >> This generally works, except that power_profile is executed multiple >> times (the event is generated once per core, and when it is triggered >> by plugging the power cord, ACPI ACAD is reported at the same time >> thus resulting in one more power_profile execution). > > At this time and for this purpose I would probably send the notification only if > global cx_lowest value changes as we do not do per-CPU power profiles. Yes, this makes sense. > Also, I think that cpu_cx_count is not the best parameter for notification. > For per-cpu events I would rather use CPU ID. For global events, it may makes > sense to use /subsystem/ value of "CPU" and then discriminate various types of CPU > events via /notify/. E.g. notify=0 could be used to indicate Cx changes. Maybe > we will have more ACPI CPU events in the future. Seems reasonable too, but this won't be necessary for my case if the above change will be implemented. From owner-freebsd-acpi@FreeBSD.ORG Wed Jul 6 21:49:12 2011 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 5B7871065670; Wed, 6 Jul 2011 21:49:12 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 32FB58FC0A; Wed, 6 Jul 2011 21:49:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p66LnC3u056638; Wed, 6 Jul 2011 21:49:12 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p66LnCVg056634; Wed, 6 Jul 2011 21:49:12 GMT (envelope-from linimon) Date: Wed, 6 Jul 2011 21:49:12 GMT Message-Id: <201107062149.p66LnCVg056634@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-acpi@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/158689: [acpi] value of sysctl hw.acpi.thermal.polling_rate needs validation 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, 06 Jul 2011 21:49:12 -0000 Synopsis: [acpi] value of sysctl hw.acpi.thermal.polling_rate needs validation Responsible-Changed-From-To: freebsd-bugs->freebsd-acpi Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jul 6 21:49:03 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=158689 From owner-freebsd-acpi@FreeBSD.ORG Fri Jul 8 12:20:50 2011 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 57D091065670 for ; Fri, 8 Jul 2011 12:20:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9E8588FC0A for ; Fri, 8 Jul 2011 12:20:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA11461; Fri, 08 Jul 2011 15:20:47 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4E16F61E.80201@FreeBSD.org> Date: Fri, 08 Jul 2011 15:20:46 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:5.0) Gecko/20110705 Thunderbird/5.0 MIME-Version: 1.0 To: Vitaly Magerya References: <4E05EB91.9090509@FreeBSD.org> <4E0862A0.7060405@FreeBSD.org> <4E09BADF.7050702@FreeBSD.org> <4E0A41C8.3000904@FreeBSD.org> <4E0CE158.6030804@FreeBSD.org> <4E0DB58F.4070906@FreeBSD.org> <4E130154.9080809@FreeBSD.org> <4E146FDB.2020602@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.2pre Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@FreeBSD.org Subject: Re: (Missing) power states of an Atom N455-based netbook 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, 08 Jul 2011 12:20:50 -0000 on 06/07/2011 22:20 Vitaly Magerya said the following: > Actually, I have a simpler fix. We could allow setting hw.acpi.cx_lowest > to any value, including states that are not currently present. Then, > on updates to available Cx states, our ACPI code will automatically > set dev.cpu.N.cx_lowest to the closest valid value without the need > for a separate power_profile invocation. > > Here's the diff: > > --- acpi_cpu.c.orig 2011-07-05 19:50:31.000000000 +0000 > +++ acpi_cpu.c 2011-07-06 17:23:16.000000000 +0000 > @@ -1194,7 +1194,7 @@ > if (strlen(state) < 2 || toupper(state[0]) != 'C') > return (EINVAL); > val = (int) strtol(state + 1, NULL, 10) - 1; > - if (val < 0 || val > cpu_cx_count - 1) > + if (val < 0) > return (EINVAL); > cpu_cx_lowest = val; This change is a little bit more intrusive than I would like. There are some things about cpu_cx_lowest handling in the code that make me a bit unsure if this change is completely safe. I suspect that there could be problems on systems where number Cx states becomes smaller after some events (e.g. AC connection). I would prefer other developers to also comment on this. Maybe it's worth while opening a PR for this proposed change. > You can even simplify power_profile with this change: > > --- power_profile.orig 2011-07-06 18:39:27.000000000 +0000 > +++ power_profile 2011-07-06 18:40:20.000000000 +0000 > @@ -81,8 +81,7 @@ > # Set the various sysctls based on the profile's values. > node="hw.acpi.cpu.cx_lowest" > highest_value="C1" > -lowest_value="`(sysctl -n dev.cpu.0.cx_supported | \ > - awk '{ print "C" split($0, a) }' -) 2> /dev/null`" > +lowest_value="C99" > eval value=\$${profile}_cx_lowest > sysctl_set C99 looks too scary (and too familiar) :-) I think that C6 would be sufficient here. -- Andriy Gapon