ThinkWiki - User contributions [en]

Problem with high power drain in ACPI sleep

2007-04-19T19:30:09Z

Fluidspace: /* Affected Models */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
==Problem description==
Several people realized that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.
|}

==Affected Models==
{| border="1" cellspacing="0" cellpadding="2" style="float:right;margin-left:20px;"
|-
! style="vertical-align:top;background-color:#ffcfbc;" | affected models
! style="vertical-align:top;background-color:#cfefcf;" | unaffected models
|-
| style="vertical-align:top;background-color:#fff0e0;" |
* {{R32}}
** 2658-BQG
* {{R40}}
** 2722-3GG
** 2722-5MG
** 2722-B3G
** 2722-CDG
** 2897-GWU
** 2722-6YU
** 2722-CDG
* {{R50}}
** 1829-7RG
** 1829-6DM
** 1836-3SU
* {{R51}}
** 1829-9MG
** 1829-EHG
** 1829-L7G
** 1829-R6G
** 1830-DG4
** 1830-BMG
** 1836-Q6U
* {{T23}}
**2647-???
* {{T30}}
** 2366-81A
** 2366-97U
** 2366-FBU
** 2366-96G
*{{T40}}
**2373-19G
**2373-22G
**2373-42G
**2373-75G
**2373-82U
**2373-92U
**2373-A1U
**2373-MU3
*{{T40p}}
**2373-G1U
**2373-G3U
**2373-G3G
**2373-G1G
**2373-G5G
* {{T41}}
**2379-DJU
**2373-3KG
**2373-9HU
**2373-4FG
**2373-4PG
**2373-1FG
**2373-2FG
**2373-2GG
**2373-6U4
**2373-7JU
**2373-CY0
**2373-TG5
**2373-3HM
**2373-4GU
* {{T41p}}
**2373-9FU
* {{T42}}
**2373-C19
**2373-CTO
**2378-DTU
**2378-DUU
**2378-XXE
**2378-R4U
**2373-FWG
**2374-ZEP
**2373-F2G
**2373-JTU
**2373-VUW
**[[2373-6ZG]]
* {{X21}}
**2662-BSG
* {{X32}}
**2884-A3U
*{{X41T}}
** 1869-5CU
| style="vertical-align:top;background-color:#e9f9e9;" |
*[[:Category:A22m | A22m]]
**2628
*[[:Category:A31 | A31]]
**2652-D5G
*[[:Category:R50p | R50p]]
*[[:Category:R52 | R52]]
**1858-6MM
*[[:Category:T41 | T41]]
**2373-GEU
*[[:Category:T41p | T41p]]
**2373-GKG
**2373-GGG
**[[2373-GHG]]
*[[:Category:T42 | T42]]
**[[2373-M1G]]
**[[2373-WBZ]]
**[[2373-F7G]]
**[[2378-DXU]]
**[[2378-FVU]]
**[[2378-RTU]]
**[[2378-RRU]]
*[[:Category:T42p | T42p]]
**[[2373-HTG]]
**[[2373-W6M]]
**[[2373-GTG]]
**[[2373-GXG]]
**2373-KXM
*[[:Category:T43 | T43]]
**[[2668-W12]]
*[[:Category:T43p | T43p]]
**[[2668-G2G]]
*[[:Category:X40 | X40]]
**2371
|}
*Different symptoms have been reported for different models. In some models the origin of the power drain is obvious ([[Problem with LCD backlight remaining on during ACPI sleep|backlight on during suspend]]), in other models there is no obvious reason.

*On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.

*The T4x ThinkPad series and other Radeon based models suspend to ram just fine, and there are no components that are obviously left powered up. The [[UltraBay]] and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF). For these models the higher power drain is caused by a driver problem and can be fixed in software. Starting with linux 2.6.18 this fix is in the official kernel.

The table on the right gives an overview of the models suffering from the mysterious power drain. To find out about your model, you may use the following [[ACPI sleep power drain test script | script]]. It creates a file {{path|/var/log/battery.log}} which will tell you if you are affected or not.

==Affected Operating Systems==
*Linux, all flavours.
*Windows, for some models as well (only when using non-IBM drivers).
*FreeBSD (on the A22M)

