Zarządzanie zasilaniem

1.  Wprowadzenie

Pojemność i żywotność baterii w laptopach w ostatnich latach znacznie się poprawiła. Niemniej jednak nowoczesne procesory pożerają znacznie więcej energii niż te starsze, zaś każde pokolenie laptopów wprowadza coraz więcej urządzeń głodnych energii. To dlatego zarządzanie zasilaniem jest teraz bardziej istotne niż kiedykolwiek wcześniej. Zwiększanie żywotności baterii niekoniecznie jest równoznaczne z kupnem nowych. Wiele można osiągnąć stosując inteligentną politykę zarządzania zasilaniem.

Szybki przegląd

Ten przewodnik opisuje zarządzanie zasilaniem dla laptopów. Chociaż niektóre części mogą się przydać również serwerom, posiadacze innych komputerów nie powinni kierować się tym przewodnikiem, gdyż niektóre polecenia w nim zawarte mogą wyrządzić szkody. Proszę nie stosować niczego z tego przewodnika do serwera, jeśli nie jest się pewnym, że jest to nieszkodliwe działanie.

Ponieważ przewodnik ten stał się nieco długi, poniżej znajduje się krótki przegląd jego zawartości, który pomoże się w nim szybko zorientować.

Rozdział Warunki wstępne mówi o pewnych wymaganiach, które muszą być spełnione, aby dowolne z poniższych urządzeń działało. Są nimi ustawienia BIOS-u, konfiguracja jądra oraz pewne ułatwienia w środowisku użytkownika. Następne 3 rozdziały skupiają się na urządzeniach, które zwykle pożerają najwięcej energii - procesor, ekran oraz dysk twardy. Każde z nich może być oddzielnie skonfigurowane. Zarządzanie zasilaniem procesora pokazuje jak ustawić częstotliwość procesora, aby zachować maksymalnie dużo energii bez straty wydajności. Kilka różnych sztuczek zapobiega działaniu dysku twardego, kiedy nie jest to konieczne w Zarządzaniu zasilaniem dla dysku twardego (zmniejszanie poziomu hałasu jako miły skutek uboczny). Parę uwag o bezprzewodowych kartach sieciowych oraz USB kończą część o urządzeniach w Zarządzaniu zasilaniem dla innych urządzeń podczas, gdy inny rozdział jest poświęcony (raczej eksperymentalnie) stanom uśpienia (ang. sleep states). Ostatni rozdział, Rozwiązywanie problemów, pokazuje najczęstsze pułapki.

Budżet energii dla każdego składnika

Ilustracja 1.1: Budżet energii dla każdego składnika

Niemal każda część może działać w różnych stanach - chociażby wyłączonym, uśpionym, bezczynnym, czynnym - pochłaniając różne ilości energii. Najwięcej pożerają ekran LCD, procesor, chipset i dyski twarde. Często możemy uaktywnić niezależne od systemu operacyjnego zarządzanie zasilaniem w BIOS-ie, jednak poprzez inteligentne ustawienie tego w systemie operacyjnym, dostosowujące się do różnych, sytuacji możemy osiągnąć znacznie więcej.

2.  Warunki wstępne

Przed wejściem w szczegóły zarządzania zasilaniem poszczególnych urządzeń należy się upewnić, że spełnione są pewne wymagania. Po sprawdzeniu ustawień w BIOS-ie, niektóre opcje w jądrze mogą być uaktywnione - w skrócie są nimi ACPI, stany uśpienia oraz skalowanie częstotliwości procesora. Ponieważ oszczędzanie energii wiąże się ze stratą wydajności lub zwiększonym opóźnieniem, więc powinno to być załączone tylko podczas pracy na bateriach. Tu przychodzi z pomocą nowy poziom uruchamiania o nazwie battery.

BIOS

Najpierw przypatrzmy się ustawieniom zarządzania zasilania w BIOS-ie. Najlepszym rozwiązaniem jest, aby połączyć polityki BIOS-u oraz systemu operacyjnego, lecz na dzień dzisiejszy lepiej wyłączyć większość ustawień w BIOS-ie. To zapewnia, że BIOS nie będzie wtrącał do naszej polityki zasilania. Nie należy zapomnieć, aby ponownie sprawdzić ustawienia BIOS-u po skonfigurowaniu czegokolwiek.

Ustawianie flag USE

Po pierwsze należy sprawdzić czy flaga acpi jest ustawiona w /etc/make.conf. Innymi flagami, które mogą mieć dla nas znaczenie są apm, lm_sensors, nforce2, nvidia, pmu. Więcej informacji na ich temat można znaleźć w /usr/portage/profiles/use*.desc. Jeżeli zapomnimy ustawić którejś z nich, możemy przekompilować pakiety jej używające przy użyciu opcji --newuse dla emerge (Zobacz man 1 emerge ).

Konfiguracja jądra

Wsparcie dla ACPI (Advanced Configuration and Power Interface - dosłownie zaawansowana konfiguracja i interfejs zasilania) w jądrze jest nadal w fazie rozwoju. Użycie świeżych źródeł jądra zapewnia najnowszą stabilną wersję.

W Portage znajduje się wiele różnych rodzajów źródeł jądra. Osobiście polecamy używanie gentoo-sources lub tuxonice-sources. Te ostatnie zawierają patche dla Software Suspend 2 (więcej w rozdziale na temat stanów uśpienia). Podczas konfiguracji jądra należy zaznaczyć przynajmniej poniższe opcje:

Power Management Options --->
  [*] Power Management Support
  [ ] Software Suspend

  ACPI( Advanced Configuration and Power Interface ) Support --->
    [*] ACPI Support
    [ ]   Sleep States
    [ ]   /proc/acpi/sleep (deprecated)
    [*]   zasilacz sieciowy Adapter
    [*]   Battery
    <M>   Button
    <M>   Video
    [ ]  Generic Hotkey
    <M>   Fan
    <M>   Processor
    <M>     Thermal Zone
    < >   ASUS/Medion Laptop Extras
    < >   IBM ThinkPad Laptop Extras
    < >   Toshiba Laptop Extras
    (0)  Disable ACPI for systems before Jan 1st this year
    [ ]   Debug Statements
    [*]   Power Management Timer Support
    < > ACPI0004, PNP0A05 and PNP0A06 Container Driver (EXPERIMENTAL)

  CPU Frequency Scaling --->
    [*] CPU Frequency scaling
    [ ] Enable CPUfreq debugging
    < > CPU frequency translation statistics
    [ ] CPU frequency translation statistics details
          Default CPUFreq governor (userspace)
    <*>   'performance' governor
    <*>   'powersave' governor
    <*>   'ondemand' cpufreq policy governor
    <*>   'conservative' cpufreq governor
    <*>   CPU frequency table helpers
    <M> ACPI Processor P-States driver
    <*> CPUFreq driver for your processor

