From owner-freebsd-acpi@FreeBSD.ORG Mon Dec 19 22:41:27 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 44FEB16A41F for ; Mon, 19 Dec 2005 22:41:27 +0000 (GMT) (envelope-from martinkov@pobox.sk) Received: from smtp.dkm.cz (smtp.dkm.cz [62.24.64.34]) by mx1.FreeBSD.org (Postfix) with SMTP id 3A7AA43D76 for ; Mon, 19 Dec 2005 22:41:21 +0000 (GMT) (envelope-from martinkov@pobox.sk) Received: (qmail 33151 invoked by uid 0); 19 Dec 2005 22:41:19 -0000 Received: from r5k4.chello.upc.cz (HELO ?86.49.10.4?) (86.49.10.4) by smtp.dkm.cz with SMTP; 19 Dec 2005 22:41:19 -0000 Message-ID: <43A7370F.2070504@pobox.sk> Date: Mon, 19 Dec 2005 23:41:19 +0100 From: martinko User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051205 X-Accept-Language: sk, cs, en-gb, en-us, en MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <20051218221834.1DEE65D07@ptavv.es.net> In-Reply-To: <20051218221834.1DEE65D07@ptavv.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: martinko , freebsd-stable@freebsd.org Subject: Cx states missing after upgrade -- Was: Re: HEADS UP: Release schedule for 2006 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, 19 Dec 2005 22:41:27 -0000 Kevin Oberman wrote: >>Date: Sun, 18 Dec 2005 20:46:49 +0100 >>From: martinko >> >>Kevin Oberman wrote: >> >> >> >>>>Date: Sat, 17 Dec 2005 18:14:01 +0100 >>>>From: martinko >>>> >>>>Kevin Oberman wrote: >>>> >>>> >>>> >>>> >>>>>>Date: Fri, 16 Dec 2005 14:29:39 -0600 >>>>>>From: Craig Boston >>>>>>Sender: owner-freebsd-stable@freebsd.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-cpu0: on acpi0 >>>>>>>+cpu0: on acpi0 >>>>>>> >>>>>>>Q: Guessing that's a formatting difference, rather then 6.x not recognizing >>>>>>>the states (sysctl hw.acpi.cpu.cx_supported confirms 4 states) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Not sure on this, but you're probably better off using EST anyway as I >>>>>>think it gives you more control over the processor frequency. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>No. There is no conflict between Cx states and EST. Cx states specifies >>>>>how deeply the CPU will sleep when idle. EST controls processor speed >>>>>and voltage. In most cases, your REALLY want to use both of these. They >>>>>are very significant in saving power. (Of course, USB tends to limit the >>>>>effectiveness of Cx states. I need to run without USB to get really good >>>>>battery life and to make suspend (S3) really ut power drain. >>>>> >>>>> >>>>> >>>>> >>>>Kevin, >>>> >>>>I used to have 3 Cx states supported when I started with FreeBSD on >>>>version 5.3. Since I upgraded to 5.4 and recently to 6.0, all I can see >>>>is just one supported Cx state. I much wonder why. (?) >>>> >>>> >>>> >>>> >>>What value do you have in /etc/rc.conf (if any) for >>>performance_cx_lowest? It defaults to HIGH which will limit you to only >>>the most power hungry sleep state (simple halt). This was made the >>>default because some hardware was breaking when this was defaulted to >>>LOW. T0 get other Cx states to be utilized, add >>>'performance_cx_lowest="LOW"' to /etc/rc.conf. >>> >>> >>> >>> >>i see. >> >>anyway: >> >># grep cx /etc/rc.conf.local >>economy_cx_lowest="LOW" >>performance_cx_lowest="LOW" >> >>still: >> >># sysctl hw.acpi.cpu >>hw.acpi.cpu.cx_supported: C1/1 >>hw.acpi.cpu.cx_lowest: C1 >>hw.acpi.cpu.cx_usage: 100.00% >> >>and, imho, cx_supported should list all available states, doesn't matter >>what is in rc.conf. (well, at least i reckon it's supposed to work that >>way.) >> >>but: >> >>i already had 3 Cx states back on 5.3. >>and when i had them, C2 was used most often (and C3 wasn't at all iirc). >> >>so what has changed in the system please and how am i to get back my >>states please ?? >> >> > >This is a totally different problem. I thought that the problem was >simply not using all of the states. Instead, you are not even showing the >states as available. Looks like the kernel is not reading the >capabilities of your system correctly. > >This seems to coincide with the new ACPI code import. Sounds like >something is not being handled properly and it is likely beyond my >capability to track it down. > >I would suggest posting your the output of 'acpidump -t -d' on a web >site and then sending a report with a pointer to that ASL to >freebsd-acpi@freebsd.org. There it will be seen by the folks who really >know the ACPI stuff. > > hello! thank you, kevin. i did as you advised and here are the outputs of acpidump: # acpidump -t -d -o asus_w1n.dsdt > asus_w1n.asl acpidump: RSDT entry 1 (sig OEMB) is corrupt http://mato.gamato.org/freebsd/aw1n/asus_w1n.dsdt http://mato.gamato.org/freebsd/aw1n/asus_w1n.asl i look forward to hearing from you folks.. :-) many thanks! regards, martin