Date: Mon, 19 Dec 2005 23:41:19 +0100 From: martinko <martinkov@pobox.sk> To: freebsd-acpi@freebsd.org Cc: martinko <martinkov@pobox.sk>, freebsd-stable@freebsd.org Subject: Cx states missing after upgrade -- Was: Re: HEADS UP: Release schedule for 2006 Message-ID: <43A7370F.2070504@pobox.sk> In-Reply-To: <20051218221834.1DEE65D07@ptavv.es.net> References: <20051218221834.1DEE65D07@ptavv.es.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Oberman wrote: >>Date: Sun, 18 Dec 2005 20:46:49 +0100 >>From: martinko <martinkov@pobox.sk> >> >>Kevin Oberman wrote: >> >> >> >>>>Date: Sat, 17 Dec 2005 18:14:01 +0100 >>>>From: martinko <martinkov@pobox.sk> >>>> >>>>Kevin Oberman wrote: >>>> >>>> >>>> >>>> >>>>>>Date: Fri, 16 Dec 2005 14:29:39 -0600 >>>>>>From: Craig Boston <craig@feniz.gank.org> >>>>>>Sender: owner-freebsd-stable@freebsd.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>-cpu0: <ACPI CPU (4 Cx states)> on acpi0 >>>>>>>+cpu0: <ACPI CPU> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43A7370F.2070504>