Samemu należy zdecydować czy chcemy włączyć Software Suspend czy Stanów uśpienia (patrz poniżej). Jeśli posiadamy laptop firmy ASUS, Medion lub Toshiba, włączamy odpowiednią opcję.

Jądro musi wiedzieć w jaki sposób ma włączyć skalowanie częstotliwości procesora. Ponieważ każdy typ procesora ma różny interfejs, więc musimy wybrać odpowiedni sterownik dla naszego procesora. Należy tu uważać - włączenie Intel Pentium 4 clock modulation w systemie z Pentium M prowadzi do dziwnych rezultatów. Należy zapoznać się z dokumentacją jądra, jeśli nie jesteśmy pewni którą opcję wybrać.

Kompilujemy jądro i upewniamy się, że podczas startu systemu ładują się odpowiednie moduły i uruchamiają jądro z włączonym ACPI. Następnie wykonujemy emerge sys-power/acpid, aby uzyskać demon acpi. Informuje on o zdarzeniach takich jak przełączanie z zasilacza sieciowego do baterii lub zamykaniu ekranu. Należy się upewnić, że moduły zostały załadowane, jeśli nie wkompilowaliśmy ich w jądro, po czym uruchamiamy acpid za pomocą polecenia /etc/init.d/acpid start. Wykonujemy rc-update add acpid default, aby ładować ten moduł podczas startu systemu. Wkrótce nauczymy się go używać.

# emerge sys-power/acpid
# /etc/init.d/acpid start
# rc-update add acpid default

Tworzenie poziomu uruchamiania o nazwie battery

Domyślnie zarządzanie zasilaniem włączy się tylko kiedy to będzie potrzebne - podczas pracy na bateriach. Aby wykonać przełączenie pomiędzy zasilaczem sieciowym a wygodną baterią, stworzymy poziom uruchamiania o nazwie battery, który będzie zawierał wszystkie skrypty uruchamiające i wyłączające zarządzanie zasilaniem.

# cd /etc/runlevels
# cp -a default battery

Skończone. Nowy poziom uruchamiania o nazwie battery zawiera wszystko co poziom default, ale nie mamy jeszcze automatycznego przełącznika pomiędzy nimi dwoma. Czas to zmienić.

Reagowanie na zdarzenia ACPI

Typowymi zdarzeniami ACPI są zamykanie ekranu, zmiana źródła zasilania lub wciśnięcie przycisku uśpienia. Ważnym zdarzeniem jest zmiana źródła zasilania, który powinien spowodować przełączenie poziomów uruchamiania. Zajmie się tym poniższy skrypt:

Najpierw potrzebujemy skryptu, który przełącza poziom uruchamiania na default lub battery zależnie od źródła zasilania. Skrypt używa programu on_ac_power z pakietu sys-power/powermgmt-base, należy się zatem upewnić czy jest on zainstalowany w naszym systemie.

# emerge powermgmt-base

Teraz jesteśmy gotowi do rozpoznania źródła zasilania, poprzez wykonanie on_ac_power && echo Podłączone do prądu || echo Działa z baterii w powłoce. Poniższy skrypt jest odpowiedzialny za zmianę poziomów uruchamiania. Należy zapisać go jako /etc/acpi/actions/pmg_switch_runlevel.sh

#!/bin/bash

# POCZĄTEK konfiguracji
RUNLEVEL_AC="default"
RUNLEVEL_BATTERY="battery"
# KONIEC konfiguracji


if [ ! -d "/etc/runlevels/${RUNLEVEL_AC}" ]
then
        logger "${0}: Poziom uruchomienia ${RUNLEVEL_AC} nie istnieje. Przerwano."
        exit 1
fi

if [ ! -d "/etc/runlevels/${RUNLEVEL_BATTERY}" ]
then
        logger "${0}: Poziom uruchomienia ${RUNLEVEL_BATTERY} nie istnieje. Przerwano."
        exit 1
fi

if on_ac_power
then
        if [[ "$(</var/lib/init.d/softlevel)" != "${RUNLEVEL_AC}" ]]
  then
            logger "Przełączanie do poziomu ${RUNLEVEL_AC}"
            /sbin/rc ${RUNLEVEL_AC}
        fi
elif [[ "$(</var/lib/init.d/softlevel)" != "${RUNLEVEL_BATTERY}" ]]
then
        logger "Przełączanie do poziomu ${RUNLEVEL_BATTERY}"
        /sbin/rc ${RUNLEVEL_BATTERY}
fi

Nie zapomnijmy o ustawieniu, aby plik był wykonywalny (chmod +x /etc/acpi/actions/pmg_switch_runlevel.sh). Ostatnią rzeczą jaką musimy jeszcze zrobić, jest wywołanie skryptu zawsze, gdy zmieni się źródło zasilania. Możemy tego dokonać poprzez przechwytywanie zdarzeń ACPI, używając acpid. Po pierwsze trzeba sprawdzić, jakie zdarzenia są wywoływane, gdy zmienia się źródło zasilania. Na większości laptopów są to kolejno ac_adapter oraz battery, jednak należy pamiętać, iż na naszym mogą się one nazywać inaczej.

# tail -f /var/log/messages | grep "received event"

Uruchamiamy zatem powyższe polecenie, a następnie wyciągamy kabel zasilający. Naszym oczom powinno ukazać się coś takiego:

[Tue Sep 20 17:39:06 2005] received event "ac_adapter AC 00000080 00000000"
[Tue Sep 20 17:39:06 2005] received event "battery BAT0 00000080 00000001"

Część, która nas interesuje znajduje się w cudzysłowiu zaraz za received event. Będą one zawarte w plikach, które stworzymy poniżej. Nie musimy się martwić, jeżeli nasz system tworzy wiele zdarzeń lub zawsze takie same. Tak długo jak jakiekolwiek zdarzenie jest generowane, zmiana poziomu uruchamiania będzie działać.

# poniżej zastępujemy "ac_adapter" zdarzeniem stworzonym przez laptop
# Na przykład: ac_adapter.* will match ac_adapter AC 00000080 00000000
event=ac_adapter.*
action=/etc/acpi/actions/pmg_switch_runlevel.sh %e

