2003-06-13
Revision History | ||
---|---|---|
Revision 1.0 | 2003-06-20 | Revised by: tm |
Initial release, reviewed by LDP | ||
Revision 0.12 | 2003-06-13 | Revised by: dn |
minor xml sourcecode rework, final draft for ldp release | ||
Revision 0.11 | 2003-06-11 | Revised by: dn |
minor bugfix and minor updates | ||
Revision 0.10 | 2003-06-06 | Revised by: dn |
rework of all command-line-hacks ... one was buggy, the others not perfect enough ;) ... |
The HLT signal which is used by the normal idle-loop of the Linux kernel does not bring any significant power-saving on processors of the Athlon/Duron family (hereafter referred to as Athlon processors). To get real power-saving on an Athlon processor, you have to put the processor in the STPGNT-Mode (Stop Grant Mode). In this mode, the processor is disconnected from the front-side bus (FSB), and can turn off parts of the CPU as well as reduce the clock to save power.
This document, Athlon Powersaving HOWTO, is copyrighted (c) 2003 by Daniel Nofftz.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is available at http://www.gnu.org/copyleft/fdl.html.
Linux is a registered trademark of Linus Torvalds.
No liability for the contents of this document can be accepted. Use the concepts, examples and information at your own risk. There may be errors and inaccuracies, that could be damaging to your system. Proceed with caution, and although this is highly unlikely, the author(s) do not take any responsibility.
All copyrights are held by their respective owners, unless specifically noted otherwise. Use of a term in this document should not be regarded as affecting the validity of any trademark or service mark. Naming of particular products or brands should not be seen as endorsements.
Feedback is most essential for this document. New solutions for new chipsets are especially needed. And I need comments, whether the provided solutions work or don't work. Send your additions, comments and criticisms to the following email address: <daniel@nofftz.de.NOSPAM>.
You can email me in German or English!
The newest version of this HOWTO will always first be made available here.
In the following section I present different approaches to achieve the same goal: power-saving on your Athlon-based system. My recommended approach at the moment is to use the "command-line hack," because the kernel patch is outdated and will not be developed any further, and the LVCool patch supports only one chipset family. The athcool program sounds good, but I haven't tested it myself.
All these approaches will set the "Disconnect eable when STPGNT detected" bit in the north bridge of the chipset. Nothing more and nothing less than that. All other work is done by the ACPI subsystem of the kernel which sends a STPGNT signal to the processor, when it enters the acpi-c2 idle mode. (Only the LVCool solution takes a different way ...)
If you haven't already got a kernel with ACPI support, you have to enable it in the kernel setup and then recompile the new kernel. You'll find the ACPI-options under
+ -> . You must have at least the following options: , andTo use the command-line hack you have to enable ACPI in the kernel. How you can do this is described in Section 2.4. If you already have a kernel with ACPI-processor support, you can enable/disable the power-saving right from the command-line without any need for rebooting.
enable: setpci -v -H1 -s 0:0.0 52=$(printf %x $((0x$(setpci -H1 -s 0:0.0 52) | 0x80)))
disable: setpci -v -H1 -s 0:0.0 52=$(printf %x $((0x$(setpci -H1 -s 0:0.0 52) & 0x7f)))
enable:
setpci -v -H1 -s 0:0.0 92=$(printf %x $((0x$(setpci -H1 -s 0:0.0 92) | 0x80)))
setpci -v -H1 -s 0:0.0 95=$(printf %x $((0x$(setpci -H1 -s 0:0.0 95) | 0x02)))
disable:
setpci -v -H1 -s 0:0.0 92=$(printf %x $((0x$(setpci -H1 -s 0:0.0 92) & 0x7f)))
setpci -v -H1 -s 0:0.0 95=$(printf %x $((0x$(setpci -H1 -s 0:0.0 95) & 0xfd)))
enable:
setpci -v -H1 -s 0:0.0 D2=$(printf %x $((0x$(setpci -H1 -s 0:0.0 D2) | 0x80)))
setpci -v -H1 -s 0:0.0 D5=$(printf %x $((0x$(setpci -H1 -s 0:0.0 D5) | 0x02)))
disable:
setpci -v -H1 -s 0:0.0 D2=$(printf %x $((0x$(setpci -H1 -s 0:0.0 D2) & 0x7f)))
setpci -v -H1 -s 0:0.0 D5=$(printf %x $((0x$(setpci -H1 -s 0:0.0 D5) & 0xfd)))
enable: setpci -v -H1 -s 0:0.0 6B=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6B) | 0x01)))
disable: setpci -v -H1 -s 0:0.0 6B=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6B) & 0xfe)))
enable: setpci -v -H1 -s 0:0.0 6A=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6A) | 0x0001)))
disable: setpci -v -H1 -s 0:0.0 6A=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6A) & 0xfffe)))
enable:
setpci -v -H1 -s 0:0.0 E7=$(printf %x $((0x$(setpci -H1 -s 0:0.0 E7) | 0x06)))
setpci -v -H1 -s 0:0.0 6D=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6D) | 0x80)))
disable:
setpci -v -H1 -s 0:0.0 E4=$(printf %x $((0x$(setpci -H1 -s 0:0.0 E7) & 0xf9)))
enable: setpci -v -H1 -s 0:0.0 6F=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6F) | 0x10)))
disable: setpci -v -H1 -s 0:0.0 6F=$(printf %x $((0x$(setpci -H1 -s 0:0.0 6F) & 0xef)))
enable: setpci -v -s 0:0.0 0x62=$(printf %x $((0x$(setpci -H1 -s 0:0.0 62) | 0x02)))
disable: setpci -v -s 0:0.0 0x62=$(printf %x $((0x$(setpci -H1 -s 0:0.0 62) & 0xfd)))
Athcool is a small program which performs the same task as the setpci commands above. It supports the same chipsets and detects what chipset you have, issuing the right settings in the chipset to get the power-saving to work.
You can read more about it (and download it) here.
On some newer boards the manufacturer provides a BIOS update which sets the needed bit/bits in the chipset of the board (or let you choose in the BIOS-setup whether it should be enabled). Refer to the homepage of your motherboard manufacturer to see if such a BIOS-update is available.
My patch is based on another patch (from Jan Niehusmann) I found on the Newsnet. I modified the patch to also support the KT266/266A chipset. By the way, my patch does the same as the command-line hack, except from within the kernel. This is why I recommend using the command-line hack, which is really simple to use.
Ok... now step by step, here's how to apply the patch:
First you have to download the patch: Kernel Patch for 2.4.17
Login as root
cd /usr/src
Apply the patch: cat $path-to-patch/amd_cool.diff | patch -p0
cd linux
Make the new kernel
Reboot, and at the kernel boot-prompt, enter the statement amd_disconnect=yes . This is because there are known bugs within the Athlon processor, which could cause problems on several boards. You should test the patch, and if it works, you can append the statement amd_disconnect=yes to the file /etc/lilo.conf.
There are two known bugs in the Athlon/Duron processor. This is number 11 and number 14 in the AMD Athlon Processor Revision Guide. It looks like the Athlon XP is significantly less often affected by these bugs. So if you have an Athlon XP you are on the lucky side (like me).
There could be following problems (caused by the bugs):
skips during sound playback
skips and slowdown during video playback
slowdown of the ultra-DMA harddisk transfers
system hangs
Sometimes a BIOS-update will help (it exists as a workaround for bug 11, which could be done by the BIOS). But as far as I know there are only a few boards out there which have this workaround in the BIOS.
For the Asus A7V133-C, it is known that the BIOS-option PCI master read caching will solve most problems when it is enabled. So look at your BIOS to see whether it has such functionality.
It is also known that on some boards, the BIOS option Delayed Transaction solves some of the problems. You may want to give this option a try too.
WARNING: On boards with KT133A, this could enable the famous VIA-Southbridge bug!
From a Newsnet post, regarding Asus A7V:
without delayed transaction: sound-skips and TV-skips
with delayed transaction: no sound skips and only slight TV problems
with delayed transcation and master read caching: nearly no TV problems and no sound skips at all
There are other causes for problems:
the PSU is not strong enough to handle the fluctuations in the power consumption of the processor/motherboard
some motherboard voltage-regulators could have the same problems like the PSU ;)
you have a K7S5A (as far as I know, this board could be really wired when power-saving is enabled)
If you have minor problems with power-saving enabled, and nevertheless want to use power-saving, you can enable the power-saving by default, and turn it off if you want to playback music, watch TV, ...
Adding more chipsets and more informations to this document.
Maybe make a motherboard list with "working" and "not working" marks.
Translations into different languages also exist. At the moment, most of them are translations of the pre-XML version of this document.
Spanish by Carlos Mayo
French by Mathieu Pillard
Italian by Maurizio Fantino
German (only parts) by Fabian Mohren