Il pacchetto powersave è stato pensato appositamente per le applicazioni che girano sui portatili, essendo preposto al risparmio energetico quando è la batteria ad alimentare il sistema. Alcune funzionalità sono comunque anche di interesse per normali postazioni di lavoro e server (ad es:suspend/standby, funzionalità bottone ACPI e disattivazione di dischi IDE).
Questo pacchetto include tutte le funzionalità di power management del vostro sistema. Esso supporta hardware che utilizza ACPI, APM, dischi IDE e tecnologia PowerNow! o SpeedStep. Le funzionalità dei pacchetti acpid, ospmd e cpufreqd (adesso cpuspeed) vengono riunite nel pacchetto powersave. Per tale ragione non si dovrebbe lavorare parallelamente con demoni presi da questi pacchetti e il demone di powersave.
Anche se il vostro sistema non dispone di tutti gli elementi di hardware summenzionati (APM e ACPI si escludono a vicenda), vale la pena utilizzare il demone di powersave per regolare il risparmio eneregetico. Eventuali modifiche della configurazione dell'hardware vengono rilevate automaticamente dal demone.
![]() | Su powersave |
|---|---|
Oltre al presente capitolo sono reperibili ulteriori informazioni sul pacchetto powersave anche sotto /usr/share/doc/packages/powersave/README_POWERSAVE . | |
powersave si configura tramite diversi file:
Questo file serve al demone di powersave. Tra l'altro sussiste la possibilità di aumentare la quantità dei messaggi di debug (in /var/log/messages) tramite il valore assegnato alla variabile POWERSAVE_DEBUG .
Questo file è richiesto dal deamon di powersave per garantire la elaborazione degli eventi di sistema che si verificano (ingl. events). Ad un evento possono essere assegnati azioni esterne o azioni che elabora il daemon. Si parla di azione esterna quando il daemon tenta di invocare un file eseguibile che risiede sotto /usr/lib/powersave/scripts/. Azioni interne predefinite sono:
ignore
throttle
dethrottle
suspend_to_disk
suspend_to_ram
standby
do_suspend_to_disk
do_suspend_to_ram
do_standby
throttle riduce l'attività del processore nella misura stabilita tramite POWERSAVE_MAX_THROTTLING. Questo valore dipende dallo schema utilizzato al momento. dethrottle riporta il processore a pieno regime. suspend_to_disk, suspend_to_ram e standby innescano la modalità di sospensione. Si consiglia di assegnare questi stati del sistema a determinati eventi del sistema.
Gli script per l'elaborazione degli eventi di sistema sono raccolti nella directory /usr/lib/powersave/scripts:
notifica tramite console, X window o segnale acustico riferito ad un evento verificatosi
abilitazione del salvaschermo
di aiuto se in seguito ad un suspend/standby la schermata risultasse discostata
salvare le impostazioni ed eseguire il logout da GNOME, KDE o da un altro window manager
salvare le impostazioni di GNOME o KDE ed eseguire lo shutdown (spegnimento) del sistema
Se ad esempio impostate la variabile POWERSAVE_EVENT_GLOBAL_SUSPEND2DISK="prepare_suspend_to_disk do_suspend_to_disk", non appena l'utente dà il comando a powersaved di entrare nello stato di sospensione Suspend to disk vengono eseguite le due azione o script nella sequenza indicata. Il daemon invoca lo script esterno /usr/lib/powersave/scripts/prepare_suspend_to_disk. Una volta eseguito ciò correttamente, il deamon esegue l'azione interna do_suspend_to_disk e, dopo che lo script abbia scaricato i relativi moduli e fermato i relativi servizi, il sistema passa nel modo di sospensione.
Una modifica apportata all'evento di un tasto Sleep potrebbe assumere il seguente aspetto: POWERSAVE_EVENT_BUTTON_SLEEP="notify suspend_to_disk". In questo caso l'utente viene informato dallo script esterno notify sull' evento di sospensione. In seguito viene generato l'evento POWERSAVE_EVENT_GLOBAL_SUSPEND2DISK a cui seguono le azioni descritte sopra che garantiscono di passare in tutta sicurezza nel modo di sospensione.
Lo script notify si lascia modificare tramite la variabile POWERSAVE_NOTIFY_METHOD che trovate in /etc/sysconfig/powersave/common.
Il file contiene delle variabili per l'ottimizzazione delle impostazioni relative alla frequenza dinamica della CPU.
Contiene i limiti della batteria e altre impostazioni specifiche della batteria.
In questo file stabilite i moduli da scaricare e i servizi da fermare prima di entrare nel modo per così dire di dormiveglia, i quali saranno in seguito ricaricati e riavviati. Inoltre potete ritardare l'attivazione di questa modalità (per poter eventualmente salvare ancora dei file.)
Qui impostate gli aspetti concernenti il raffreddamento e la regolazione termica. Per maggiori dettagli rimandiamo al file /usr/share/doc/packages/powersave/README.thermal.
Si tratta dei diversi schemi, detti anche profili, che regolano il consumo energetico in base a determinati scenari di applicazione. Alcuni sono già preconfigurati e possono essere subito utilizzati senza che vi sia la necessità di apportare delle modifiche. Comunque sussiste inoltre la possibilità di archiviarvi anche propri profili.
I modi di attività ridotta sono disabilitati di default, visto che su alcuni sistemi non producono gli effetti desiderati. In linea di massima vi sono tra modi di dormiveglia ACPI e due di APM:
Salva l'intero contenuto della memoria sul disco rigido. Il sistema si spegne completamente e non consuma alcuna energia.
Salva gli stati dei dispositivi nella RAM, solamente la RAM viene alimentata con energia.
Spegne a secondo del modello dei dispositivi.
Nel file /etc/sysconfig/powersave/sleep potete abilitare questi modi e stabilire quali moduli critici e servizi sono da scaricare o fermare prima che vi sia un evento di sospensione o di stand-by. Se dopo un po'riaccendete il sistema i moduli e servizi in questione verranno rispettivamente caricati e avviati nuovamente. Le impostazioni di default si riferiscono in primo luogo ai moduli USB e PCMCIA. Se il sistema non entra correttamente nel modo suspend o standby, spesso la causa è dovuta a determinati moduli. Nella sezione Section 16.5.4, “Troubleshooting” trovate delle ulteriori indicazioni per circoscrivere la causa dell'errore.
Assicurate che siano settate le seguenti opzioni standard per la corretta interpretazione di eventi suspend/standby e resume nel file /etc/sysconfig/powersave/events (cosa che si ha di solito ad installazione avvenuta di ):
POWERSAVE_EVENT_GLOBAL_SUSPEND2DISK=
"prepare_suspend_to_disk do_suspend_to_disk"
POWERSAVE_EVENT_GLOBAL_SUSPEND2RAM=
"prepare_suspend_to_ram do_suspend_to_ram"
POWERSAVE_EVENT_GLOBAL_STANDBY=
"prepare_standby do_standby"
POWERSAVE_EVENT_GLOBAL_RESUME_SUSPEND2DISK=
"restore_after_suspend_to_disk"
POWERSAVE_EVENT_GLOBAL_RESUME_SUSPEND2RAM=
"restore_after_suspend_to_ram"
POWERSAVE_EVENT_GLOBAL_RESUME_STANDBY=
"restore_after_standby"
Nel file /etc/sysconfig/powersave/battery potete stabilire tre stati di caricamento della batteria (espressi in punti percentuali) raggiunti i quali il sistema emette degli avvertimenti e esegue determinate azioni.
POWERSAVED_BATTERY_WARNING=20 POWERSAVED_BATTERY_LOW=10 POWERSAVED_BATTERY_CRITICAL=5
Le azioni/gli script che verranno eseguiti non appena si scende sotto la soglia dei valori impostati vengono impostate nel file di configurazione /etc/sysconfig/powersave/events. Inoltre potete modificare le azioni standard dei button come descritto nella sezione Section 16.5.1, “Configurazione del pacchetto powersave”.
POWERSAVE_EVENT_BATTERY_NORMAL="ignore" POWERSAVE_EVENT_BATTERY_WARNING="notify" POWERSAVE_EVENT_BATTERY_LOW="notify" POWERSAVE_EVENT_BATTERY_CRITICAL="wm_shutdown"
Potete correlare il comportamento del sistema al tipo dell'alimentazione energetica. Il consumo energetico del sistema dovrebbe ridurrsi quando il sistema funziona a batteria. Ed inversamente la performance del sistema dovrebbe incrementare non appena il sistema è connesso nuovamente alla rete elettrica. In concreto potete influire sulla frequenza della CPU, sulla funzione di risparmio energetico dei dischi IDE e su una serie di parametri.
In /etc/sysconfig/powersave/events stabilite l'esecuzione di determinate azioni alla connessione o disconnessione del sistema dalla rete elettrica. In /etc/sysconfig/powersave/common selezionate i scenari (detti schemes):
POWERSAVE_AC_SCHEME="performance" POWERSAVE_BATTERY_SCHEME="powersave"
Gli schemes vengono archiviati nei file sotto /etc/sysconfig/powersave. Il loro nome si compone di: nome_scheme dello schema. Nell'esempio ne riportiamo due: scheme_performance e scheme_powersave. Preconfigurati sono performance, powersave e presentation e acoustic. Tramite il modulo per il power management (si veda la sezione Section 16.6, “Il modulo per il power management di YaST”) potete elaborare in qualsiasi momento schemi esistenti crearne di nuovi, cancellare quelli esistenti o modificare la correlazione allo stato di alimentazione energetica del sistema.
Se utilizzate ACPI potete determinare la reazione del vostro sistema tramite i cosiddetti “tasti ACPI” (Power, Sleep e “Schermo alzato”, “Schermo abbassato”). In /etc/sysconfig/powersave/events stabilite l'esecuzione di determinate azioni. Per maggiori dettagli per quel che riguarda le opzioni consulate il file di configurazione.
Se premete il tasto Power il sistema esegue lo shutdown del relativo window manager (KDE, GNOME, fvwm...).
Se premete il tasto Sleep il sistema entra nel modo suspend to disk.
Se alzate lo schermo non succede niente.
Se abbassate lo schermo si attiva il salvaschermo.
Se il processore per un determinato lasso di tempo non raggiunge un determinato livello di attività, potete ridurre ulteriormente il livello di attività del processore. Impostate a riguardo tramite POWERSAVED_CPU_LOW_LIMIT e POWERSAVED_CPU_IDLE_TIMEOUT rispettivamente il livello minimo e l'intervallo di tempo una volta raggiunti o superati i quali ridurre il livello di attività della CPU.
Date una occhiata a /var/log/messages dove vengono protocolli i messaggi di errore e di allerta. Se scorrendo il file non si individua la causa del problema, istruite powersave nel file /etc/sysconfig/powersave/common tramite la variabile DEBUG di emettere dei messaggi più dettagliati. Impostate il valore della variabile su 7 o addirittura su 15 e riavviate il demone. Con messaggi più dettagliati in /var/log/messages alla mano dovrebbe essere ora possibile circoscrivere il problema. Tratteremo di seguito le difficoltà maggiormente riscontrate con powersave.
In caso di difficoltà dovute ad ACPI, analizzate da vicino l'output del comando dmesg, con particolare attenzione ai messaggi che riguardano ACPI, il comando è dmesg|grep -i acpi.
A volte è necessario eseguire un aggiornamento del BIOS per risolvere la causa del problema. Visitate dunque il sito del produttore del portatile, e scaricate ed installate una versione aggiornata del BIOS. Comunicate al produttore del vostro sistema di attenersi all'attuale specificazione dell' ACPI.
Se gli errori persistono anche dopo l'aggiornamento del BIOS, cercate una DSDT aggiornata per il vostro sistema da sostituire alla vecchia tabella DSDT contenente degli errori del vostro BIOS:
Scaricate la DSDT adatta al vostro sistema da http://acpi.sourceforge.net/dsdt/tables . Assicuratevi che il file sia scompattato e compilato (riconoscibile dalla estensione di file .aml (ACPI Machine Language)). In questo caso passate al punto 3.
Se la tabella scaricata ha l'estensione di file .asl (ACPI Source Language), dovrete compilarla tramite iasl dal pacchetto pmtools. Invocate iasl -sa <file>.asl. L'ultima versione di iasl (Intel ACPI Compiler) è inoltre reperibile al seguente indirizzo http://developer.intel.com/technology/iapc/acpi/downloads.htm.
Copiate il file DSDT.aml dove preferite (noi consigliamo /etc/DSDT.aml). Editate /etc/sysconfig/kernel ed adattate di conseguenza il percorso del vostro file DSDT. Lanciate mkinitrd (Pacchetto mkinitrd). Ogni volta che disinstallate il kernel e utilizzate mkinitrd per creare un initrd verrà integrato il DSDT adatto e caricato al boot.
Sorgenti del kernel alla mano (kernel-source) controllate se il vostro processore viene supportato oppure se dovete utilizzare eventualmente un determinato modulo del kernel o una determinata opzione del modulo per attivare la CPU frequency. I dettagli sono reperibili sotto /usr/src/linux/Documentation/cpu-freq/*. Se è richiesto un determinato modulo o una determinata opzione, configurate ciò nel file /etc/sysconfig/powersave/cpufre tramite le variabili CPUFREQD_MODULE e CPUFREQD_MODULE_OPTS.
Ecco le possibili cause da ricondursi al kernel che ostacolano su sistemi ACPI il modo suspend/standby:
Sistemi con oltre 1 GB di RAM al momento non supportano (ancora) il modo suspend
Sistemi multi-processori o sistemi con un processore P4 (con hyper threading) attualmente non supportano il modo suspend.
L'errore può essere anche dovuto ad una implementazione errata della vostra DSDT (BIOS). In questo caso installare una nuova DSDT.
Per sistemi ACPI e APM vale:
Non appena il sistema tenta di scaricare un modulo corrotto, il sistema si blocca e l'evento suspend non viene innescato. Allo stesso risultato si arriva anche nel caso inverso ovvero l'evento suspend non viene innescato perché non vengono scaricati o fermati dei moduli o servizi. In entrambi i casi dovreste provare a individuare i moduli che causano il problema. Di aiuto sono i file di log creati dal daemon di powersave sotto /var/log/<modo di dormiveglia>. In caso difficoltà spesso tutto si lascia ricondurre ad un modulo da scaricare prima di entra nel modo di sospensione e standby. Potete intervenire sulle impostazioni sotto /etc/sysconfig/powersave/sleep.
POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND2DISK="" POWERSAVE_UNLOAD_MODULES_BEFORE_SUSPEND2RAM="" POWERSAVE_UNLOAD_MODULES_BEFORE_STANDBY="" POWERSAVE_SUSPEND2DISK_RESTART_SERVICES="" POWERSAVE_SUSPEND2RAM_RESTART_SERVICES="" POWERSAVE_STANDBY_RESTART_SERVICES=""
Se ricorrete al modo di sospensione e standby in diversi ambienti di rete o con file system montati da remoto (ad es. Samba, NIS e altri), si consiglia di utilizzare l'automounter per eseguirne il mount oppure inserite i rispettivi servizi (ad es. smbfs o nfs) nelle variabili menzionate sopra. Se primo di un evento suspend/standby si accede ad un file system montato da remoto tramite un programma, il servizio non si lascia fermare correttamente ed il file system non funziona correttamente. Dopo il ripristino del sistema il file system risulta eventualmente essere corrotto e dovrà essere montato nuovamente.
In ACPI, il sistema operativo può richiedere dal BIOS una comunicazione quando si scende sotto un certo livello di carica della batteria. Il vantaggio di questo metodo consiste nel non dovere costantemente leggere lo stato della batteria cosa che frenerebbe le prestazioni del sistema. Comunque può darsi il caso che contrariamente a quanto comunicato dal BIOS in realtà non viene inviata nessuna comunicazione al sistema operativo anche se si scende sotto il livello minimo indicato.
In questi casi impostate la variabile POWERSAVED_FORCE_BATTERY_POLLING in /etc/sysconfig/powersave/battery su yes per forzare la lettura dello stato della batteria.