# poniżej zastępujemy "battery" zdarzeniem stworzonym przez laptop
# Na przykład: battery.* will match battery BAT0 00000080 00000001
event=battery.*
action=/etc/acpi/actions/pmg_switch_runlevel.sh %e

Na koniec acpid musi zostać ponownie uruchomione w celu zastosowania zmian.

# /etc/init.d/acpid restart

Próbujemy: wkładamy i wyciągamy wtyczkę zasilacza sieciowego i obserwujemy syslog w poszukiwaniu komunikatów "Switching to AC mode" lub "Switching to battery mode". Należy spojrzeć do części Rozwiązywanie problemów, jeśli skrypt nie będzie w stanie wykryć poprawnie źródła.

Dzięki naturze mechanizmu zdarzeń, nasz laptop załaduje się w poziom uruchamiania default bez względu na to czy pobieramy energię z zasilacza sieciowego czy z baterii. Jest to dobre rozwiązanie, jeżeli laptop jest zasilany z gniazda sieciowego, jednak w przeciwnym razie chcielibyśmy, aby system był ładowany do poziomu battery. Możemy dodać dodatkowy wpis do bootloadera softlevel=battery, ale możemy zapomnieć go wybrać, gdy będziemy pracowali na baterii. Lepszym rozwiązaniem jest sfałszować zdarzenie ACPI pod koniec procesu uruchamiania systemu i niech skrypt /etc/acpi/default.sh zdecyduje czy zmiana poziomu uruchamiania jest konieczna. Otwieramy /etc/conf.d/local.start w ulubionym edytorze i dodajemy następujące linie:

# Fałszywe zdarzenie acpi, aby przełączyć poziom uruchamiania, jeśli pracujemy na bateriach
/etc/acpi/actions/pmg_switch_runlevel.sh "battery/battery"

W ten sposób przygotowani, możemy włączyć polityki zarządzania zasilaniem dla konkretnych urządzeń.

3.  Zarządzanie zasilaniem dla procesora

Procesory dla komputerów przenośnych mogą operować na różnych częstotliwościach. Niektóre pozwalają również na zmianę napięcia zasilającego. Przez większość czasu procesor nie musi pracować na pełnych obrotach a zmniejszenie częstotliwości może zachować dużo energii - często bez straty wydajności.

Pewne terminy techniczne

Podczas skalowania częstotliwości procesora możemy natknąć się na pewne nieznane nam terminy techniczne. Poniżej znajduje się krótki wstęp.

Po pierwsze jądro musi być w stanie zmienić częstotliwość procesora. Sterownik procesora CPUFreq zna te polecenia. Stąd jest ważne, aby wybrać właściwy procesor w jądrze. Powinniśmy już to mieć za sobą. Kiedy jądro wie jak zmieniać częstotliwości, powinno również wiedzieć jaką częstotliwość obecnie ustawić. To jest wykonywane według polityki, która składa się z polityki CPUFreq oraz regulatora. Polityką CPUfreq są tylko 2 liczby, które definiują zakres częstotliwości - minimalną i maksymalną częstotliwość. Regulator teraz decyduje, którą z dostępnych częstotliwości użyć. Na przykład, regulator powersave zawsze wybiera najniższą dostępną częstotliwość, regulator performance najwyższą. Regulator userspace nie podejmuje żadnej decyzji, ale wybiera to co chce użytkownik (lub program w przestrzeni użytkownika) chce - co oznacza, że czyta on częstotliwość z /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed.

Nie brzmi to jak dynamiczne skalowanie częstotliwości i wcale tym nie jest. Jednakże dynamika może być osiągnięta, za pomocą różnych podejść. Na przykład, regulator ondemand wykonuje swoje decyzje zależnie od obciążenia procesora. To samo jest wykonane za pomocą narzędzi takich jak cpudyn, cpufreqd, powernowd i wielu innych. Zdarzenia ACPI mogą również być użyte do włączenia lub wyłączenia dynamicznych zmian częstotliwości zależnie od źródła zasilania.

Ręczne ustawianie częstotliwości

Obniżanie prędkości oraz napięcia CPU ma dwie zalety: z jednej strony mniej energii jest zużywane, z drugiej zmniejsza się ilość wydzielanego ciepła, gdyż system nie działa na pełnych obrotach. Główną wadą tego rozwiązania jest oczywiście utrata wydajności. Zmniejszenie prędkość procesora jest wyborem pomiędzy utratą wydajności, a zaoszczędzeniem energii.

Nadszedł czas, aby sprawdzić czy zmienianie częstotliwości CPU działa. Zainstalujmy dodatkowe narzędzie, które jest bardzo użyteczne w celach diagnostycznych: sys-power/cpufrequtils.

# emerge cpufrequtils
# cpufreq-info

Poniżej znajduje się przykładowe wyjście:

cpufrequtils 0.3: cpufreq-info (C) Dominik Brodowski 2004
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
  driver: centrino
  CPUs which need to switch frequency at the same time: 0
  hardware limits: 600 MHz - 1.40 GHz
  available frequency steps: 600 MHz, 800 MHz, 1000 MHz, 1.20 GHz, 1.40 GHz
  available cpufreq governors: conservative, ondemand, powersave, userspace, performance
  current policy: frequency should be within 924 MHz and 1.40 GHz.
    The governor "performance" may decide which speed to use
    within this range.
  current CPU frequency is 1.40 GHz

Następnie należy pobawić się cpufreq-set, aby się upewnić, że przełączanie częstotliwości działa. Na przykład uruchamiamy cpufreq-set -g ondemand, aby uruchomić regulatora ondemand i sprawdzić zmianę za pomocą cpufreq-info. Jeśli nie zadziała jak oczekiwaliśmy, wtedy możemy znaleźć pomoc w części Rozwiązywanie problemów na końcu tego przewodnika.

Zautomatyzowana zmiana częstotliwości

Powyższe rozwiązanie jest dosyć dobre, ale nie do codziennego użytku. Lepiej, aby system ustawił automatycznie odpowiednią częstotliwość. W tym celu istnieją różne podejścia. Poniższa tabela pokazuje szybki przegląd wszystkich możliwości, aby pomóc wybrać jeden z nich. Jest ona z grubsza podzielona na 3 kategorie jądro dla podejść, które wymagają tylko wsparcia jądra, demon dla programów, które są uruchomione w tle oraz graficzne dla programów, które dostarczają graficzny interfejs użytkownika dla łatwej konfiguracji i zmian.