==Radeon GPU not powered off==
A frequent cause of the mysterious power drain is the Radeon GPU, which requires extra steps to suspend properly. We identified affected thinkpads, and [[radeonfb]] activates the workaround on those models automatically (starting with linux kernel 2.6.18).

===Status===
*The official bugzilla entry for the radeon suspend issue is in the [http://bugme.osdl.org/show_bug.cgi?id=3022 OSDL Bugzilla]. There you can find the above-mentioned patch for older kernel versions. The patch removes the CONFIG_PPC_PMAC condition for enabling D2 sleep in {{path|drivers/video/aty/radeon_pm.c}}. If you suspect that this patch makes things worse, you can disable it by the kernel parameter {{bootparm|video|radeonfb:ignore_devlist|1}}. Similarly, if the patch is not automatically activated on your notebook you can force it by {{bootparm|video|radeonfb:force_sleep|1}}. In case that improves your sleep, please leave a note in the bugzilla including the output of {{cmdroot|lspci -d "1002:*" -vn}}. See also [http://thread.gmane.org/gmane.linux.hardware.thinkpad/25355 the linux-thinkpad ML post requesting this information] for more information.

*Most certainly, the DSDT is not at fault. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)

===Solutions===
You must use a recent (or patched) version of the [[radeonfb]] driver, even if you are only interested in using the X window system. The radeon frame buffer suspends the radeon chip correctly during ACPI sleep. Starting with linux 2.6.18, this patch is in the official (kernel.org) kernels.

If the patch is known to work on your notebook, it is automatically enabled. If you think that your computer would profit from the patch as well, you can force it by including the module parameter {{bootparm|video|radeonfb:force_sleep|1}}. If it does not work this can result in system hangs.

====Problem with radeonfb and X====
In some cases [[radeonfb]] cannot coexist with the [[radeon]] X.org driver (causing corrupted rendering and hangs). Using the <tt>Option "UseFBDev" "True"</tt> of [[radeon]] may help, but this is incompatible with [[radeon]]'s mergedfb mode. A "GPU device layer" architecture which may, one day, resolve this was proposed by Dave Airlie [http://airlied.livejournal.com/#item30632 here] and [http://lkml.org/lkml/2006/7/22/45 here].
{{HELP|Practical solutions for this problem are needed}}

Configurations which exhibit this problem: {{T43}} [[ATI Mobility Radeon X300]] with {{Fedora}} 5 using the [[radeon]] driver, with and without DRI.

Configurations which don't exhibit this problem: {{T41}} [[ATI Mobility Radeon 9000]] running {{Fedora}} 5 and 6 using [[radeon]] driver, with and without DRI.

====Fedora Core====
* Fedora Core 6: Ships with kernel >= 2.6.18, only needs initrd (see below).
* Fedora Core 5: The latest kernel from updates (2.6.18-1.2200.fc5) seems to actually fix this issue, you only have to make custom initrd because the default one does not contain radeonfb.
* Fedora Core 4: Fedora ships a patched radeon frame buffer (radeonfb.ko), but you must enable it yourself. {{Fedora}} compiles it as a module rather than including it in the kernel, therefore you cannot activate it at boot time without a custom initrd. You must arrange for the module to be loaded before X starts (for example, using an init script).
* Fedora Core 3: this is also true for updated kernels (at least for kernel-2.6.12-1.1376_FC3) but '''not''' for the initially shipped version.

