AMD64 CPU and ACPI (was Re: Configuration of Compaq R3000)

[Nate Lawson]

Michael W. Oliver wrote:
> On 2005-01-27T13:59:29-0500, Jung-uk Kim wrote:
>>Did you use 'acpi_ppc' driver?
>>http://www.spa.is.uec.ac.jp/~nfukuda/software/
> 
>>You need this driver to run your laptop at full speed.  CPU speed will 
>>be automatically adjusted by CPU load.  However, it may take few 
>>seconds to get to the speed.  You can set the speed manually by:
> 
> Whoo-hoo!!!  This works on my machine (Sager 4750V) so far, and gives
> wonderful information:
> 
> hw.acpi.cpu.px_control: -1
> hw.acpi.cpu.px_highest: 0
> hw.acpi.cpu.px_lowest: 2
> hw.acpi.cpu.px_current: 1
> hw.acpi.cpu.px_supported: 2200 1800 800
> hw.acpi.cpu.px_usage: 4.62% 25.70% 69.66%
> 
> (running `make clean' in /usr/ports just to push it a little)
> 
> This is great!  Thanks so much for posting this!  This completely makes
> sense now that I would see the CPU speed reported as ~801MHz when the
> machine would boot up.  I can't thank you enough.
> 
> What are the chances that this could be imported into current?  I am
> running...

I've been working on a cpufreq driver for about 6 months now.  Work 
unfortunately has made progress too slow.  I have taken a vacation day 
to work on FreeBSD and plan to import a stripped down version (no 
throttling support) very soon.

The driver is a general cpufreq framework and two hardware drivers, one 
for SpeedStep ICH and one for ACPI Px states (like acpi_ppc but a 
separate implementation).  Other drivers, like SpeedStep Centrino and 
Powernow, can easily be hooked into the framework by their maintainers 
and imported into the general tree.  I've wanted to keep them as ports 
for now so that I could prototype the framework before importing it. 
That way we wouldn't have to restructure millions of cpu hardware 
drivers after the fact.

The short answer is that a similar capability should be imported soon.

>>Unfortunately if you run this laptop under heavy CPU load, CPU will 
>>heat up pretty fast and 'acpi_ec' will adjust delay to prevent 
>>excessive heat.  You can ignore this behavior by hacking acpi_ec.c, I 
>>believe but it's really bad idea.
> 
> 
> I do see some ACPI errors on my laptop when I boot it up, such as:
> 
> (dmesg -a | grep -i acpi):
> acpi_cmbat0: battery initialization start
> acpi_acad0: acline initialization start
> acpi_tz0: _CRT value is absurd, ignored (154.8C)
> acpi_acad0: On Line
> acpi_acad0: acline initialization done, tried 1 times
> acpi_ec0: info: new max delay is 70 us
> acpi_ec0: info: new max delay is 100 us
> acpi_cmbat0: battery initialization failed, giving up   <-- ugh!
> acpi_ec0: info: new max delay is 130 us
> acpi_ec0: info: new max delay is 170 us
> acpi_tz0: _CRT value is absurd, ignored (154.8C)
> acpi_tz0: _CRT value is absurd, ignored (154.8C)
> acpi_ec0: info: new max delay is 900 us
> acpi_ec0: info: new max delay is 11000 us
> acpi_tz0: _CRT value is absurd, ignored (154.8C)
> acpi_tz0: _CRT value is absurd, ignored (154.8C)

This all indicates your embedded controller is not responding.  It's 
important to figure out why.  Can you post a link to your full dmesg too?

> acpidump stuff is here:
> http://michael.gargantuan.com/sager_4750v/acpidump.asl
> http://michael.gargantuan.com/sager_4750v/dsdt.out
> http://michael.gargantuan.com/sager_4750v/sysctl_hw.acpi

Thanks, I'll eventually take a look at this but hopefully you understand 
that I've set aside bugfixing for a short while to complete longer term 
projects.

-- 
Nate