Dopasowywanie częstotliwości do obecnego obciążenia procesora jest z pozoru łatwym zadaniem, ale nie jest to takie trywialne. Zły algorytm może spowodować ciągłe przełączanie pomiędzy 2 częstotliwościami lub marnowanie energii poprzez ustawienie częstotliwości nieodpowiedniej do obciążenia procesora.

Który wybrać? Jeśli nie wiemy, to wybieramy cpufreqd:

# emerge cpufreqd

cpufreqd może być skonfigurowany poprzez edycję /etc/cpufreqd.conf. Domyślna konfiguracja może wyglądać trochę nieładnie. Ja polecam zastąpienie jej konfiguracją napisaną przez jednego z deweloperów Gentoo - Henrika Brixa Andersena (znajduje się poniżej). Należy zauważyć, że potrzebujemy cpufreqd-2.0.0 lub późniejszego. Wcześniejsze wersje mają rożny format pliku konfiguracyjnego.

[General]
pidfile=/var/run/cpufreqd.pid
poll_interval=3
enable_plugins=acpi_ac, acpi_battery
enable_remote=1
remote_group=wheel
verbosity=5
[/General]

[Profile]
name=ondemand
minfreq=0%
maxfreq=100%
policy=ondemand
[/Profile]

[Profile]
name=conservative
minfreq=0%
maxfreq=100%
policy=conservative
[/Profile]

[Profile]
name=powersave
minfreq=0%
maxfreq=100%
policy=powersave
[/Profile]

[Profile]
name=performance
minfreq=0%
maxfreq=100%
policy=performance
[/Profile]

[Rule]
name=battery
ac=off
profile=conservative
[/Rule]

[Rule]
name=battery_low
ac=off
battery_interval=0-10
profile=powersave
[/Rule]

[Rule]
name=ac
ac=on
profile=ondemand
[/Rule]

Uruchamiamy demon oraz dodajemy go do poziomów default oraz battery.

# rc-update add cpufreqd default battery
# rc

Niekiedy wskazane jest użycie innej polityki niż wybiera demon. Np. kiedy poziom baterii jest niski, ale wiemy, iż niedługo będziemy mogli podłączyć go do prądu. W tym przypadku możemy przełączyć się na tryb ręcznego sterowania cpufreqd, przy użyciu cpufreqd-set manual oraz wybrać jedno ze skonfigurowanych zachowań (ich listę możemy uzyskać poprzez cpufreqd-get). Możemy opuścić tryb ręcznego sterowania poprzez wpisanie cpufreqd-set dynamic.

Weryfikowanie rezultatu

Ostatnią rzeczą jest sprawdzenie czy nasza polityka wykonuje dobrą robotę. Łatwym sposobem, aby to sprawdzić jest monitorowanie CPU:

# watch grep \"cpu MHz\" /proc/cpuinfo

Jeśli /proc/cpuinfo nie jest aktualizowane (patrz Rozwiązywanie problemów), to monitorujemy częstotliwość za pomocą sys-apps/x86info:

# watch x86info -mhz

Zależnie od ustawień, prędkość CPU powinna wzrastać pod dużym obciążeniem, maleć podczas bezczynności lub pozostać na tym samym poziomie. Używając cpufreqd, jeśli mamy ustawioną rozwlekłość (ang. verbosity) na 5 lub więcej w cpufreqd.conf otrzymamy dodatkowe informacje o tym co się dzieje, za pomocą programu logującego (syslog).

4.  Zarządzanie zasilaniem dla ekranu LCD

Jak możemy zauważyć na rysunku 1.1, ekran LCD pożera największą część energii (nie dotyczy to komputerów stacjonarnych). Stąd jest to dosyć ważne nie tylko, aby wyłączać ekran kiedy nie jest używany, ale również aby zmniejszyć podświetlenie matrycy jeśli to będzie możliwe. Większość laptopów oferuje kontrolowanie przyciemniania ekranu.

Ustawienia stanu gotowości

Po pierwsze należy sprawdzić czasy oczekiwania, zawieszenia i wyłączenia ekranu. Ponieważ to zależy silnie od naszego menedżera okien, Wystarczy sprawdzić 2 popularne miejsca: zaczernienie terminala może być ustawione za pomocą setterm -blank <liczba_minutM>, setterm -powersave on oraz setterm -powerdown <liczba_minutM>. Dla Xorg, modyfikujemy /etc/X11/xorg.conf w następujący sposób:

Section "ServerFlags"
  Option  "BlankTime"  "5"  # Zaczernienie obrazu po 5 minutach
(udawane)
  Option  "StandbyTime"  "10"  # Wyłączenie obrazu po 10 minutach
(DPMS)
  Option  "SuspendTime"  "20"  # Całkowite zawieszenie po 20
minutach
  Option  "OffTime"  "30"  # Wyłączenie po pół godzinie
  [...]
EndSection

[...]

Section "Monitor"
  Identifier  [...]
  Option  "DPMS"
  [...]
EndSection

Zmniejszanie podświetlenia

Prawdopodobnie bardziej istotną sprawą jest zmniejszenie podświetlenia. Jeśli mamy dostęp do ustawień przyciemniania poprzez jakieś narzędzie, napiszemy mały skrypt, który będzie zmniejszał podświetlenie w trybie pracy na baterii oraz osadzimy go w poziomie uruchamiania o nazwie battery. Następujący skrypt powinien działać na większości Thinkpadów IBM-a oraz laptopach firmy Toshiba. W pierwszym przypadku należy uaktywnić odpowiednie opcje w jądrze, natomiast przy laptopach Toshiby zainstalować sys-power/acpitool i nie stosować poniższej konfiguracji thinkpad_acpi (dawniej zwany ibm_acpi)..

Aby móc ustawić poziom jasności, moduł thinkpad_acpi musi być załadowany z parametrem eksperymentalnym.

(Przed przystąpieniem, proszę przeczytać powyższe ostrzeżenia!)
# echo "options thinkpad_acpi experimental=1" >> /etc/modprobe.d/thinkpad_acpi
# update-modules
# echo thnikpad_acpi >> /etc/modules.autoload.d/kernel-2.6
# modprobe thnikpad_acpi

To powinno działać bez komunikatów o błędach, plik /proc/acpi/ibm/brightness powinien być stworzony po załadowaniu modułu. Skrypt startowy zajmie się wybieraniem jasności w zależności od źródła zasilania.

# Należy zajrzeć do /proc/acpi/ibm/brightness, aby uzyskać dostępne wartości
# Proszę przeczytać /usr/src/linux/Documentation/thnikpad-acpi.txt

