From owner-freebsd-acpi@FreeBSD.ORG Mon Oct 1 11:07:12 2012 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 0DEE91065677 for ; Mon, 1 Oct 2012 11:07:12 +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 D38368FC18 for ; Mon, 1 Oct 2012 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q91B7BFZ024890 for ; Mon, 1 Oct 2012 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q91B7BkF024888 for freebsd-acpi@FreeBSD.org; Mon, 1 Oct 2012 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Oct 2012 11:07:11 GMT Message-Id: <201210011107.q91B7BkF024888@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, 01 Oct 2012 11:07:12 -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/171305 acpi [acpi] acpi_tz0: _CRT value is absurd, ignored (256.0C o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] fix driver detach in absence of CMI o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne 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/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject 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 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 kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o bin/126162 acpi [acpi] ACPI autoload failed : loading required module o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/91594 acpi [acpi] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support o kern/56024 acpi ACPI suspend drains battery while in S3 31 problems total. From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 2 17:18:53 2012 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 3E22210656B6; Tue, 2 Oct 2012 17:18:53 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id A15948FC1A; Tue, 2 Oct 2012 17:18:52 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q92HIXI1028346; Tue, 2 Oct 2012 10:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1349198314; bh=U30aL2+xNZOPbtnFuzOnw7Lbps+5eJAe3mz/MQRalOU=; h=Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type: Date:Message-ID:Mime-Version:Content-Transfer-Encoding; b=upLZFhJLggiQ6i4UH0xIIylXQEw4fuOeW1j7Q/uLEJEjc6UK501Y5b7gXidjtQQf7 XOodWA9/tUUjJt19mB7fmQQb45fZ/5IcYI8mf2bnqK1u1yCaqLqEaZiDDWtPhCdZJa FRlRmtuP4LNSFHjVLxxg/VwXbFYZNFd6Irjgks8M= From: Sean Bruno To: Andriy Gapon In-Reply-To: <504EDBEB.6010104@FreeBSD.org> References: <504EDBEB.6010104@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Tue, 02 Oct 2012 10:18:33 -0700 Message-ID: <1349198313.4246.3.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 198313001 Cc: "freebsd-acpi@freebsd.org" Subject: Re: notify userland about C-state changes X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:18:53 -0000 > The following patch adds only per-CPU notifications. > > acpi_cpu: explicitly notify userland about c-state changes > > diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c > index 82e204a..15201f9 100644 > --- a/sys/dev/acpica/acpi_cpu.c > +++ b/sys/dev/acpica/acpi_cpu.c > @@ -1054,6 +1054,8 @@ acpi_cpu_notify(ACPI_HANDLE h, UINT32 notify, void *context) > ACPI_SERIAL_BEGIN(cpu); > acpi_cpu_set_cx_lowest(sc); > ACPI_SERIAL_END(cpu); > + > + acpi_UserNotify("PROCESSOR", sc->cpu_handle, notify); > } > > static int > So quick question, does this happen a lot on a system with a sporadic workload? Does this introduce overhead to the system to service the notification requests? Sean From owner-freebsd-acpi@FreeBSD.ORG Tue Oct 2 23:24:21 2012 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 4AF09106564A for ; Tue, 2 Oct 2012 23:24:21 +0000 (UTC) (envelope-from root@centos5.fkeinternet.com) Received: from centos5.fkeinternet.com (bluedenimminis.com [216.154.215.239]) by mx1.freebsd.org (Postfix) with ESMTP id F2BE68FC0C for ; Tue, 2 Oct 2012 23:24:20 +0000 (UTC) Received-SPF: pass (centos5.fkeinternet.com: domain of root@centos5.fkeinternet.com designates 127.0.0.1 as permitted sender) receiver=centos5.fkeinternet.com; client-ip=127.0.0.1; helo=centos5.fkeinternet.com; envelope-from=root@centos5.fkeinternet.com; x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with libspf2-1.0.0; Received: from centos5.fkeinternet.com (localhost.localdomain [127.0.0.1]) by centos5.fkeinternet.com (8.14.4/8.14.3) with ESMTP id q92NBK1u030044 for ; Tue, 2 Oct 2012 19:11:20 -0400 Received: (from root@localhost) by centos5.fkeinternet.com (8.14.4/8.14.4/Submit) id q92NBKqx030043 for freebsd-acpi@freebsd.org; Tue, 2 Oct 2012 19:11:20 -0400 Date: Tue, 2 Oct 2012 19:11:20 -0400 Message-Id: <201210022311.q92NBKqx030043@centos5.fkeinternet.com> To: freebsd-acpi@freebsd.org Original-To: freebsd-acpi@freebsd.org From: "Fred Koschara" Sender: wfredk@wfredk.com Subject: eBay rule changes that affect *YOU* - important information - PLEASE READ!! X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wfredk@wfredk.com List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 23:24:21 -0000 NOTE: THIS IS TIME CRITICAL INFORMATION - PLEASE READ THIS NOW! On August 22, 2012, I received a message from eBay entitled "Updates to the eBay User Agreement and Privacy Policy" which had several paragraphs summarizing changes in place for new users and that will be going into effect for existing users on October 10. Two of those paragraphs, in particular, caught my attention as being questionably acceptable: "Pursuant to the eBay User Agreement, you agree that eBay, its affiliates, agents, and independent contractors may contact you at any telephone number you provide to us or from which you place a call to us, or any telephone number at which we reasonably believe we may reach you, using any means of communication, including calls or text messages using an automatic telephone dialing system and/or prerecorded messages, even if you incur charges for receiving such communications." and "The User Agreement contains an Agreement to Arbitrate, which will, with limited exception, require you and eBay to submit claims to binding and final arbitration, unless you opt-out of the Agreement to Arbitrate by November 9, 2012. Unless you opt-out: (1) you will only be permitted to pursue claims against eBay on an individual basis, not as part of any class or representative action or proceeding and (2) you will only be permitted to seek relief (including monetary, injunctive, and declaratory relief) on an individual basis." Have you thought about these eBay rule changes set to go into effect on Oct. 10? In particular, consider this clause: "you agree that eBay, its affiliates, agents, and independent contractors may contact you at any telephone number you provide to us or from which you place a call to us, or any telephone number at which we reasonably believe we may reach you, using any means of communication, including calls or text messages using an automatic telephone dialing system and/or prerecorded messages, even if you incur charges for receiving such communications" What this means is that if you call from someone else's phone, eBay or anybody who gets their user list ("affiliates, agents, and independent contractors") can run up that person's phone bill using automated systems - and you gave them permission to do it - not to mention they can do the same to you. Let's say you've gone to visit your elderly grandmother, who lives on a fixed income. She has a cell phone with limited minutes to use to talk to family members, and for emergency calls. You check one of your eBay listings using your laptop and find it's not being properly displayed, but your cell phone is out in the car. Grandma says she still has lots of minutes on her phone, and you call eBay to discuss the problem. It turns out to be a quick call, so you think there's no problem. About a month later, Grandma starts getting pre-recorded marketing phone calls from an "eBay affiliate." She waits (using up additional minutes) until they stop talking so she can leave a message to tell them to stop calling you on her phone, but her request is ignored. Halfway through the fifth call, she runs out of minutes for the month. That evening, she falls down and breaks her hip. Now what happens to Grandma - because eBay had permission to use up her minutes because you called from her phone? This rule change has to be stopped before it goes into effect! If you are an eBay user, send them a message saying that clause *MUST* be struck from the user agreement before October 10 or you will close your account. (I've included the text of the message *I* am sending at the end of this email.) If you know anybody in the press, tell them about the proposed rule change (forward this email message, if you wish). If you know a lawyer interested in pursuing a class action suit to stop it, tell them about it, too. Call your Congressman and Senator - do anything you think of that can be used as reasonable leverage to apply pressure against eBay to insure they remove this destruction of civil rights from their user agreement. ...and forward this message to everybody you have an email address for! The clause prohibiting you from participating in a class action lawsuit against eBay is probably not as dangerous, and it also gives you a choice in the matter: If you follow the link in the original message, it takes you to the page at http://pages.ebay.com/help/policies/user-agreement.html#arbitrate where you find this information: "Opt-Out Procedure You can choose to reject this Agreement to Arbitrate ("opt-out") by mailing us a written opt-out notice ("Opt-Out Notice"). For new eBay users, the Opt-Out Notice must be postmarked no later than 30 days after the date you accept the User Agreement for the first time. If you are already a current eBay user and previously accepted the User Agreement prior to the introduction of this Agreement to Arbitrate, the Opt-Out Notice must be postmarked no later than November 9, 2012 . You must mail the Opt-Out Notice to eBay Inc., c/o National Registered Agents, Inc., 2778 W. Shady Bend Lane, Lehi, UT 84043. The Opt-Out Notice must state that you do not agree to this Agreement to Arbitrate and must include your name, address, and the user ID(s) and email address(es) associated with the eBay account(s) to which the opt-out applies. You must sign the Opt-Out Notice for it to be effective. This procedure is the only way you can opt-out of the Agreement to Arbitrate. If you opt-out of the Agreement to Arbitrate, all other parts of the User Agreement and its Legal Disputes Section will continue to apply to you. Opting out of this Agreement to Arbitrate has no effect on any previous, other, or future arbitration agreements that you may have with us." I suspect the timing of this "no class action participation" clause may be because eBay expects that when people realize what the "you can run up my phone bill" clause means, there will be calls for class action against them. In any case, giving up your right to seek restitution for damages is not a good idea, so I would *STRONGLY* suggest you follow the opt-out procedure they have specified. There are two deadlines here: On October 10, if eBay does not change their rules, "they" can start calling you, sending text messages, etc., even if it costs you money. On November 10, unless you opt out of eBay's Agreement to Arbitrate, you will lose your right to participate in class action suits against eBay. TIME IS SHORT, SO YOU NEED TO ACT *NOW* IF YOU WANT TO KEEP YOUR RIGHTS! Put eBay on notice, demand changes, and opt out of their Agreement to Arbitrate - Do it *TODAY*! Forward this message to everyone you have an email address for so that we have the largest group possible protesting this atrocity. -- Fred Koschara ============================================================================ Dear eBay: Please be advised that I find the proposed User Agreement changes due to go into effect on October 10, 2012 unacceptable. In particular, I find the clause stating "you agree that eBay, its affiliates, agents, and independent contractors may contact you at any telephone number you provide to us or from which you place a call to us, or any telephone number at which we reasonably believe we may reach you, using any means of communication, including calls or text messages using an automatic telephone dialing system and/or prerecorded messages, even if you incur charges for receiving such communications" to be a gross offense against myself and the public in general, and I demand it be removed *IMMEDIATELY* from the User Agreement. If you do not remove said clause from the User Agreement before it is set to go into effect on October 10, and have not advised me of the change in a timely manner, I will be terminating my membership in eBay effective 11:59PM on October 9, 2012, and I am advising everyone I know to do the same. Thank you for your prompt attention to this matter. -- Fred Koschara (trancetor) From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 13:08:33 2012 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 A5F3E106566B; Wed, 3 Oct 2012 13:08:33 +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 C31148FC0A; Wed, 3 Oct 2012 13:08:32 +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 QAA06176; Wed, 03 Oct 2012 16:08:30 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <506C38CE.4090400@FreeBSD.org> Date: Wed, 03 Oct 2012 16:08:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: sbruno@FreeBSD.org References: <504EDBEB.6010104@FreeBSD.org> <1349198313.4246.3.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1349198313.4246.3.camel@powernoodle.corp.yahoo.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-acpi@freebsd.org" , Sean Bruno Subject: Re: notify userland about C-state changes 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, 03 Oct 2012 13:08:33 -0000 on 02/10/2012 20:18 Sean Bruno said the following: > >> The following patch adds only per-CPU notifications. >> >> acpi_cpu: explicitly notify userland about c-state changes >> >> diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c >> index 82e204a..15201f9 100644 >> --- a/sys/dev/acpica/acpi_cpu.c >> +++ b/sys/dev/acpica/acpi_cpu.c >> @@ -1054,6 +1054,8 @@ acpi_cpu_notify(ACPI_HANDLE h, UINT32 notify, void *context) >> ACPI_SERIAL_BEGIN(cpu); >> acpi_cpu_set_cx_lowest(sc); >> ACPI_SERIAL_END(cpu); >> + >> + acpi_UserNotify("PROCESSOR", sc->cpu_handle, notify); >> } >> >> static int >> > > So quick question, does this happen a lot on a system with a sporadic > workload? Does this introduce overhead to the system to service the > notification requests? I am not sure who can answer this question. It is up to ACPI platform to decide when it changes _available C-states_. OS doesn't have control over that. P.S. I hope you haven't confused this notification for a notification about _current_ C-state changing. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 16:21:41 2012 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 6DC7A106564A; Wed, 3 Oct 2012 16:21:41 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by mx1.freebsd.org (Postfix) with ESMTP id 249278FC12; Wed, 3 Oct 2012 16:21:40 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q93GL6mZ009136; Wed, 3 Oct 2012 09:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1349281268; bh=m0izu1CzRooeeXUFV0PE5fFj+KoS/nHHUF1n5MtP55E=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=vbKUCTB/XD5l9Mltj1wn2NXpIbjOK6Y4GzJdd9KatZrgcrjzu8eQAzPK9u8kFGsug UhOzp2XYMR7+sqrDbxzWiehiHGOAg0vq4O8kX4Dp1BLaxsfTio8eDD4qPHQ+80UdjR Zs+9PuqjrUVYeEkWJhO0q9glJJCVY4gfjqTr3FCM= From: Sean Bruno To: Andriy Gapon In-Reply-To: <506C38CE.4090400@FreeBSD.org> References: <504EDBEB.6010104@FreeBSD.org> <1349198313.4246.3.camel@powernoodle.corp.yahoo.com> <506C38CE.4090400@FreeBSD.org> Content-Type: text/plain; charset="UTF-8" Date: Wed, 03 Oct 2012 09:21:06 -0700 Message-ID: <1349281266.13749.0.camel@powernoodle.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 281267004 Cc: "sbruno@FreeBSD.org" , "freebsd-acpi@freebsd.org" Subject: Re: notify userland about C-state changes 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, 03 Oct 2012 16:21:41 -0000 On Wed, 2012-10-03 at 06:08 -0700, Andriy Gapon wrote: > > > > So quick question, does this happen a lot on a system with a > sporadic > > workload? Does this introduce overhead to the system to service the > > notification requests? > > I am not sure who can answer this question. It is up to ACPI platform > to decide > when it changes _available C-states_. OS doesn't have control over > that. > Hrm ... what changes to the machine would make this happen while the machine is running? things like the switching from battery to line power? > P.S. I hope you haven't confused this notification for a notification > about > _current_ C-state changing. I did have it confused. Thanks for putting this note in. Sean From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 16:24:12 2012 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 AF30D106566B; Wed, 3 Oct 2012 16:24:12 +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 CC89A8FC15; Wed, 3 Oct 2012 16:24:11 +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 TAA07996; Wed, 03 Oct 2012 19:24:07 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <506C66A6.4070003@FreeBSD.org> Date: Wed, 03 Oct 2012 19:24:06 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Sean Bruno References: <504EDBEB.6010104@FreeBSD.org> <1349198313.4246.3.camel@powernoodle.corp.yahoo.com> <506C38CE.4090400@FreeBSD.org> <1349281266.13749.0.camel@powernoodle.corp.yahoo.com> In-Reply-To: <1349281266.13749.0.camel@powernoodle.corp.yahoo.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "sbruno@FreeBSD.org" , "freebsd-acpi@freebsd.org" Subject: Re: notify userland about C-state changes 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, 03 Oct 2012 16:24:12 -0000 on 03/10/2012 19:21 Sean Bruno said the following: > On Wed, 2012-10-03 at 06:08 -0700, Andriy Gapon wrote: >>> >>> So quick question, does this happen a lot on a system with a >> sporadic >>> workload? Does this introduce overhead to the system to service the >>> notification requests? >> >> I am not sure who can answer this question. It is up to ACPI platform >> to decide >> when it changes _available C-states_. OS doesn't have control over >> that. >> > Hrm ... what changes to the machine would make this happen while the > machine is running? things like the switching from battery to line > power? Yes. Or something else [?] of similar nature/effect. >> P.S. I hope you haven't confused this notification for a notification >> about >> _current_ C-state changing. > > I did have it confused. Thanks for putting this note in. OK :-) -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 16:31:02 2012 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 F19A0106564A for ; Wed, 3 Oct 2012 16:31:01 +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 4A3DB8FC0A for ; Wed, 3 Oct 2012 16:31:00 +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 TAA08045 for ; Wed, 03 Oct 2012 19:30:59 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <506C6843.8030709@FreeBSD.org> Date: Wed, 03 Oct 2012 19:30:59 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: "freebsd-acpi@freebsd.org" X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: acpi_thermal: fix _AL activation logic 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, 03 Oct 2012 16:31:02 -0000 The following patch should put the logic in acpi_thermal in accordance to my understanding of ACPI specification. This is probably of very minor importance as very few modern systems use ACPI TZ to managed fans (this is mostly deferred to hardware or firmware). The change would probably change nothing for systems where a TZ manages a single fan with various speed levels. commit 8da38fffb44ddf5449e5fc15d3ad07b645de12f8 Author: Andriy Gapon Date: Wed Sep 26 18:26:47 2012 +0300 acpi_thermal: when _ACx is tripped, all _ALi i>= x should be on ... and not just _ALx as it is now. diff --git a/sys/dev/acpica/acpi_thermal.c b/sys/dev/acpica/acpi_thermal.c index 32e5c2d..baa8205 100644 --- a/sys/dev/acpica/acpi_thermal.c +++ b/sys/dev/acpica/acpi_thermal.c @@ -121,6 +121,8 @@ struct acpi_tz_softc { int tz_cooling_saved_freq; }; +#define TZ_ACTIVE_LEVEL(act) ((act) >= 0 ? (act) : TZ_NUMLEVELS) + #define CPUFREQ_MAX_LEVELS 64 /* XXX cpufreq should export this */ static int acpi_tz_probe(device_t dev); @@ -565,18 +567,21 @@ acpi_tz_monitor(void *Context) } if (newactive != sc->tz_active) { - /* Turn off the cooling devices that are on, if any are */ - if (sc->tz_active != TZ_ACTIVE_NONE) + /* Turn off unneeded cooling devices that are on, if any are */ + for (i = TZ_ACTIVE_LEVEL(sc->tz_active); + i < TZ_ACTIVE_LEVEL(newactive); i++) { acpi_ForeachPackageObject( - (ACPI_OBJECT *)sc->tz_zone.al[sc->tz_active].Pointer, + (ACPI_OBJECT *)sc->tz_zone.al[i].Pointer, acpi_tz_switch_cooler_off, sc); - + } /* Turn on cooling devices that are required, if any are */ - if (newactive != TZ_ACTIVE_NONE) { + for (i = TZ_ACTIVE_LEVEL(sc->tz_active) - 1; + i >= TZ_ACTIVE_LEVEL(newactive); i--) { acpi_ForeachPackageObject( - (ACPI_OBJECT *)sc->tz_zone.al[newactive].Pointer, + (ACPI_OBJECT *)sc->tz_zone.al[i].Pointer, acpi_tz_switch_cooler_on, sc); } + ACPI_VPRINT(sc->tz_dev, acpi_device_get_parent_softc(sc->tz_dev), "switched from %s to %s: %d.%dC\n", acpi_tz_aclevel_string(sc->tz_active), -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 16:34:16 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85409106564A for ; Wed, 3 Oct 2012 16:34:16 +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 B1ECF8FC12 for ; Wed, 3 Oct 2012 16:34:15 +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 TAA08055 for ; Wed, 03 Oct 2012 19:34:14 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <506C6906.9070402@FreeBSD.org> Date: Wed, 03 Oct 2012 19:34:14 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: "freebsd-acpi@freebsd.org" X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: acpi_wmi: move wmi_info_list into sc 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, 03 Oct 2012 16:34:16 -0000 Please take a look at the following patch and a commit message that explains it. I observed the problem on a system with acpi_wmi instances where one instance overrode GUID list from the other. commit f1f4109b1588872906ed56086e2680ac1af96268 Author: Andriy Gapon Date: Thu Sep 27 13:48:18 2012 +0300 acpi_wmi: move wmi_info_list into sc different instances of acpi_wmi couldn't properly share it and in fact there was no reason to do that diff --git a/sys/dev/acpi_support/acpi_wmi.c b/sys/dev/acpi_support/acpi_wmi.c index 5a37979..5927ee1 100644 --- a/sys/dev/acpi_support/acpi_wmi.c +++ b/sys/dev/acpi_support/acpi_wmi.c @@ -74,6 +74,7 @@ struct acpi_wmi_softc { struct sbuf wmistat_sbuf; /* sbuf for /dev/wmistat output */ pid_t wmistat_open_pid; /* pid operating on /dev/wmistat */ int wmistat_bufptr; /* /dev/wmistat ptr to buffer position */ + TAILQ_HEAD(wmi_info_list_head, wmi_info) wmi_info_list; }; /* @@ -105,8 +106,6 @@ struct wmi_info { void *event_handler_user_data; /* ev handler cookie */ }; -TAILQ_HEAD(wmi_info_list_head, wmi_info) - wmi_info_list = TAILQ_HEAD_INITIALIZER(wmi_info_list); ACPI_SERIAL_DECL(acpi_wmi, "ACPI-WMI Mapping"); @@ -146,13 +145,13 @@ static ACPI_STATUS acpi_wmi_ec_handler(UINT32 function, void *region_context); #endif /* helpers */ -static ACPI_STATUS acpi_wmi_read_wdg_blocks(ACPI_HANDLE h); +static ACPI_STATUS acpi_wmi_read_wdg_blocks(struct acpi_wmi_softc *sc, ACPI_HANDLE h); static ACPI_STATUS acpi_wmi_toggle_we_event_generation(device_t dev, struct wmi_info *winfo, enum event_generation_state state); static int acpi_wmi_guid_string_to_guid(const UINT8 *guid_string, UINT8 *guid); -static struct wmi_info* acpi_wmi_lookup_wmi_info_by_guid_string( +static struct wmi_info* acpi_wmi_lookup_wmi_info_by_guid_string(struct acpi_wmi_softc *sc, const char *guid_string); static d_open_t acpi_wmi_wmistat_open; @@ -240,7 +239,7 @@ acpi_wmi_attach(device_t dev) ACPI_SERIAL_BEGIN(acpi_wmi); sc->wmi_dev = dev; sc->wmi_handle = acpi_get_handle(dev); - TAILQ_INIT(&wmi_info_list); + TAILQ_INIT(&sc->wmi_info_list); #if 0 /* XXX Only works with one EC, but nearly all systems only have one. */ if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0)) @@ -263,7 +262,7 @@ acpi_wmi_attach(device_t dev) acpi_wmi_notify_handler); } #endif - else if (ACPI_FAILURE((status = acpi_wmi_read_wdg_blocks( + else if (ACPI_FAILURE((status = acpi_wmi_read_wdg_blocks(sc, sc->wmi_handle)))) { device_printf(sc->wmi_dev, "couldn't parse _WDG - %s\n", AcpiFormatException(status)); @@ -318,11 +317,11 @@ acpi_wmi_detach(device_t dev) AcpiRemoveAddressSpaceHandler(sc->wmi_handle, ACPI_ADR_SPACE_EC, acpi_wmi_ec_handler); #endif - TAILQ_FOREACH_SAFE(winfo, &wmi_info_list, wmi_list, tmp) { + TAILQ_FOREACH_SAFE(winfo, &sc->wmi_info_list, wmi_list, tmp) { if (winfo->event_handler) acpi_wmi_toggle_we_event_generation(dev, winfo, EVENT_GENERATION_OFF); - TAILQ_REMOVE(&wmi_info_list, winfo, wmi_list); + TAILQ_REMOVE(&sc->wmi_info_list, winfo, wmi_list); free(winfo, M_ACPIWMI); } if (sc->wmistat_bufptr != -1) { @@ -347,12 +346,14 @@ acpi_wmi_detach(device_t dev) static int acpi_wmi_provides_guid_string_method(device_t dev, const char *guid_string) { + struct acpi_wmi_softc *sc; struct wmi_info *winfo; int ret; + sc = device_get_softc(dev); ACPI_FUNCTION_TRACE((char *)(uintptr_t)__func__); ACPI_SERIAL_BEGIN(acpi_wmi); - winfo = acpi_wmi_lookup_wmi_info_by_guid_string(guid_string); + winfo = acpi_wmi_lookup_wmi_info_by_guid_string(sc, guid_string); ret = (winfo == NULL)?0:winfo->ginfo.max_instance+1; ACPI_SERIAL_END(acpi_wmi); @@ -378,7 +379,7 @@ acpi_wmi_evaluate_call_method(device_t dev, const char *guid_string, sc = device_get_softc(dev); ACPI_SERIAL_BEGIN(acpi_wmi); - if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(guid_string)) + if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(sc, guid_string)) == NULL) status = AE_NOT_FOUND; else if (!(winfo->ginfo.flags & ACPI_WMI_REGFLAG_METHOD)) @@ -420,6 +421,7 @@ static ACPI_STATUS acpi_wmi_install_event_handler_method(device_t dev, const char *guid_string, ACPI_NOTIFY_HANDLER event_handler, void *data) { + struct acpi_wmi_softc *sc = device_get_softc(dev); struct wmi_info *winfo; ACPI_STATUS status; @@ -429,7 +431,7 @@ acpi_wmi_install_event_handler_method(device_t dev, const char *guid_string, ACPI_SERIAL_BEGIN(acpi_wmi); if (guid_string == NULL || event_handler == NULL) status = AE_BAD_PARAMETER; - else if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(guid_string)) + else if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(sc, guid_string)) == NULL) status = AE_NOT_EXIST; else if (winfo->event_handler != NULL || @@ -451,6 +453,7 @@ acpi_wmi_install_event_handler_method(device_t dev, const char *guid_string, static ACPI_STATUS acpi_wmi_remove_event_handler_method(device_t dev, const char *guid_string) { + struct acpi_wmi_softc *sc = device_get_softc(dev); struct wmi_info *winfo; ACPI_STATUS status; @@ -459,7 +462,7 @@ acpi_wmi_remove_event_handler_method(device_t dev, const char *guid_string) status = AE_OK; ACPI_SERIAL_BEGIN(acpi_wmi); if (guid_string && - (winfo = acpi_wmi_lookup_wmi_info_by_guid_string(guid_string)) + (winfo = acpi_wmi_lookup_wmi_info_by_guid_string(sc, guid_string)) != NULL && winfo->event_handler) { status = acpi_wmi_toggle_we_event_generation(dev, winfo, EVENT_GENERATION_OFF); @@ -494,7 +497,7 @@ acpi_wmi_get_event_data_method(device_t dev, UINT32 event_id, ACPI_BUFFER *out) params[0].Integer.Value = event_id; input.Pointer = params; input.Count = 1; - TAILQ_FOREACH(winfo, &wmi_info_list, wmi_list) { + TAILQ_FOREACH(winfo, &sc->wmi_info_list, wmi_list) { if ((winfo->ginfo.flags & ACPI_WMI_REGFLAG_EVENT) && ((UINT8) winfo->ginfo.oid[0] == event_id)) { status = AcpiEvaluateObject(sc->wmi_handle, "_WED", @@ -538,7 +541,7 @@ acpi_wmi_get_block_method(device_t dev, const char *guid_string, UINT8 instance, ACPI_SERIAL_BEGIN(acpi_wmi); if (guid_string == NULL || out == NULL) status = AE_BAD_PARAMETER; - else if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(guid_string)) + else if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(sc, guid_string)) == NULL) status = AE_ERROR; else if (instance > winfo->ginfo.max_instance) @@ -602,7 +605,7 @@ acpi_wmi_set_block_method(device_t dev, const char *guid_string, UINT8 instance, ACPI_SERIAL_BEGIN(acpi_wmi); if (guid_string == NULL || in == NULL) status = AE_BAD_DATA; - else if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(guid_string)) + else if ((winfo = acpi_wmi_lookup_wmi_info_by_guid_string(sc, guid_string)) == NULL) status = AE_ERROR; else if (instance > winfo->ginfo.max_instance) @@ -636,6 +639,7 @@ acpi_wmi_set_block_method(device_t dev, const char *guid_string, UINT8 instance, static void acpi_wmi_notify_handler(ACPI_HANDLE h, UINT32 notify, void *context) { + struct acpi_wmi_softc *sc = context; ACPI_NOTIFY_HANDLER handler; void *handler_data; struct wmi_info *winfo; @@ -645,7 +649,7 @@ acpi_wmi_notify_handler(ACPI_HANDLE h, UINT32 notify, void *context) handler = NULL; handler_data = NULL; ACPI_SERIAL_BEGIN(acpi_wmi); - TAILQ_FOREACH(winfo, &wmi_info_list, wmi_list) { + TAILQ_FOREACH(winfo, &sc->wmi_info_list, wmi_list) { if ((winfo->ginfo.flags & ACPI_WMI_REGFLAG_EVENT) && ((UINT8) winfo->ginfo.oid[0] == notify)) { if (winfo->event_handler) { @@ -719,7 +723,7 @@ acpi_wmi_ec_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address, * into wmi_info_list. */ static ACPI_STATUS -acpi_wmi_read_wdg_blocks(ACPI_HANDLE h) +acpi_wmi_read_wdg_blocks(struct acpi_wmi_softc *sc, ACPI_HANDLE h) { ACPI_BUFFER out = {ACPI_ALLOCATE_BUFFER, NULL}; struct guid_info *ginfo; @@ -750,7 +754,7 @@ acpi_wmi_read_wdg_blocks(ACPI_HANDLE h) return (AE_NO_MEMORY); } winfo->ginfo = ginfo[i]; - TAILQ_INSERT_TAIL(&wmi_info_list, winfo, wmi_list); + TAILQ_INSERT_TAIL(&sc->wmi_info_list, winfo, wmi_list); } AcpiOsFree(out.Pointer); free(ginfo, M_ACPIWMI); @@ -860,7 +864,7 @@ acpi_wmi_guid_string_to_guid(const UINT8 *guid_string, UINT8 *guid) * Return NULL if the GUID is unknown in the _WDG */ static struct wmi_info* -acpi_wmi_lookup_wmi_info_by_guid_string(const char *guid_string) +acpi_wmi_lookup_wmi_info_by_guid_string(struct acpi_wmi_softc *sc, const char *guid_string) { char guid[16]; struct wmi_info *winfo; @@ -870,7 +874,7 @@ acpi_wmi_lookup_wmi_info_by_guid_string(const char *guid_string) ACPI_SERIAL_ASSERT(acpi_wmi); if (!acpi_wmi_guid_string_to_guid(guid_string, guid)) { - TAILQ_FOREACH(winfo, &wmi_info_list, wmi_list) { + TAILQ_FOREACH(winfo, &sc->wmi_info_list, wmi_list) { if (!memcmp(winfo->ginfo.guid, guid, 16)) { return (winfo); } @@ -969,7 +973,7 @@ acpi_wmi_wmistat_read(struct cdev *dev, struct uio *buf, int flag) sbuf_printf(&sc->wmistat_sbuf, "GUID " " INST EXPE METH STR " "EVENT OID\n"); - TAILQ_FOREACH(winfo, &wmi_info_list, wmi_list) { + TAILQ_FOREACH(winfo, &sc->wmi_info_list, wmi_list) { guid = (UINT8*)winfo->ginfo.guid; sbuf_printf(&sc->wmistat_sbuf, "{%02X%02X%02X%02X-%02X%02X-" -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 17:40:23 2012 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 0F53210656D5; Wed, 3 Oct 2012 17:40:23 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 574BB8FC17; Wed, 3 Oct 2012 17:40:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q93HeEKl008490; Thu, 4 Oct 2012 03:40:15 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 4 Oct 2012 03:40:14 +1000 (EST) From: Ian Smith To: Andriy Gapon In-Reply-To: <506C66A6.4070003@FreeBSD.org> Message-ID: <20121004031100.P43208@sola.nimnet.asn.au> References: <504EDBEB.6010104@FreeBSD.org> <1349198313.4246.3.camel@powernoodle.corp.yahoo.com> <506C38CE.4090400@FreeBSD.org> <1349281266.13749.0.camel@powernoodle.corp.yahoo.com> <506C66A6.4070003@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Sean Bruno , "freebsd-acpi@freebsd.org" Subject: Re: notify userland about C-state changes 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, 03 Oct 2012 17:40:23 -0000 On Wed, 3 Oct 2012, Andriy Gapon wrote: > on 03/10/2012 19:21 Sean Bruno said the following: > > On Wed, 2012-10-03 at 06:08 -0700, Andriy Gapon wrote: > >>> > >>> So quick question, does this happen a lot on a system with a > >> sporadic > >>> workload? Does this introduce overhead to the system to service the > >>> notification requests? > >> > >> I am not sure who can answer this question. It is up to ACPI platform > >> to decide > >> when it changes _available C-states_. OS doesn't have control over > >> that. If you give us the notification :) we could instrument behaviour on different systems, and check for correlation with your [?] .. > >> > > Hrm ... what changes to the machine would make this happen while the > > machine is running? things like the switching from battery to line > > power? > > Yes. Or something else [?] of similar nature/effect. Docking/undocking a laptop maybe? LAN/Wireless busy/not (re C3 anyway). As you say, up to ACPI code by vendor, modulo ASL tweaks. > >> P.S. I hope you haven't confused this notification for a notification > >> about > >> _current_ C-state changing. > > > > I did have it confused. Thanks for putting this note in. > > OK :-) Me too .. my first reaction was ooo, that could get really busy :) So are you talking about a devd notification to trigger activity like the AC/battery script, or a sysctl that scripts could poll, or? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Wed Oct 3 19:56:42 2012 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 B2C06106564A; Wed, 3 Oct 2012 19:56: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 CD8B88FC0C; Wed, 3 Oct 2012 19:56:41 +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 WAA10390; Wed, 03 Oct 2012 22:56:26 +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 1TJV3R-000HDt-VT; Wed, 03 Oct 2012 22:56:25 +0300 Message-ID: <506C9867.2020403@FreeBSD.org> Date: Wed, 03 Oct 2012 22:56:23 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: Ian Smith References: <504EDBEB.6010104@FreeBSD.org> <1349198313.4246.3.camel@powernoodle.corp.yahoo.com> <506C38CE.4090400@FreeBSD.org> <1349281266.13749.0.camel@powernoodle.corp.yahoo.com> <506C66A6.4070003@FreeBSD.org> <20121004031100.P43208@sola.nimnet.asn.au> In-Reply-To: <20121004031100.P43208@sola.nimnet.asn.au> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sbruno@FreeBSD.org" , "freebsd-acpi@freebsd.org" , Sean Bruno Subject: Re: notify userland about C-state changes 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, 03 Oct 2012 19:56:42 -0000 on 03/10/2012 20:40 Ian Smith said the following: > So are you talking about a devd notification to trigger activity like > the AC/battery script, or a sysctl that scripts could poll, or? devd notification like for AC line status change. -- Andriy Gapon From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 4 07:42:07 2012 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 958161065675; Thu, 4 Oct 2012 07:42:06 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 646418FC57; Thu, 4 Oct 2012 07:04:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q9474paZ035252; Thu, 4 Oct 2012 17:04:51 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 4 Oct 2012 17:04:51 +1000 (EST) From: Ian Smith To: Andriy Gapon In-Reply-To: <506C9867.2020403@FreeBSD.org> Message-ID: <20121004170250.L43208@sola.nimnet.asn.au> References: <504EDBEB.6010104@FreeBSD.org> <1349198313.4246.3.camel@powernoodle.corp.yahoo.com> <506C38CE.4090400@FreeBSD.org> <1349281266.13749.0.camel@powernoodle.corp.yahoo.com> <506C66A6.4070003@FreeBSD.org> <20121004031100.P43208@sola.nimnet.asn.au> <506C9867.2020403@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "sbruno@FreeBSD.org" , "freebsd-acpi@freebsd.org" , Sean Bruno Subject: Re: notify userland about C-state changes 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, 04 Oct 2012 07:42:07 -0000 On Wed, 3 Oct 2012, Andriy Gapon wrote: > on 03/10/2012 20:40 Ian Smith said the following: > > So are you talking about a devd notification to trigger activity like > > the AC/battery script, or a sysctl that scripts could poll, or? > > devd notification like for AC line status change. I'll buy one, when you MFC it back to 9 (8?) cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Oct 4 13:34:58 2012 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 21783106566C; Thu, 4 Oct 2012 13:34:58 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 7D70A8FC0C; Thu, 4 Oct 2012 13:34:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q94DYtHm048023; Thu, 4 Oct 2012 23:34:56 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 4 Oct 2012 23:34:55 +1000 (EST) From: Ian Smith To: Andriy Gapon In-Reply-To: <20121004170250.L43208@sola.nimnet.asn.au> Message-ID: <20121004233148.T43208@sola.nimnet.asn.au> References: <504EDBEB.6010104@FreeBSD.org> <1349198313.4246.3.camel@powernoodle.corp.yahoo.com> <506C38CE.4090400@FreeBSD.org> <1349281266.13749.0.camel@powernoodle.corp.yahoo.com> <506C66A6.4070003@FreeBSD.org> <20121004031100.P43208@sola.nimnet.asn.au> <506C9867.2020403@FreeBSD.org> <20121004170250.L43208@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "freebsd-acpi@freebsd.org" Subject: Re: notify userland about C-state changes 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, 04 Oct 2012 13:34:58 -0000 On Thu, 4 Oct 2012, Ian Smith wrote: > On Wed, 3 Oct 2012, Andriy Gapon wrote: > > devd notification like for AC line status change. > > I'll buy one, when you MFC it back to 9 (8?) Sorry, that was flippant. Anything preventing applying this to 9, or 8? Ian From owner-freebsd-acpi@FreeBSD.ORG Fri Oct 5 21:55:35 2012 Return-Path: Delivered-To: acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1483106566C; Fri, 5 Oct 2012 21:55:35 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 8E6798FC0C; Fri, 5 Oct 2012 21:55:35 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 0BA8D1E00700; Fri, 5 Oct 2012 23:55:27 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.4/8.14.4) with ESMTP id q95LrGIY039123; Fri, 5 Oct 2012 23:53:16 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.4/8.14.3/Submit) id q95LrG6g039122; Fri, 5 Oct 2012 23:53:16 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Fri, 5 Oct 2012 23:53:16 +0200 To: mobile@freebsd.org, acpi@freebsd.org Message-ID: <20121005215316.GA38707@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: avilla@freebsd.org Subject: Dell acpi_video patch 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, 05 Oct 2012 21:55:35 -0000 Hi! I finally took a closer look why acpi_video found nothing on my Dell laptop (Precision M4500), and came up with this patch: --- sys/dev/acpica/acpi_video.c.orig +++ sys/dev/acpica/acpi_video.c @@ -906,7 +906,7 @@ vid_enum_outputs_subr(ACPI_HANDLE handle for (i = 0; i < argset->dod_pkg->Package.Count; i++) { if (acpi_PkgInt32(argset->dod_pkg, i, &val) == 0 && - (val & DOD_DEVID_MASK_FULL) == adr) { + (val & (DOD_DEVID_MASK_FULL | 0x80000000)) == adr) { argset->callback(handle, val, argset->context); argset->count++; } which gives me: % sysctl hw.acpi.video. hw.acpi.video.crt0.active: 0 hw.acpi.video.lcd0.active: 0 hw.acpi.video.lcd0.brightness: 100 hw.acpi.video.lcd0.fullpower: 100 hw.acpi.video.lcd0.economy: 46 hw.acpi.video.lcd0.levels: 100 46 0 6 13 20 26 33 40 46 53 60 66 73 80 86 93 100 hw.acpi.video.ext0.active: 0 hw.acpi.video.ext1.active: 0 hw.acpi.video.ext2.active: 0 hw.acpi.video.ext3.active: 0 % and I can change the lcd brightness. hw.acpi.video.lcd0.active is still 0 tho and can't be changed regardless if the display is off or on - maybe that also explains the blank screen after suspend/resume w/o X running or when exiting X or switching from X to a textconsole? I also took a cursory look at Linux' drivers/platform/x86/dell-laptop.c and drivers/platform/x86/dell-wmi.c and found Linux seems to do smi calls, tho it wasn't immediately obvious if that affects all Dell laptops or only older models. (The blank screen problem doesn't occur on Linux.) See also my FLCL entry: https://laptop.bsdgroup.de/freebsd/index.html?action=show_laptop_detail&laptop=13061 Thanx! :) Juergen