====openSuSE====
* openSuSE 10.2: Ships with kernel >= 2.6.18. Needs initrd and boot menu changes. See [[http://en.opensuse.org/SDB:ThinkPadPowerDrain openSuSE SDB article on ThinkPad power drain problem]]

====testing radeonfb without changing initrd====
If you want to try the radeon frame buffer, you can enable it as follows:
*First, switch to a console ({{key|Ctrl}}{{key|Alt}}{{key|F1}}) and log in as root.
*Stop X: {{cmdroot|init 3}}
*Now you can load the module: {{cmdroot|1=modprobe radeonfb force_sleep=1}}
*Finally, resume X: {{cmdroot|init 5}}

====Gentoo====
After installing the patch on {{Gentoo}} (it works fine with gentoo-sources: {{cmdroot|cd /usr/src/linux/drivers/video/aty}}, and execute {{cmdroot|patch -p4 < <patchname>}}, then recompile the kernel), one needs to add {{bootparm|video|radeonfb:force_sleep}} to the kernel parameters.

====including radeonfb into your initrd====
As an alternative you can build your customized initrd. This is as simple as running
:{{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> `uname -r`}}
and replacing the initrd in {{path|/boot/grub/grub.conf}} with your new one. You also need to add the kernel command line argument {{bootparm|video|2=radeonfb:force_sleep}}.

With FC6 and KDE I had to:
*Login as root
*Enter the command as {{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> <kernel version>}}
:e.g. {{cmdroot|1=mkinitrd --with=radeonfb /boot/initrd-2.6.18-1.2798.fc6-my.img 2.6.18-1.2798.fc6}}
:And the kernel command line argument was added to /etc/sysconfig/grub.

==Backlight staying on==
It is possible that [[radeontool]] will help some people if the backlight stays on.
(simply run "radeontool light off" before suspend and "radeontool light on" after resume).
A radeontool patch for freebsd is here: http://www.init-main.com/radeontool.patch (by Takanori Watanabe).

===Notes for gnome-power-manager===
If you suspend from Gnome and need to run radeontool to turn the backlight off you need to find the suspend script for HAL. In Ubuntu, the scripts are located in /usr/share/hal/scripts/. Add the following the script "hal-system-power-suspend":
chvt 1
radeontool light off
And in the resume script ("restore-after-standby"):
radeontool light on
chvt 7

This worked for me. YMMV. [[User:Etnoy|Etnoy]] 16:27, 9 November 2006 (CET)

===For models without Radeon graphics===
The Problem seems to be solved when you use the [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to turn the LCD off before suspending ...
:{{cmdroot|vbetool dpms off}}
and turning it on afterwards again...
:{{cmdroot|vbetool dpms on}}
You have to change to a normal console before turning the LCD off.
Additionally you have to deactivate the Wake-On-Lan feature like mentioned above ...
:{{cmdroot|ethtool -s eth0 wol d}}
With these commands used together the "testing script" reports no high power drain while suspending.

==Other problems causing the power drain==
On my [[R51]] using Gentoo Linux, the high power drain was not caused by the graphics adaptor but by several components not powered down properly before putting the Thinkpad into S3.

If the above did not help you, this might do:

Walk through
/sys/devices/*/*/power/state
and try to disable each of it, every time checking the power drain. (See linux/Documentation/power/devices.txt for values to write into the state-files. 3 should be the value you want to try)
Do the same for other components (Like the Ultrabay, etc.). Please add your experiences here.

===R51: Ultrabay and networking===
On my system, ultrabay and networking light were still on while in S3. So were the devices theirselves.
echo -n eject > /proc/acpi/ibm/bay # Disable ultrabay
ethtool -s eth0 wol d # Disable Wake-On-Lan (And so the eth-adaptor)
echo mem > /sys/power/state # Sleep

For me, this lowered the power drain from >700mW to 338 mW.

===USB===
My initial testing of a [[T43]] (2669-model) revealed no power drain issues. However, after several rounds of BIOS and kernel upgrades I have discovered that the power drain has risen to >700mWh. Having tested things a bit, I have discoved that removing ehci_hcd module solved the high power drain. This is a [[T43]] laptop, with kernel 2.6.17-r5 and BIOS 1.28/EC 1.06. For me, issuing {{cmdroot|modprobe -r ehci_hcd}} before going to sleep and reloading the module ({{cmdroot|modprobe ehci_hcd}}) after waking up dropped the power drain down to 277mWh in suspend2ram, which seems fair. The unloading/reloading can be put into the suitable ACPI script called to suspend the laptop.

===Wake-on-LAN===
Some additional power savings can be achieved by turning off the wake-on-lan ({{cmdroot|ethtool -s eth0 wol d}}). The power drain of the wol feature is far smaller than the radeon bug, but can be noticeable.

How to make use of IrDA

2007-02-28T22:25:50Z

Fluidspace: troubleshoot LSR safety check when synchronizing with a Ericsson T39m mobile phone

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
<div style="margin: 0; margin-right:10px; border: 1px solid #dfdfdf; padding: 0em 1em 1em 1em; background-color:#efefef; align:right;">
The purpose of this document is to get the [[IrDA]] hardware in your ThinkPad operational, setting up communication to other devices is not covered. However, the external links section can prove useful for this.
</div>
|}

== Serial IR (SIR) ==
SIR is limited to serial datarates up to 115.2Kb/s

To use it, run {{cmdroot|irattach /dev/ttyS1 -s; modprobe ircomm-tty}} (on {{Fedora}} 5 just run {{cmdroot|service irda start}}). Then turn on your IrDA-capable device and put it within range, and point your software (e.g., <tt>minicom</tt>) to {{path|/dev/irda0}}.

===Kernel configuration===

Some distributions (e.g., {{Fedora}} 5) already include the equvialent of the following.

==== Linux 2.4 kernel config ====
Edit {{path|/etc/modules.conf}} and add the following lines
alias tty-ldisc-11 irtty
alias char-major-161 ircomm-tty

==== Linux 2.6 kernel config ====
Edit {{path|/etc/modprobe.conf}} and add the following lines
alias tty-ldisc-11 irtty-sir
alias char-major-161 ircomm-tty

== Fast IR (FIR) ==
FIR is the preferred mode of IrDA operation and operates at a bandwidth of 4 Mbps

The chips FIR mode first needs to be activated using the ISA PnP or BIOS method.

{{HINT|Regardless of which method you use, you will still have to set the dongle_id and run setserial as shown further below}}
=== ISA PnP support for nsc-ircc ===

ISA PnP support is '''necessary''' in some cases, as without it the kernel doesn't manage to enable the device by itself in many ThinkPads.

Starting with the 2.6.17-rc1 kernel, the nsc-ircc driver has ISA PnP support. For older kernels you will need patches to allow the loading of the driver without the below BIOS change.

* [http://steffenpingel.de/patches/nsc-ircc-pnp.diff 2.6.10 patch]
* [http://shamrock.dyndns.org/~ln/linux/nsc-ircc-pnp.2.6.12-rc6.diff 2.6.12-rc6 patch]
* [http://shamrock.dyndns.org/~ln/linux/nsc-ircc-pnp.2.6.12.diff 2.6.12 patch (applies cleanly to 2.6.12 through 2.6.15)]

=== NS PC8394T support ===

Thinkpads {{T43}}, {{T43p}} and {{R52}} [http://bugzilla.kernel.org/attachment.cgi?id=8247 needed an extra patch] to detect their [[NS PC8394T]]-based FIR device on kernels before 2.6.18. They also require ISA PnP support in the driver to work, which is available since 2.6.17 (and can be added to 2.6.16 with the patches above).

=== Changing BIOS settings ===
For older kernels (prior to 2.6.17-rc1), the easiest way to activate FIR mode is by entering BIOS setup during boot-up by pressing {{key|F1}} when prompted.
Then, selecting 'Config' followed by 'Infrared' will allow you to control the IrDA operation. Here you will need to select the option to Enable the infra-red port, and ensure the proper resources are set (typically: IO 0x2f8 and IRQ 3). Be sure to save the changes, and then Exit.

{{NOTE|Changing these BIOS settings does not affect Windows 2000 or XP operating systems, but may cause resource issues in older windows versions, or other legacy operating systems.}}

{{WARN|If you change the BIOS settings for IO, IRQ or DMA of the IrDA port, remember to do so accordingly on all examples in this page when applying them to your ThinkPad.}}

===Kernel configuration===
==== Linux 2.4 kernel config ====
Edit {{path|/etc/modules.conf}} and add the following lines

alias irda0 nsc-ircc
options nsc-ircc dongle_id=0x09 io=0x2f8 irq=3 dma=3
pre-install nsc-ircc setserial /dev/ttyS1 uart none port 0 irq 0

==== Linux 2.6 kernel config ====
Edit {{path|/etc/modprobe.conf}} and add the following lines

alias irda0 nsc-ircc
options nsc-ircc dongle_id=0x09 io=0x2f8 irq=3 dma=3
install nsc-ircc /bin/setserial /dev/ttyS1 uart none port 0 irq 0; /sbin/modprobe --ignore-install nsc-ircc

The install line is a work-around for the 8250 serial driver taking over the device, and may not be needed in certain distributions.
Another way to do this is to set this kernel config option:

1. {{kernelconf|CONFIG_SERIAL_8250_RUNTIME_UARTS|(1)|Number of 8250/16550 serial ports to register at runtime|Serial drivers|Character devices|Device Drivers|}}

2. {{kernelconf|CONFIG_SERIAL_8250_NR_UARTS|(4)|Maximum number of 8250/16550 serial ports|Serial drivers|Character devices|Device Drivers|}}

This will prevent the 8250 driver from grabbing any other than the first serial port at boot time or when the module is loaded. You can still add more ports later for example from PC-Card modems, up to CONFIG_SERIAL_8250_NR_UARTS.

==== {{Gentoo}} kernel config ====
Edit / Create {{path|/etc/modules.d/nsc-irrc}} and add the following lines

alias irda0 nsc-ircc
options nsc-ircc dongle_id=0x09 io=0x2f8 irq=3 dma=3

Edit {{path|/etc/modules.autoload.d/kernel-2.6}} and add the following lines

nsc-ircc

If you have serial support build in the kernel, switch it to a module and add it after nsc-ircc to advoid io base and irq conflict. For kernel 2.4, same as 2.6 changing the path to modules.autoload.d/kernel-2.4.

==== {{Debian}} Sarge/Etch kernel config ====
Install irda-utils and set it up for serial port emulation. Edit {{path|/etc/modprobe.d/irda-utils}} and add/change the following lines:

alias irda0 nsc-ircc
options nsc-ircc dongle_id=0x09 io=0x2f8 irq=3 dma=3

Edit / create {{path|/etc/modules.conf}} and add the following line before any references to 8250*, if any:

nsc-ircc

Make sure that module-init-tools has a chance to iterate over {{path|/etc/modules.conf}} before udev does the initial pci hotplug (this is a problem at least in Debian Sarge, when using backported udev packages):

{{cmdroot|cp /etc/rcS.d/S20module-init-tools /etc/rcS.d/S03module-init-tools}}

Note that at S03, module-init-tools cannot run depmod for you, so either do it manually before you reboot into a new kernel, or reboot twice to get it to work right. This is also the reason for using cp instead of mv.

If you have the regular serial port drivers as modules, that's it. Otherwise, try adding the install line described in the Linux 2.6 kernel config section, above, or compile them as modules instead of built-in.

== Known problems ==
* If the FIR mode is not activated, attempts to load the <tt>nsc-ircc</tt> module will result in an error in syslog of "Wrong chip version ff".
* After suspend the <tt>nsc-ircc</tt> module needs to be manually reloaded
* If module reloading does not work after a suspend, try reactivating the IrDA port as well:
rmmod nsc_ircc
echo disable > /sys/devices/pnp0/00\:0d/resources
echo activate > /sys/devices/pnp0/00\:0d/resources
modprobe nsc_ircc
:The value <tt>pnp0/00\:0d</tt> can vary - look for a id file containing IBM0071 or PNP0511, or for a resources file containing the appropriate irq/dma/io values, e.g., using {{cmdroot|grep 0x2f8 /sys/devices/pnp*/*/resources}} .
{{NOTE|The power management issues should be resolved starting with the 2.6.17-rc1 kernel.}}

{{NOTE|Don't understand after inserting modules use irattach irda0 -s and after this you can use eg. minicom over /dev/ircomm0 and test link with irdadump with this I get working FIR on A21m with 2.6.18}}
* If you read something like "ttyS1: LSR safety check engaged!" and "irattach: tcgetattr: Input/output error" in the system log, try limiting the FIR max baud rate (echo 57600 > /proc/sys/net/irda/max_baud_rate). This did the trick for me when I was trying to synchronize my Ericsson T39m with my Thinkpad R51 (multisync, evolution-2.8, KDE 3.5.5, openSUSE 10.2).

== Some other things you might want to do with IrDA ==
* add fast PPP support:
:{{cmdroot|modprobe irnet}}
* if needed, limit further the size of the transmit window
:{{cmdroot|echo 1 > /proc/sys/net/irda/max_tx_window}}
* set the connection speed to 4Mbit in FIR mode:
:{{cmdroot|echo 4000000 > /proc/sys/net/irda/max_baud_rate}}

==LIRC and IrDA==
Usually, IrDA ports are not compatible with LIRC, but you may have luck using lirc_sir.

If loading the <tt>lirc_sir</tt> module shows something like the following in {{cmdroot|dmesg}} output, you are lucky and can use LIRC with the IrDA port to remote control your ThinkPad.
lirc_sir: I/O port 0x02f8, IRQ 3.
lirc_sir: Installed.

If it fails with "Device or resource busy", you may want to install the setserial tool and run it with {{cmdroot|setserial /dev/ttyS1 uart none}}. After that lirc_sir should be loadable.

You might also need to {{cmdroot|modprobe actisys-sir}}, {{cmdroot|modprobe tekram-sir}}, and {{cmdroot|modprobe lirc-sir}} if you are using the SIR on the thinkpad (modules are from kernel 2.6).

Also, do not forget to start the lirc daemon, otherwise no output will be given (you better try running it not as a daemon first, so you can see the output).
lircd -d /dev/lirc0 /etc/lircd.conf --nodaemon
You should see:
lircd: lircd(serial) ready
This means you are good to start {{cmdroot|irrecord}} or {{cmdroot|xmode2}} and check for input.

Once that shows a good output you can configure your remote control.
then use it in applications like mplayer, xine, or KDE's remote controls server.

== External Sources ==
*[http://irda.sourceforge.net/ Linux-IrDA Project] (External)
*[http://pcmcia-cs.sourceforge.net/ Linux PCMCIA Project] (External)
*[http://tpctl.sourceforge.net/ tpctl homepage] (External)
*[http://www.lirc.org/ Linux Infrared Remote Control] (External)

KThinkBat

2007-01-06T16:27:07Z

Fluidspace: Added link to SuSE rpms on Guru's rpm site

==Description==

[https://lepetitfou.dyndns.org/KThinkBat KThinkBat] is a laptop battery monitor for the KDE-Kicker. It is inspired by the Windows Application "Battery Maximizer" which is included with ThinkPads.

It can use the SMAPI BIOS (through the [[tp_smapi]] driver) or [[How to make ACPI work|ACPI]] to collect the data. It shows you the current power consumption of the laptop and brings support for a second battery. It is fully customizable including sizes, color, fonts and battery number

Homepage: https://lepetitfou.dyndns.org/KThinkBat

Author: [https://lepetitfou.dyndns.org/wiki/bin/view/Main/TobiasRoeser Tobias Roeser]

Latest Version (2006-11-18): 0.2.3

==Screenshot==

[[Image:KThinkBat.png]]

Offline Mode: you see how much charge is left and the current discharging rate.

[[Image:KThinkBat_dual.png]]

Online Mode: you see how much charge is left and the current charging rate. This screenshot is taken with the disabled "summarize batteries" option.

==Installation==

KThinkBat uses the autotools. For a standard installation use

./configure
make
su -c 'make install'

Alternatively, to minimize filesystem clutter you can install KThinkBat into {{path|/opt/kthinkbat}} and add just a few symlinks under {{path|/usr}}:

mkdir -p /opt/kthinkbat
./configure --prefix=/opt/kthinkbat
make
make install
cd /usr/lib/kde3
ln -vfs ../../../opt/kthinkbat/lib/* ./
cd /usr/share/apps/kicker/applets
ln -vfs ../../../../../opt/kthinkbat/share/apps/kicker/applets/kthinkbat.desktop ./

(The above paths are for {{Fedora}} 4 and 5, and may need to be adjusted for other distributions.)

If you already have the applet running, run {{cmduser|killall kicker; kicker}} to restart it.

==Gentoo==
You can use the the ebuild from this [https://lepetitfou.dyndns.org/svn/portage-overlay-lefou/trunk/ portage overlay], category/package: [https://lepetitfou.dyndns.org/svn/portage-overlay-lefou/trunk/app-laptop app-laptop]/[https://lepetitfou.dyndns.org/svn/portage-overlay-lefou/trunk/app-laptop/kthinkbat kthinkbat].

==openSuSE==

On [http://linux01.gwdg.de/~pbleser/index.php Guru's RPM Site] there are [http://linux01.gwdg.de/~pbleser/rpm-navigation.php?cat=System/kthinkbat/ RPMs for KThinkBat 0.2.3 and 0.2.2] compiled for all SuSE versions back to 9.3.

==Download==

* [https://lepetitfou.dyndns.org/KThinkBat#Download Download from the KThinkBat Site]

==See Also==

* [[How to use UltraBay batteries]]

[[Category:Tools]] [[Category:Gentoo]]