# poziom jasności w trybie ac. Domyślnie 7.
BRIGHTNESS_AC=7

# poziom jasności w trybie battery. Domyślnie 4.
BRIGHTNESS_BATTERY=4

#!/sbin/runscript

set_brightness() {
    if on_ac_power
    then
        LEVEL=${BRIGHTNESS_AC:-7}
    else
        LEVEL=${BRIGHTNESS_BATTERY:-4}
    fi

    if [ -f /proc/acpi/ibm/brightness ]
    then
        ebegin "Ustawianie jasności LCD"
        echo "level ${LEVEL}" > /proc/acpi/ibm/brightness
        eend $?
    elif [[ -e /usr/bin/acpitool && -n $(acpitool -T | grep "LCD brightness") ]]
    then
        ebegin "Ustawianie jasności LCD"
        acpitool -l $LEVEL >/dev/null || ewarn "Ustawienie jasności niemożliwe"
        eend $?
    else
        ewarn "Regulacja jasności LCD nie jest wspierana."
        ewarn "Dla Thinkpadów IBM czy thnikpad_acpi jest załadowane"
        ewarn "Dla laptopów Toshiba, należy zainstalować sys-power/acpitool"
    fi
}

start() {
    set_brightness
}

stop () {
    set_brightness
}

Kiedy skończymy, należy się upewnić, że jasność jest dobierana automatycznie poprzez dodanie tego skryptu do poziomu uruchamiania o nazwie "battery".

# chmod +x /etc/init.d/lcd-brightness
# rc-update add lcd-brightness "battery"
# rc

5.  Zarządzanie zasilaniem dla dysku twardego

Dyski twarde zużywają mniej energii w trybie uśpienia. Zatem nabiera sensu uaktywnienie udogodnień związanych z zachowywaniem energi, gdy dysk nie jest używany przez dłuższy czas. Poniżej opisane zostały dwa sposoby dokonania tego. Po pierwsze laptop-mode zachowuje dużo energii spowodowanych kilkoma sposobami, które powstrzymają nas lub opóźniają dostęp do zapisu na dysku. Wadą takiego rozwiązania jest to, że przy opóźnionym dostępie do zapisu kernel może spowodować krytyczne błędy, które mogą być znacznie bardziej niebezpieczne dla naszych danych. Musimy się zatem najpierw upewnić czy nie mamy uruchomionych procesów, które regularnie zapisują coś na dysk twardy, a dopiero następnie możemy uaktywnić udogodnienia związane z zachowaniem energii używając hdparm.

Zwiększanie czasu bezczynności - laptop-mode

Kernele 2.6 zawierają tzw. laptop-mode. Kiedy jest on aktywny, brudne bufory (ang. Dirty Buffers) są zapisywane na dysk przy odczytywaniu oraz po każdych 10 lub więcej minutach (a nie 30 sekundach). Minimalizuje to ilość razy, w których dysk twardy musi być się rozkręcać.

# emerge laptop-mode-tools

laptop-mode-tools ma swój plik konfiguracyjny w /etc/laptop-mode/laptop-mode.conf. Należy go dopasować do własnych upodobań (jest dobrze skomentowany), a następnie wykonać rc-update add laptop_mode battery aby uruchamiał się zawsze przy starcie systemu.

Ostatnie wersje laptop-mode (1.11 i nowsze) zawierają nowe narzędzie o nazwie lm-profiler. Monitoruje on użycie dysku oraz działające usługi sieciowe, oraz sugeruje, które z nich wyłączyć gdy są nie używane. Możemy je wyłączyć poprzez wbudowane w laptop-mode-tools wsparcie dla poziomów uruchamiania (który będzie "reverted" przez /sbin/rc/ w Gentoo) lub używając poziomów default/battery (polecane rozwiązanie).

# lm-profiler
Profiling session started.
Time remaining: 600 seconds
[4296896.602000] amarokapp
Time remaining: 599 seconds
[4296897.714000] sort
[4296897.970000] mv
Time remaining: 598 seconds
Time remaining: 597 seconds
[4296900.482000] reiserfs/0

Po 10-cio minutowym "testowaniu" naszego systemu, lm-profiler pokaże listę usług, które w tym czasie wykonywały jakieś operacje na dysku.

Program:     "atd"
Reason:      standard recommendation (program may not be running)
Init script: /etc/init.d/atd (GUESSED)

Do you want to disable this service in battery mode? [y/N]: n

Aby zablokować atd, jak zostało to pokazane w powyższym przykładzie, powinniśmy uruchomić rc-update del atd battery. Należy być ostrożnym aby przypadkiem nie wyłączyć usług, które są potrzebne do poprawnego działania systemy - lm-profiler może czasem wytworzyć złe informacje. Nie należy zatem wyłączać usług jeżeli nie jesteśmy pewni czy są one potrzebne.

Limitowanie dostępu do zapisu

Jeżeli z jakiegoś powodu nie chcemy używać laptop-mode, musimy trochę się natrudzić aby zablokować usługi, które zapisują dane na nasz dysk. syslogd jest dobrym kandydatem aby nam w tym pomóc, Prawdopodobnie nie chcemy całkowicie go wyłączyć, ale możliwe jest zmodyfikowanie pliku konfiguracyjnego tak, aby "niepotrzebne" rzeczy nie były logowane a co za tym idzie nie tworzyły transferu na dysku. Dla przykładu Cups zapisuje co jakiś czas dane na dysk, więc jedynym rozwiązaniem jest wyłączenie go i ręczne włączanie jedynie gdy będzie nam potrzebny.

# rc-update del cupsd battery

Możemy również użyć lm-profiler z pakietu laptop-mode-tools (patrz wyżej) w celu znalezienia usług do wyłączenia. Kiedy tylko pozbędziemy się ich wszystkich, możemy zająć się konfiguracją hdparm.

hdparm

Drugą możliwością jest użycie hdparm. Jeśli używamy tryby laptop-mode należy pominąć ten krok. Jeśli nie, wyedytujmy /etc/conf.d/hdparm i dodajmy poniższe wartości dla dysku. W tym przypadku dysk jest nazwany hda.

hda_args="-q -S12"

Zarządzanie energią dla dysku zostanie aktywowane. Jeśli kiedykolwiek sytuacja będzie wymagała jego wyłączenia, w pliku /etc/conf.d/hdparm można zmienić wartość na -q -S0 lub uruchomić hdparm -q -S0 /dev/hda.

Aby dowiedzieć się o dostępnych opcjach należy spojrzeć do man hdparm. Chociaż uruchomienie hdparm jest zawsze możliwe poprzez wykonanie polecenia /etc/init.d/hdparm start, to znacznie łatwiej jest gdy proces ten przechodzi automatycznie podczas zmiany poziomu uruchamiania. Aby tego dokonać, należy dodać hdparm do odpowiedniego poziomu uruchamiania.

# rc-update add hdparm battery

Inne sztuczki

Inną możliwością jest wyłączenie swapa podczas pracy na bateriach. Przed napisaniem przełącznika swapa, należy się upewnić, że mamy dostatecznie dużo pamięci RAM i swap nie jest używany zbyt często, w przeciwnym wypadku możemy mieć duże problemy.

Jeśli nie chcemy używać laptop-mode, nadal możemy zmniejszyć dostęp do dysku poprzez zamontowanie pewnych katalogów jako tmpfs - próby zapisu nie są zachowywane na dysku, ale w głównej pamięci i zostają utracone przy odmontowywaniu. Często jest użyteczne, aby zamontować w ten sposób /tmp - nie musimy zwracać szczególnej uwagi, ponieważ zostaje on skasowany po każdym ponownym uruchomieniu komputera niezależnie czy zamontujemy go na dysku czy do RAM-u. Należy się jedynie upewnić, że mamy wystarczającą ilość pamięci oraz, że żaden program (jak klient ściągający lub narzędzie pakujące) nie potrzebuje dodatkowej przestrzeni w /tmp. Aby to włączyć, włączamy wsparcie dla tmpfs w jądrze i dodajemy następującą linię do /etc/fstab:

none  /tmp  tmpfs  size=32m  0 0

6.  Zarządzanie zasilaniem dla innych urządzeń

Zarządzanie zasilaniem dla kart graficznych

W przypadku gdy posiadamy kartę graficzną ATI wspierającą PowerPlay (dynamiczne skalowanie zegara procesora graficznego), możemy uaktywnić je w naszym X.org. Otwórzmy zatem plik /etc/X11/xorg.conf a następnie dodajmy (lub uaktywnijmy) opcję DynamicClocks w sekcji "Device". Należy jednak pamiętać, że to udogodnienie może powodować zawieszanie się niektórych komputerów.

Section "Device"
[...]
Option  "Dynamic Clocks" "on"
EndSection

Zarządzanie zasilaniem dla kart sieci bezprzewodowych

Karty sieci bezprzewodowych również pochłaniają sporo energii. Należy dodać je do trybu zarządzania zasilaniem tak jak zostało to dokonane w przypadku dysku.

Aby automatycznie włączyć zarządzanie energią dla karty bezprzewodowej należy uaktywnić odpowiednie opcje w /etc/conf.d/net, jak poniżej.

iwconfig_wlan0="power on"

Więcej szczegółów można uzyskać w man iwconfig. Jeśli sterownik i punkt dostępu wspierają zmianę sygnału, jest możliwość zaoszczędzenia jeszcze większej ilości energii.

Zarządzanie zasilaniem dla USB

Istnieją dwa główne problemy z urządzeniami USB odnoszące się do pochłaniania energii: pierwszy, urządzenia jak mysz USB, aparat cyfrowy lub USB sticks pożerają energię, gdy są podpięte. Nie możemy tego ominąć (nie mniej jednak należy je odłączyć jeśli nie są potrzebne). Po drugie, kiedy urządzenia USB są podpięte, wtedy sterownik hosta USB okresowo uzyskuje dostęp do magistrali, która po kolei zapobiega, aby procesor nie przeszedł stan uśpienia. Jądro oferuje eksperymentalną opcję do uśpienia urządzeń podłączonych do USB, poprzez wywołania sterowników z plików power/state znajdujących się w /sys.

Device Drivers
 USB support
   [*]   Support for Host-side USB
   [*]   USB suspend/resume (EXPERIMENTAL)

7.  Stany uśpienia: uśpienie, oczekiwanie, suspend to disk

ACPI definiuje różne stany uśpienia. Najważniejszymi są

• S1 alias Oczekiwanie,
• S3 alias Zawieszenie do RAM-u alias Uśpienie,
• S4 alias Zawieszenie na dysk twardy (ang. Suspend-to-Disk) alias Hibernacja.

Mogą one być wezwane kiedykolwiek system jest bezczynny, ale zamknięcie systemu nie jest wskazane z powodu długiego czasu ładowania systemu.

Uśpienie (S3)

Wsparcie ACPI dla tych stanów uśpienia jest oznaczone jako eksperymentalne z prostego powodu. Stany uśpienia APM są bardziej stabilne, jednakże nie możemy używać APM i ACPI jednocześnie.

  Power Management Options --->
    [*]  Power Management support
      ACPI (Advanced Configuration and Power Interface) Support --->
       [*]  ACPI Support
         [*]   Sleep States

Gdy nasz kernel jest poprawnie skonfigurowany, możemy użyć hibernate-script aby aktywować hibernację lub tryb uśpienia. Najpierw jednak musimy go zainstalować

# emerge hibernate-script

Musimy jeszcze skonfigurować kilka plików w katalogu /etc/hibernate. Domyślnie pakiet wstawia tam kilka plików odpowiednio dla każdego stanu uśpienia. Opcje, które są popularne dla wszystkich metod wstrzymania zostały umieszczone w common.conf; upewnijcie się, że plik ten jest właściwie ustawiony dla waszego systemu.

Do skonfigurowania uśpienia, edytujemy sysfs-ram.conf w katalogu /etc/hibernate. UseSysfsPowerState mem jest już dobrze ustawiona, ale jeżeli chcecie dokonac dalszych zmian do tego konkretnego stanu uśpienia (lub jakiegokolwiek innego) powinien on zostać dodany do /etc/hibernate/hibernate.conf. W tej drodze poprowadzą nas komentarze oraz nazwy odpowiednich opcji. Jeżeli ponadto używamy nfs lub samby do dzielenia się plikami w sieci, powinniśmy się upewnić aby wyłączyć niepotrzebne skrypty uruchomieniowe, aby uniknąć opóźnień.

Gotowi? Teraz mamy ostatnią szansę zrobić kopię bezpieczeństwa danych, które chcemy trzymać po wykonaniu następnej komendy. W celu późniejszego "wybudzenia" należy wcisnąć jakiś specjalny klawisz (np. Fn).

# hibernate-ram

Jeżeli dalej czytamy ten tekst, wygląda na to, że uśpienie działa poprawnie. Możemy również ustawić oczekiwanie (S1) w podobny sposób, edytując sysfs-ram.conf oraz zmieniając "UseSysfsPowerState mem" na "UseSysfsPowerState standby". S3 oraz S4 są bardziej interesującymi stanami uśpienia prowadzącymi jednakże do większego oszczędzania energii.

Hibernate (S4)

Ten rozdział pokaże nam czym jest hibernacja, czyli obraz działającego systemu skopiowany na dysk przez wyłączeniem. Podczas wznawiania, obraz jest ładowany i możemy zacząć działać dokładnie od tego samego punktu, w którym poprzednio wywołaliśmy hibernację.

Obecnie istnieją dwie różne implementacje dla S4. Oryginalnym jest swsusp, potem nowszy tuxonice (dawny suspend2), który ma najładniejszy interfejs (zwierając wsparcie dla fbsplasha). Porównanie udogodnień jest dostępne na stronie domowej projektu suspend2. Dodatkowo istniało również zawieszenie na dysk (Suspend-to-Disk, pmdisk) - rozwidlenie swsusp, ale jego rozwój został wstrzymany.

TuxOnIce nie jest jeszcze oficjalnie włączone do głównych źródeł jądra, trzeba nałożyć na nie odpowiednie łatki, które możemy znaleźć na tuxonice.net lub użyć sys-kernel/tuxonice-sources

Jądro dla swsusp i tuxonice należy ustawić następująco:

Power Management Options --->

  (hibernacja z swsusp)
  [*] Software Suspend
    (należy zamienić /dev/SWAP z odpowiednią partycją swap)
    (/dev/SWAP)  Default resume partition

  (hibernacja z TuxOnIce)
  Enhanced Hibernation (TuxOnIce)
    --- Image Storage (you need at least one writer)
    [*]    File Writer
    [*]    Swap Writer
    --- General Options
    [*]    LZF image compression
    (należy zamienić /dev/SWAP z odpowiednią partycją swap)
    (/dev/SWAP)    Domyślna nazwa urządzenia wznowienia
    [ ]    Allow Keep Image Mode

Konfiguracja swsusp jest raczej prosta. Jeżeli nie ustawiliśmy lokalizacji partycji swap w konfiguracji jądra, możemy ją dodać jako parametr jądra podczas uruchomienia (resume=/dev/SWAP). Jeżeli uruchomienie nie jest możliwe, ponieważ obraz jest zepsuty, należy użyć parametru noresume. Skrypt uruchomieniowy hibernate-cleanup unieważnia obrazy swsusp podczas uruchamiania.

# rc-update add hibernate-cleanup boot

Aby uaktywnić hibernację z swsusp, trzeba użyć skryptu hibernate oraz ustawić UseSysfsPowerState disk w /etc/hibernate/sysfs-disk

Jeśli wyświetli nam się komunikat o spanikowaniu jądra z powodu uhci lub czegoś podobnego, wtedy należy skompilować wsparcie dla USB jako moduł i usunąć go z pamięci przed uśpieniem laptopa. Opcje konfiguracyjne możemy znaleźć w common.conf

# nano -w /etc/hibernate/common.conf
(Ostatnia szansa na zrobienie kopii zapasowej)
# hibernate

Poniższy nagłówek opisuje ustawienie TuxOnIce włączając w to wsparcie dla fbsplash, dla ładnego, graficznego pasku postępu hibernacji i wznawiania.

Pierwsza część konfiguracji jest podobna do konfiguracji swsusp. Podobnie jak tam, jeżeli nie podamy lokacji partycji swap w konfiguracji jądra, możemy ją dodać jako parametr jądra (resume2=swap:/dev/SWAP). Jeżeli z powodu uszkodzonego obrazu nie możemy załadować systemu należy dodać parametr noresume. Dodatkowo skrypt hibernate-cleanup unieważnia obrazy TuxOnIce podczas uruchamiania.

# rc-update add hiberante-cleanup boot

Teraz należy odpowiednio wyedytować /etc/hiberante/suspend2.conf, uaktywniając opcje TuxOnIce, które są nam potrzebne. Na razie jednak nie uaktualniajmy części o fbsplash w common.conf.

# nano -w /etc/hibernate/suspend2.conf
(Ostatnia szansa na zrobienie kopii zapasowej danych)
# hibernate

Należy skonfigurować fbsplash teraz, jeżeli jeszcze tego nie zrobiliśmy. Aby uaktywnić wsparcie dla fbsplash podczas hibernacji, potrzebujemy pakietu sys-apps/tuxonice-userui. Dodatkowo, musimy odblokować flagę USE fbsplash.

# echo sys-apps/tuxonice-userui fbsplash >> /etc/portage/package.use
(Pakiet może być oznaczy jako niestabilny, więc najpierw trzeba będzie
go odmaskować)
# echo "sys-apps/tuxonice-userui" >> /etc/portage/package.keywords
# emerge tuxonice-userui

Po instalacji dostajemy informację o konieczności zrobienia dowiązania symbolicznego to motywu, którego chcemy użyć. Np, aby użyć motywu livecd-2005.1, powinniśmy wykonać poniższe komendy:

# ln -sfn /etc/splash/livecd-2005-1 /etc/splash/suspend2

Jeżeli chcemy czarnego ekranu w pierwszej części procesu wznawiania, powinniśmy dodać narzędzie tuxoniceui_fbsplash do naszego obrazu initrd. Zakładając, że stworzyliśmy obraz wykorzystując splash_geninitramfs i zapisaliśmy jako /boot/fbsplash-emergence-1024x768, znajdziemy poniżej informacje jak tego dokonać.

#  mount /boot
#  mkdir ~/initrd.d
#  cp /boot/fbsplash-emergence-1024x768 ~/initrd.d/
#  cd ~/initrd.d
#  gunzip -c fbsplash-emergence-1024x768 | cpio -idm --quiet -H newc
#  rm fbsplash-emergence-1024x768
#  cp /usr/sbin/tuxoniceui_fbsplash sbin/
#  find . | cpio --quiet --dereference -o -H newc | gzip -9 > /boot/fbsplash-tuxonice-emergence-1024x768

Pozostaje nam jeszcze tylko przekonfigurowanie grub.conf (lub lilo.conf) aby nasz kernel używał /boot/fbsplash-tuxonice-emergence-1024x768 jako obrazu initrd. Teraz możemy na sucho przetestować czy wszystko zostało ustawione poprawnie

# tuxoniceui_fbsplash -t

Jeżeli wszystko działa dobrze, możemy ponownie otworzyć /etc/hibernate/common.conf i uaktywnić wszystkie opcje związane z fbsplash. Po tym możemy już uruchomić hibernate i podziwiać hibernacje z użyciem fbsplash

8.  Rozwiązywanie problemów

P:Próbując zmienić częstotliwość CPU, wyświetlany jest komunikat, że /sys/devices/system/cpu/cpu0/cpufreq/scaling_regulator nie istnieje.

O: Należy się upewnić, że nasz procesor wspiera skalowanie częstotliwości oraz, że wybraliśmy odpowiedni sterownik CPUFreq dla naszego procesora. Poniżej znajduje się lista procesorów wspieranych przez CPUFreq (jądro 2.6.7): ARM Integrator, ARM-SA1100, ARM-SA1110, AMD Elan - SC400, SC410, AMD mobile K6-2+, AMD mobile K6-3+, AMD mobile Duron, AMD mobile Athlon, AMD Opteron, AMD Athlon 64, Cyrix Media GXm, Intel mobile PIII i Intel mobile PIII-M na pewnych chipsetach, Intel Pentium 4, Intel Xeon, Intel Pentium M (Centrino), National Semiconductors Geode GX, Transmeta Crusoe, VIA Cyrix 3 / C3, UltraSPARC-III, SuperH SH-3, SH-4, kilka "PowerBook" i "iBook2" oraz różne procesory zgodne z systemami ACPI 2.0 (tylko jeśli "ACPI Processor Performance States" są dostępne w interfejsie ACPI/BIOS).

P: Laptop wspiera skalowanie częstotliwości, ale /sys/devices/system/cpu/cpu0/cpufreq/ jest pusty.

O: Należy poszukać komunikatów o błędach ACPI za pomocą dmesg | grep ACPI. Należy uaktualnić BIOS, szczególnie jeśli jest raportowany zepsuty DSDT. Możemy również naprawić to samemu (co wykracza poza ten przewodnik).

P: Laptop wspiera skalowanie częstotliwości, ale według /proc/cpuinfo prędkość nigdy się nie zmienia.

O: Prawdopodobnie włączyliśmy wsparcie dla symmetric multiprocessing support (CONFIG_SMP) w jądrze. Należy to wyłączyć i wszystko powinno działać. Niektóre starsze jądra posiadały powodujący to błąd. W takim przypadku wykonujemy emerge x86info, aktualizujemy jądro gdy zostaniemy o to zapytani i sprawdzamy częstotliwość za pomocą x86info -mhz.

P: Częstotliwość CPU może być zmieniana, ale jej zakres nie jest tak szeroki jak w innym systemie operacyjnym.

O: Możemy połączyć skalowanie częstotliwości z przepustnicą ACPI, aby otrzymać niższą minimalną częstotliwość. Zauważmy, że przepustnica nie zachowuje wiele energii i głównie jest używana do zarządzania temperaturą (utrzymując laptop cichym i chłodnym). Możemy uzyskać obecny stan przepustnicy za pomocą cat /proc/acpi/processor/CPU/throttling i zmienić go wykonując echo -n "0:x" > /proc/acpi/processor/CPU/limit, gdzie x jest jednym ze stanów Tx wyszczególnionych w /proc/acpi/processor/CPU/throttling.

P: Konfigurując jądro regulatory powersave, performance i userspace pojawiają się, ale brakuje ondemand. Gdzie go można znaleźć?

O: Regulator ondemand jest tylko dołączony do ostatnich źródeł jąder. Należy uaktualnić jądro.

P: Żywotność baterii się pogorszyła.

O: Sprawdzamy ustawienia w BIOS-ie. Może zapomnieliśmy, ponownie włączyć niektóre opcje.

P: Bateria jest w pełni naładowana, ale KDE wyświetla, że pozostało 0% i natychmiastowo zamyka system.

O: Sprawdzamy wsparcie baterii wkompilowane w jądro. Jeśli używamy go jako modułu, należy się upewnić, że jest on załadowany.

P: Program logujący pokazuje komunikaty tj. "logger: ACPI group batter / action battery is not defined".

O: Ten komunikat jest generowany przez skrypt /etc/acpi/default.sh, który jest dostarczany z acpid. Możemy bez żadnych konsekwencji je zignorować. Jeżeli jednak chcemy się ich pozbyć, możemy to zrobić poprzez zakomentowanie odpowiedniej linii w pliku /etc/acpi/default.sh:

   *)  # logger "ACPI action $action is not defined"

P: Posiadacze laptopów Dell Inspiron 51XX. Nie występują zdarzenia ACPI.

O: Wygląda na błąd w jądrze. Przeczytajmy o tym tutaj.

P: Uaktywniłem opcję DynamicClocks w xorg.conf i teraz X.org pada / Ekran jest cały czarny / mój laptop nie wyłącza się poprawnie.

O: Dzieje się tak na niektórych systemach. Rozwiązaniem jest wyłączenie DynamicClocks.

P: Chcę użyć TuxOnIce, ale dostaję komunikat, że moja partycja swap jest za mała. Rozszerzenie nie wchodzi w grę.

O: Jeżeli mamy wystarczająco dużo wolnego miejsca na dysku, możemy użyć zapisu do pliku, zamiast do partycji swap. hibernate-script radzi sobie z tym całkiem dobrze. Więcej informacji na ten temat możemy znaleźć w /usr/src/linux/Documentation/power/tuxonice.txt.

P: Nowo zakupiona bateria starcza ledwo na kilka minut! Co jest nie tak?

O: Najpierw należy podążyć za wskazówkami producenta o tym jak poprawnie naładować baterię.

P: Powyższe nie pomogło. Co wtedy?

O: Niektóre baterie sprzedawane jako "nowe" są w rzeczywistości stare. Proszę spróbować:

$ grep capacity /proc/acpi/battery/BAT0/info
design capacity:     47520 mWh
last full capacity:  41830 mWh

Jeśli "last full capacity" różni się znacznie od "design capacity", wtedy bateria prawdopodobnie jest zepsuta. Proszę spróbować wymiany gwarancyjnej.

P: Naszego problemu nie ma powyżej. Co dalej?

O: Po pierwsze nie bać się kontaktu ze mną, Dennis Nienhüser. Fora Gentoo są również bardzo dobrym miejscem na uzyskanie pomocy. Jeżeli wolimy kontaktować się przez IRC, pomoc możemy uzyskać na kanale #gentoo-laptop.

Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike.