Capacità e durata delle batterie dei notebook sono migliorate molto nel corso degli ultimi anni. Tuttavia i moderni processori consumano molta più energia dei vecchi e ad ogni nuova generazione di notebook si aggiungono nuove periferiche "affamate" di energia. Ecco il perchè dell'importanza della gestione energetica. Applicando buone politiche di risparmio energetico non sarà sempre necessario acquistare un'altra batteria.
Questa guida tratta della gestione energetica per i notebook. Alcune sezioni potrebbero essere valide anche per i server, altre non lo sono sicuramente e potrebbero causare problemi. Si consiglia fortemente di non applicare niente di quello contenuto in questa guida a macchine server a meno che non si sappia veramente quello che si sta facendo.
Poichè questa guida diventa sempre più lunga, segue una breve panoramica di ciò che sarà trattato.
La sezione Prerequisiti tratta di alcuni requisiti di base necessari per tutte le sezioni a seguire della guida. Include impostazioni del BIOS e particolari configurazioni nel kernel. I seguenti tre capitoli pongono l'attenzione sui componenti che tipicamente consumano maggiore energia: il processore, il display e l'hard disk. Ognuno di essi pùo essere configurato separatamente. Gestione Energetica della CPU mostra come modificare la frequenza del processore al fine di risparmiare energia senza un eccessivo calo delle prestazioni. Alcuni stratagemmi in Gestione Energetica dell'Hard Disk permettono di alleggerire il carico di lavoro del disco (avendo come effetto anche una riduzione del livello di rumore). Indicazioni anche per le schede Wireless LAN e per le periferiche USB concludono la sezione dei dispositivi in Gestione Energetica delle altre periferiche mentre un altro intero capitolo è dedicato agli (ancora sperimentali) Stati di Sleep. L'ultimo capitolo (ma non come importanza) denominato Risoluzione dei problemi elenca i problemi più comuni in cui è possibile incorrere.
Bilancio Energetico Per Ogni Componente
Figura 1.1: Peso energetico per ogni componente |
![]() |
Quasi tutti i componenti possono funzionare in differenti stati, ovvero off (spento), sleep (a riposo), idle (inattivo), active (attivo), consumando a seconda dei casi diverse quantità di energia. La maggior parte dell'energia viene consumata dal display LCD, dalla CPU e dagli hard disk. Spesso alcuni di essi sono in grado di attivare politiche di gestione energetica attraverso il BIOS, ma una configurazione intelligente del proprio sistema operativo adattabile a diverse situazioni può ottenere molto di più.
Prima di trattare i dettagli della gestione energetica per le singole periferiche, vi sono alcuni requisiti. Dopo aver controllato le impostazioni del BIOS, è necessario attivare alcune opzioni del kernel, che in breve sono ACPI, sleep states e CPU frequency scaling. Poichè il risparmio energetico comporta una perdita delle prestazioni o un aumento della latenza, deve essere attivato, naturalmente, solamente in assenza di una connessione a rete elettrica. Da qui la necessità di un nuovo runlevel battery.
Per prima cosa è necessario controllare le impostazioni relative alla Gestione Energetica nel BIOS. Di solito la soluzione migliore è combinare le impostazioni del BIOS alle politiche del sistema operativo, ma per il momento è meglio disabilitare le funzioni del BIOS. In questo modo niente interferisce con le nuove politiche imposte dal sistema operativo. Dopo aver configurato tutto per bene, sarà necessario riabilitare tutte le funzioni del BIOS.
È importante verificare che la flag USE acpi sia attivata in /etc/make.conf. Altre flag USE che potrebbero interessare il proprio sistema sono apm, lm_sensors, nforce2, nvidia, pmu. Per informazioni su queste ultime è possibile consultare i file /usr/portage/profiles/use*.desc. Se, in qualsiasi momento, ci si accorge della mancanza di una qualsiasi di queste flag, è possibile ricompilare i pacchetti interessati con l'opzione --newuse di emerge; maggiori informazioni con man 1 emerge.
Il supporto dell'ACPI (Advanced Configuration and Power Interface) nel kernel è ancora in fase di sviluppo. Pertanto è consigliabile usare sempre il kernel più recente.
In Portage ci sono differenti versioni del kernel. Quelle consigliate sono gentoo-sources e tuxonice-sources. La seconda, in particolare, contiene le patch per TuxOnIce; vedere la sezione sugli stati di sleep per maggiori dettagli. Nelle opzioni di configurazione del kernel vanno, in ogni caso, attivate le opzioni seguenti:
Codice 2.1: Configurazione minimale del kernel per la Gestione Energetica (Kernel 2.6) |
Power Management and ACPI options --->
[*] Power Management support
[ ] Software Suspend
ACPI( Advanced Configuration and Power Interface ) Support --->
[ ] Deprecated /proc/acpi/ files
[*] AC 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)
<*> 'performancÈ governor
<*> 'powersavÈ governor
<*> 'ondemand' cpufreq policy governor
<*> 'conservativÈ cpufreq governor
<*> CPU frequency table helpers
<M> ACPI Processor P-States driver
<*> driver CPUFreq a seconda del processore
|
È possibile attivare, a propria discrezione, Software Suspend e Sleep States. I possessori di notebook ASUS, Medion, Thinkpad IBM o Toshiba devono attivare i relativi moduli specifici.
Il kernel deve essere in grado di attivare il CPU frequency scaling (cambio di frequenza della CPU) sul processore. Poichè ogni CPU presenta un'interfaccia differente dalle altre, è necessario scegliere il driver giusto per il proprio processore. Prestare attenzione a queesto passaggio perchè, ad esempio, attivando Intel Pentium 4 clock modulation su un Pentium M si otterrà molto probabilmente un sistema poco stabile. La documentazione del kernel può chiarire qualsiasi dubbio in proposito.
Dopo la compilazione del kernel bisogna assicurarsi del corretto caricamento dei moduli all'avvio e riavviare il notebook con il nuovo kernel con ACPI abilitato. Successivamente eseguire emerge sys-power/acpid per installare il demone acpi. Il suddetto demone gestisce eventi quali il passaggio da corrente a batteria o la chiusura del lid. È necessario assicurarsi che i moduli siano caricati se non compilati direttamente all'interno del proprio kernel. A questo punto avviare il demone acpid con /etc/init.d/acpid start ed eseguire rc-update add acpid default per caricarlo all'avvio. Il suo utilizzo verrà spiegato in seguito.
Codice 2.2: Installazione di acpid |
# emerge sys-power/acpid # /etc/init.d/acpid start # rc-update add acpid default |
Creazione Del Runlevel "battery"
La configurazione predefinita attiverà il risparmio energetico solo quando necessario, praticamente quando il notebook funziona con la propria batteria. Per effettuare il passaggio fra stato di corrente e di batteria, sarà necessario creare un runlevel battery in grado di gestire l'avvio e il blocco degli script di risparmio energetico.
Nota: Se l'idea di avere un ulteriore runlevel non convince, è possibile saltare questa sezione. Naturalmente ciò renderà tutto un po' più complicato. La sezione seguente considera l'esistenza di un runlevel battery. |
Codice 2.3: Creazione di un runlevel battery |
# cd /etc/runlevels # cp -a default battery |
Finito. Il nuovo runlevel battery contiene tutto come default, ma non c'è ancora nessun cambio automatico tra i due livelli.
Di solito gli eventi ACPI sono la chiusura del lid, il cambio della sorgente energetica e il bottone di sleep. Il cambio di sorgente energetica è un evento importante e deve necessariamente generare un cambio di runlevel. Di questo si occuperà un piccolo script.
È necessario uno script in grado di cambiare il runlevel fra default e battery a seconda della sorgente energetica utilizzata. Lo script utilizzata il comando on_ac_power fornito da sys-power/powermgmt-base: assicurarsi dell'installazione di tale pacchetto nel proprio sistema.
Codice 2.4: Installazione di powermgt-base |
# emerge powermgmt-base
|
Ora, tramite il comando on_ac_power && echo AC available || echo Running on batteries eseguito in shell è possibile determinare la sorgente energetica in uso. Lo script seguente è responsabile del cambio di runlevel. Va salvato come /etc/acpi/actions/pmg_switch_runlevel.sh
Codice 2.5: /etc/acpi/actions/pmg_switch_runlevel.sh |
#!/bin/bash # INIZIO configurazione RUNLEVEL_AC="default" RUNLEVEL_BATTERY="battery" # FINE configurazione if [ ! -d "/etc/runlevels/${RUNLEVEL_AC}" ] then logger "${0}: Runlevel ${RUNLEVEL_AC} does not exist. Aborting." exit 1 fi if [ ! -d "/etc/runlevels/${RUNLEVEL_BATTERY}" ] then logger "${0}: Runlevel ${RUNLEVEL_BATTERY} does not exist. Aborting." exit 1 fi if on_ac_power then if [[ "$(</var/lib/init.d/softlevel)" != "${RUNLEVEL_AC}" ]] then logger "Switching to ${RUNLEVEL_AC} runlevel" /sbin/rc ${RUNLEVEL_AC} fi elif [[ "$(</var/lib/init.d/softlevel)" != "${RUNLEVEL_BATTERY}" ]] then logger "Switching to ${RUNLEVEL_BATTERY} runlevel" /sbin/rc ${RUNLEVEL_BATTERY} fi |
Con il comando chmod +x /etc/acpi/actions/pmg_switch_runlevel.sh si rende lo script eseguibile. Infine è necessario che lo script venga eseguito ad ogni cambio di sorgente energetica dal demone acpid. Bisogna però sapere quali eventi vengono generati al cambio di sorgente energetica. Gli eventi vengono chiamati ac_adapter e battery sulla maggior parte dei notebook, ma si potrebbero avere delle eccezioni.
Codice 2.6: Determinazione degli eventi ACPI al cambio di sorgente energetica |
# tail -f /var/log/messages | grep "received event"
|
Eseguire il comando sopra indicato e staccare il cavo di alimentazione dal proprio notebook.
Codice 2.7: Esempio di output al cambio di sorgente energetica |
[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" |
La parte interessante di questo output è quella che segue received event fra le virgolette. Sarà necessario inserire queste stringhe nello script che segue. In caso il proprio notebook dovesse generare più eventi o sempre lo stesso evento, non c'è da preoccuparsi.
Codice 2.8: /etc/acpi/events/pmg_ac_adapter |
# Sostituire "ac_adapter" indicato di seguito con l'evento generato dal proprio notebook # Ad esempio ac_adapter.* sarà sostituito da ac_adapter AC 00000080 00000000 event=ac_adapter.* action=/etc/acpi/actions/pmg_switch_runlevel.sh %e |
Codice 2.9: /etc/acpi/events/pmg_battery |
# Sostituire "battery" indicato di seguito con l'evento generato dal proprio notebook # Ad esempio battery.* sarà sostituito da battery BAT0 00000080 00000001 event=battery.* action=/etc/acpi/actions/pmg_switch_runlevel.sh %e |
Sarà necessario riavviare il demone acpid per rendere attivi i cambiamenti apportati.
Codice 2.10: Riavvio del demone acpid |
# /etc/init.d/acpid restart
|
Provando ora ad attaccare e staccare l'alimentazione a corrente, nei log di sistema dovrebbero apparire a seconda dei casi i messaggi "Switching to AC mode" o "Switching to battery mode". Se lo script non è in grado di rilevare correttamente la sorgente di energia utilizzata, è possibile consultare la sezione Risoluzione dei problemi.
A causa della natura del meccanismo degli eventi, il notebook, al boot, passa al runlevel default che sia o meno collegato alla rete elettrica. Questo va bene se si è collegati direttamente a rete elettrica, certamente no quando si avvia da batteria. Una soluzione potrebbe essere l'aggiunta di un parametro del tipo softlevel=battery al proprio boot loader, ma ci si potrebbe dimenticare di selezionarlo. Una soluzione migliore è sicuramente quella di generare un finto evento ACPI alla fine del processo di boot e lasciare che lo script pmg_switch_runlevel.sh decida quale runlevel utilizzare. Aprire con il proprio editor il file /etc/conf.d/local.start e aggiungere le linee:
Codice 2.11: Cambio del runlevel al boot del notebook con la modifica di local.start |
# Finto evento acpi per cambiare runlevel se scollegati da rete elettrica
/etc/acpi/actions/pmg_switch_runlevel.sh "battery/battery"
|
Conclusa questa parte preparativa, è ora possibile attivare le politiche di gestione energetica per ogni singolo componente.
3. Gestione Energetica della CPU
I processori per i sistemi mobili possono operare a frequenze differenti. Alcuni di essi permettono il cambio del proprio voltaggio. In molte situazioni, la CPU non lavora a pieno carico e quindi abbassandone la frequenza, si otterrà un notevole risparmio energetico, spesso senza nemmeno un decremento prestazione.
Il CPU frequency scaling introduce alcuni termini tecnici che potrebbero non essere conosciuti. Segue, per questo motivo, una breve introduzione.
Prima di tutto, il kernel deve essere in grado di cambiare la frequenza di funzionamento della CPU. Il CPUfreq processor driver contiene i comandi per effettuare questa operazione su ogni tipo di CPU. Per questo motivo è importante indicare il driver giusto da utilizzare nel proprio kernel (operazione già effettuata precedentemente). Inoltre, il kernel deve anche scegliere la frequenza corretta di funzionamento da utilizzare nelle diverse situazioni. Questa viene fissata in base ad una policy (politica di gestione) che consiste in una CPUfreq policy e in un governor (regolatore). Una CPUfreq policy non è altro che un insieme di due numeri che definiscono un campo all'interno del quale la frequenza può oscillare, ovvero un valore minimo e uno massimo. Il governor, invece, decide quale delle frequenze disponibili fra la minima e la massima utilizzare. Ad esempio, il powersave governor utilizza sempre la frequenza più bassa disponibile, il performance governor, invece, la più alta. L'userspace governor non sceglie nessuna frequenza in particolare ma utilizza quella indicata dall'utente (o da un programma in userspace); il valore della frequenza viene letto da /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed.
Questo può non sembrare un cambiamento dinamico della frequenza e in effetti non lo è. La dinamicità può essere realizzata con diversi approcci. Ad esempio, ondemand governor prende le sue decisioni in base al carico di lavoro della CPU. La stessa cosa viene fatta da utility come cpudyn, cpufreqd, powernowd e molte altre. Gli eventi ACPI possono essere utilizzati per attivare o disattivare i cambi dinamici della frequenza a seconda della sorgente energetica utilizzata.
Diminuendo la velocità e il voltaggio della CPU si hanno due vantaggi: viene consumata meno energia e il notebook non si riscalda eccessivamente. Il grande svantaggio, naturalmente, è una perdita di prestazioni. La diminuzione della velocità del processore resta in ogni caso un buon compromesso fra calo di prestazioni e risparmio energetico.
Nota: Non tutti i notebook supportano il frequency scaling. In caso di dubbi, una lista dei processori supportati si trova nella sezione Risoluzione dei problemi. |
È ora di provare il corretto funzionamento del cambio di frequenza della CPU. Installare un altro strumento: sys-power/cpufrequtils.
Codice 3.1: Controllo della frequenza della CPU |
# emerge cpufrequtils # cpufreq-info |
Ecco un esempio di quello che si ottiene:
Codice 3.2: Output di esempio di cpufreq-info |
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. |
Utilizzare cpufreq-set per assicurarsi che il cambio di frequenza funzioni. Il comando cpufreq-set -g ondemand, ad esempio, attiva il governor ondemand; eseguirlo e verificare il cambiamento con cpufreq-info. Se non funziona come dovrebbe, la sezione Risoluzione dei problemi alla fine di questa guida potrebbe essere d'aiuto.
cpufrequtils può operare in modalità automatica (quando si usa il governor ondemand), si può inoltre passare al governor userspace se si vuole impostare manualmente una specifica velocità. È possibile anche impostare staticamente la propria CPU alla massima o minima velocità usando rispettivamente i governor performance e powersave.
Codice 3.3: Cambiare le velocità della CPU |
(Impostare la frequenza più alta disponibile) # cpufreq-set -g performance (Impostare la frequenza più bassa disponibile) # cpufreq-set -g powersave (Impostare una specifica frequenza) # cpufreq-set -g userspace # cpufreq-set -f 2.00ghz |
Altri strumenti di utilità per gestire la velocità della CPU
Sebbene cpufrequtils possa essere considerato il miglior programma sulla piazza, ci sono alcune altre scelte disponibili in Portage. La tabella seguente fornisce una rapida panoramica su gli strumenti di utilità disponibili per la gestione della velocità della CPU. È suddivisa in tre categorie: kernel per soluzioni che hanno bisogno solo del supporto del kernel, demone per programmi che lavorano in background e GUI per programmi che forniscono una interfaccia grafica per una configurazione più semplice.
| Nome | Categoria | Causa cambio | Governor del kernel | Governor supportati | Note |
| 'ondemand' governor | Kernel | Carico della CPU | N.A. | N.A. | Sceglie la frequenza massima in caso di carico della CPU e frequenze man mano più basse in caso di CPU libera. Configurazione attraverso i file presenti in /sys/devices/system/cpu/cpu0/cpufreq/ondemand/. Richiede ancora strumenti in userspace (programmi, script) in caso di utilizzo del cambio di governor. |
| 'conservative' governor | Kernel | Carico della CPU | N.A. | N.A. | A differenza dell'ondemand governor, il conservative non salta alla massima frequenza quando il carico della CPU cresce, ma aumenta poco alla volta la frequenza. Configurazione attraverso i file presenti in /sys/devices/system/cpu/cpu0/cpufreq/ondemand/. Richiede ancora strumenti in userspace (programmi, script) in caso di utilizzo del cambio di governor. |
| cpudyn | Demone | Carico della CPU | Performance, powersave | Dynamic | Supporta anche lo standby dei dischi: notare, però, che il laptop mode in molti casi funziona decisamente meglio. |
| cpufreqd | Demone | Stato della batteria, Carico della CPU, Temperatura, Programmi in esecuzione e altro | Tutti disponibili | Nessuno | Configurazioni sofisticate (ma anche piuttosto complesse). Estendibile tramite plugin per il monitoraggio sensori (lm_sensors) oppure per schede grafiche NVidia. Cpufreqd supporta SMP e può essere controllato manualmente durante la propria esecuzione. |
| powernowd | Demone | Carico della CPU | Nessuno | Passive, sine, aggressive | Supporta SMP. |
| ncpufreqd | Demone | Temperatura | Nessuno | Powersave, performance | Passa da modalità performance a powersave a seconda della temperatura del sistema. Molto utile su notebook con noti problemi di surriscaldamento. |
| speedfreq | Demone | Carico della CPU | Nessuno | Dynamic, powersave, performance, fixed speed | Semplice da configurare con una interfaccia client/server. Richiede un kernel della serie 2.6. Il suo sviluppo è stato interrotto, non è più funzionante e per questo motivo è stato rimosso da Portage. |
| gtk-cpuspeedy | GUI | Nessuno | Nessuno | Nessuno | Applicazione per Gnome, utility grafica per configurare manualmente la frequenza della CPU. Non offre nessun tipo di automazione. |
| klaptopdaemon | GUI | Stato della batteria | Tutti disponibili | Nessuno | Solamente per KDE, 'ondemand' governor necessario per il cambio dinamico della frequenza. |
L'adattamento della frequenza della CPU al carico di lavoro corrente del notebook può sembrare semplice da attuare ad una prima occhiata, ma in realtà non lo è. Un algoritmo errato può causare cambi continui fra due frequenze o spreco di energia quando la frequenza viene portata inutilmente a valori troppo alti.
Quale scegliere? Se si è indecisi, un'ottima scelta è cpufreqd:
Codice 3.4: Installazione di cpufreqd |
# emerge cpufreqd
|
La configurazione di cpufreqd avviene attraverso il file /etc/cpufreqd.conf. Quella predefinita fornita con cpufreqd sembra leggermente confusionaria. Si raccomanda di sostituirla con quella fornita dall'ex sviluppatore Gentoo, Henrik Brix Andersen (vedere successivamente). È necessaria almeno la versione 2.0.0 di cpufreqd. Le versioni precedenti presentano una sintassi differente per il file di configurazione.
Codice 3.5: /etc/cpufreqd.conf (versione 2.0.0 e superiori) |
[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] |
Ora si può avviare il demone cpufreqd. Aggiungerlo ai runlevel default e battery come mostrato di seguito.
Codice 3.6: Avvio di cpufreqd |
# rc-update add cpufreqd default battery # /etc/init.d/cpufreqd start |
Alcune volte può essere opportuno selezionare un'altra politica di gestione rispetto a quella scelta dal demone, ad esempio quando la batteria è quasi scarica, ma si è certi dell'imminente connessione a rete elettrica. In questo caso è possibile attivare la modalità manuale di cpufreqd con il comando cpufreqd-set manual selezionando una delle proprie politiche configurate (elencate tramite cpufreqd-get). Si può abbandonare la modalità manuale con il comando cpufreqd-set dynamic.
Avvertenza: Non eseguire più di uno dei programmi sopra citati contemporaneamente. Potrebbero, infatti, esserci problemi come un cambio continuo fra due frequenze. |
Verifica di funzionamento a seguito delle modifiche apportate
L'ultima cosa da controllare è che le nuove politiche di risparmio energetico facciano bene il loro lavoro. Un modo semplice per verificare ciò è il monitoraggio della velocità della CPU mentre è al lavoro sul notebook:
Codice 3.7: Monitoraggio della velocità della CPU |
# watch grep \"cpu MHz\" /proc/cpuinfo
|
Se /proc/cpuinfo non dovesse venire aggiornato (sezione Risoluzione dei problemi), provare a monitorare la frequenza della CPU con sys-apps/x86info:
Codice 3.8: Monitoraggio alternativo della velocità della CPU |
# watch x86info -mhz
|
A seconda delle impostazioni, la velocità della CPU dovrebbe aumentare in caso di richieste d'uso, diminuire in mancanza di attività o, semplicemente, rimanere costante. Quando si utilizza cpufreqd e la voce verbosity è impostata ad un valore di 5 o più in cpufreqd.conf, nel syslog si otterrano maggiori informarzioni su quello che accade.
4. Gestione Energetica del display LCD
Come si può vedere dalla figura 1.1, il display LCD consuma la maggior parte dell'energia (questo potrebbe non valere nel caso di CPU non mobile). Per questo non solo è importante spegnere il display quando non utilizzato, ma anche ridurre il backlight (retroilluminazione), se possibile. Molti notebook offrono la possibilità di regolare il backlight.
La prima cosa da controllare sono le impostazioni di standby/suspend/off del display. Questi sono tutti valori che dipendono dal windowmanager. L'oscuramento del terminale può essere effettuato con setterm -blank <numero-di-minutiM>, setterm -powersave on e setterm -powerdown <numero-di-minutiM>. Per X.org, si può modificare /etc/X11/xorg.conf come di seguito riportato:
Codice 4.1: Impostazioni dell'LCD suspend in X.org |
Section "ServerFlags" Option "blank time" "5" # Oscura lo schermo dopo cinque minuti (Finto) Option "standby time" "10" # Spegne lo schermo dopo 10 minuti (DPMS) Option "suspend time" "20" # Sospensione completa dopo 20 minuti Option "off time" "30" # Spegnere dopo mezz'ora [...] EndSection [...] Section "Monitor" Identifier [...] Option "DPMS" [...] EndSection |
Backlight (Retroilluminazione)
Probabilmente la gestione del backlight (retroilluminazione) è il punto più importante. Se si è in grado di accedere al controllo tramite uno strumento, bisogna scrivere un piccolo script in grado di impostare il backlight nella modalità batteria e inserirlo nel runlevel battery. Lo script seguente dovrebbe funzionare sulla maggior parte dei notebook IBM Thinkpad e Toshiba. Per gli IBM Thinkpad bisogna attivare le opzioni appropriate nel kernel. Per i notebook Toshiba è sufficiente l'installazione del pacchetto sys-power/acpitool (non sono necessarie le istruzioni seguenti relative a thinkpad_acpi, ex ibm_acpi).
Avvertenza: Il supporto per la regolazione della luminosità è sperimentale nel pacchetto thinkpad_acpi. L'accesso diretto all'hardware di questa utilità potrebbe provocare blocchi inaspettati del sistema. Leggere a tal proposito il sito ufficiale del pacchetto thinkpad_acpi. |
Per essere in grado di regolare il livello di lumonisità, il modulo thinkpad_acpi deve essere caricato con il paramentro sperimentale.
Codice 4.2: Caricamento automatico del modulo thinkpad_acpi |
(Prima di proseguire leggere l'avviso sopra riportato circa l'instabilità di questa opzione) # echo "options thinkpad_acpi experimental=1" >> /etc/modprobe.d/thinkpad_acpi # update-modules # echo thinkpad_acpi >> /etc/modules.autoload.d/kernel-2.6 # modprobe thinkpad_acpi |
Queste operazioni non dovrebbero produrre messaggi di errore e, dopo il caricamento del modulo, dovrebbe essere creato il file /proc/acpi/ibm/brightness. Uno script di avvio avrà il compito di scegliere il miglior livello di luminosità in base alla sorgente energetica disponibile.
Codice 4.3: /etc/conf.d/lcd-brightness |
# Vedere /proc/acpi/ibm/brightness per i valori disponibili # Si legga /usr/src/linux/Documentation/thinkpad-acpi.txt # Livello di luminosità in modalità corrente. Predefinito 7. BRIGHTNESS_AC=7 # Livello di luminosità in modalità batteria. Predefinito 4. BRIGHTNESS_BATTERY=4 |
Codice 4.4: /etc/init.d/lcd-brightness |
#!/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 "Setting LCD brightness"
echo "level ${LEVEL}" > /proc/acpi/ibm/brightness
eend $?
elif [[ -e /usr/bin/acpitool && -n $(acpitool -T | grep "LCD brightness") ]]
then
ebegin "Setting LCD brightness"
acpitool -l $LEVEL >/dev/null || ewarn "Unable to set lcd brightness"
eend $?
else
ewarn "Setting LCD brightness is not supported."
ewarn "For IBM Thinkpads, check that thinkpad_acpi is loaded into the kernel"
ewarn "For Toshiba laptops, you've got to install sys-power/acpitool"
fi
}
start() {
set_brightness
}
stop () {
set_brightness
}
|
Una volta finito, bisogna assicurarsi che la luminosità sia regolata automaticamente aggiungendo lo script al runlevel battery.
Codice 4.5: Regolazione automatica della luminosità |
# chmod +x /etc/init.d/lcd-brightness # rc-update add lcd-brightness battery # rc |
5. Gestione Energetica dell'Hard Disk
Gli Hard Disk consumano meno energia in modalità sleep. Quindi ha senso attivare la modalità risparmio energetico ogni qual volta l'hard disk non viene utilizzato per un certo intervallo di tempo. Ci sono due metodi per questo. Il laptop-mode, il primo, permette un risparmio energetico grazie ad alcune misure che prevengono o al massimo ritardano gli accessi in scrittura. Lo svantaggio è dato dal fatto che uno sbalzo energetico o un crash del kernel potrebbero portare a perdite di dati. Se si vogliono evitare queste situazioni, sarà bene accertarsi che non siano attivi processi che necessitano di scritture frequenti. Il secondo metodo è l'attivazione dell'opzione risparmio energetico del proprio hard disk tramite hdparm.
Aumento del tempo di idle - laptop-mode
Tutti i kernel recenti includono il così detto laptop-mode. Quando attivato, i buffer vengono scritti sul disco alle chiamate read oppure dopo 10 minuti (invece di 30 secondi). Questo fà si che l'hard disk non lavori in maniera continuativa.
Codice 5.1: Avvio automatico del laptop-mode |
# emerge laptop-mode-tools
|
I laptop-mode-tools hanno la propria configurazione in /etc/laptop-mode/laptop-mode.conf. È possibile adattarla alle proprie esigenze; la documentazione è presente nel file di configurazione stesso. Per rendere automatico l'avvio rc-update add laptop_mode battery.
Le ultime versioni (dalla 1.11 in avanti) dei laptop-mode-tools includono lm-profiler. Questo tool effettuerà un monitoraggio dell'utilizzo del disco del proprio sistema e dei servizi di rete in esecuzione consigliando la disabilitazione di quelli non necessari. Sarà possibile disattivarli attraverso il supporto runlevel integrato nei laptop-mode-tools (sostituiti da /sbin/rc di Gentoo) o attraverso i propri runlevel default/battery (raccomandato).
Codice 5.2: Output d'esempio dell'esecuzione di lm-profiler |
# 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
|
A seguito del monitoraggio di dieci minuti, lm-profiler mostrerà un elenco di servizi responsabili di accessi al disco durante il tempo di osservazione.
Codice 5.3: Richiesta di disabilitazione servizi di lm-profiler |
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
|
Per disabilitare atd come suggerito dall'esempio sopra riportato, sarà necessario il comando rc-update del atd battery. Prestare attenzione a non disabilitare servizi essenziali al corretto funzionamento del proprio sistema, in quanto lm-profiler genera facilmente falsi positivi.
Limitazione degli accessi in scrittura
Se non si vuole utilizzare il laptop-mode, sarà necessario prestare maggiore attenzione nel disattivare servizi che accedono frequentemente al disco; syslogd è un buon candidato, ad esempio. Probabilmente non lo si vorrà bloccare completamente, ma una modifica al suo file di configurazione al fine di evitare un logging eccessivo sarà una soluzione migliore. Cups scrive su disco periodicamente, quindi si consideri l'idea di bloccarlo definitivamente così da attivarlo solo quando effettivamente necessario.
Codice 5.4: Disattivazione di cups nella modalità batteria |
# rc-update del cupsd battery
|
È anche possibile utilizzare lm-profiler dei laptop-mode-tools (leggere sopra) per cercare servizi da disabilitare. Una volta eliminati tutti quelli interessati, si può passare alla configurazione di hdparm.
La seconda possibilità è l'utilizzo di hdparm. Se si utilizza il laptop-mode è possibile saltare questa sezione. Altrimenti, sarà necessario modificare il file /etc/conf.d/hdparm per aggiungere i valori seguenti a secondo dei proprio dischi. In questo esempio il disco fisso è associato ad hda:
Codice 5.5: Utilizzo di /etc/conf.d/hdparm per lo standby dell'hard disk |
hda_args="-q -S12" |
Questa stringa attiverà il risparmio energetico per il proprio hard disk. Se in futuro si volesse disattivarlo, basterà modificare ancora una volta il file /etc/conf.d/hdparm cambiando i valori in -q -S0 o, in altro modo, eseguire il comando hdparm -q -S0 /dev/hda.
Per informazioni sulle opzioni, consultare il manuale con man hdparm. Benchè sia sempre possibile avviare hdparm manualmente quando si è collegati a batteria con /etc/init.d/hdparm start, è molto più semplice automatizzarne l'esecuzione e la terminazione. Per fare questo, bisogna aggiungere hdparm al runlevel battery così che attivi automaticamente il risparmio energetico.
Codice 5.6: Configurazione per lo standby automatico del disco |
# rc-update add hdparm battery
|
Importante: Prestare molta attenzione alle impostazioni di sleep e di spin down del proprio hard disk. Impostazioni troppo spinte (valori molto piccoli) possono danneggiare l'hardware e invalidare la garanzia. |
Un'altra possibilità è la disattivazione dello swap nella modalità batteria. Prima di scrivere qualcosa che attivi e disattivi lo swap, bisogna assicurarsi che ci sia abbastanza RAM e che lo swap non sia usato pesantemente, altrimenti si potrebbero avere problemi.
Se non si vuole utilizzare il laptop-mode, è sempre possibile minimizzare gli accessi al disco montando alcune directory come tmpfs, in modo che gli accessi in scrittura non avvengano sul disco ma nella memoria principale, con la conseguenza di perderli con l'operazione di unmount. Spesso è utile montare /tmp allo stesso modo, in quanto il suo contenuto viene in ogni caso perso ad ogni reboot che sia montato o meno sul disco o in RAM. Bisogna solo essere certi di avere RAM a sufficienza e nessun programma (come un client per i download od un programma di compressione) che abbia bisogno di molto spazio in /tmp. Per usare questa soluzione è necessario avere il supporto tmpfs abilitato nel kernel ed aggiungere una linea come la seguente in /etc/fstab:
Codice 5.7: Modifica di /etc/fstab per rendere /tmp volatile |
none /tmp tmpfs size=32m 0 0 |
Avvertenza: Prestare attenzione al parametro size e modificarlo per il proprio sistema. Se non si è sicuri non modificarlo, in quanto si creerebbero facilmente grossi cali di prestazione (effetto collo di bottiglia). Se si volesse montare /var/log nello stesso modo, non bisogna dimenticare di unire i file di log al disco prima di effettuare l'unmounting, poichè sono essenziali. Montare anche /var/tmp allo stesso modo è inutile. Portage usa questa directory per la compilazione... |
6. Gestione Energetica per Altre Periferiche
Se si è in possesso di una scheda grafica ATI con supporto PowerPlay (dynamic clock scaling per le GPU, graphic processing unit), in X.org è possibile abilitare questa caratteristica. Bisogna aprire il file /etc/X11/xorg.conf e aggiungere (oppure attivare) l'opzione DynamicClocks nella sezione Device. Questa opzione attiva su alcuni sistemi può provocare blocchi o crash.
Codice 6.1: Attivazione del supporto PowerPlay per le schede grafiche ATI in X.org |
Section "Device" [...] Option "DynamicClocks" "on" EndSection |
Gestione Energetica del Wireless
Le schede Wireless LAN consumano poca energia. È possibile inserirle nella modalità risparmio energetico nello stesso modo dei propri hard disk.
Nota: Questo script considera la propria interfaccia wireless come wlan0; sostituire questo valore con il nome della propria. |
Per attivare in maniera automatica il risparmio energetico della propria scheda wireless è necessario aggiungere l'opzione seguente al file /etc/conf.d/net:
Codice 6.2: Attivazione automatica del risparmio energetico per le WLAN |
iwconfig_wlan0="power on" |
Per maggiori informazioni e altre opzioni come la configurazione del timeout e del tempo tra i wakeup, è possibile consultare il manuale con man iwconfig. Se i propri driver oppure l'access point supportano il cambio del beacon time, questo può essere un altro modo per risparmiare ancora più energia.
Ci sono due problemi riguardo il consumo di energia delle periferiche USB: primo, periferiche come i mouse USB, le fotocamere digitali o le USB stick consumano energia appena inserite. Non si può ovviare in nessun modo a questo problema (a meno che non vengano rimosse se non necessarie). Secondo, quando ci sono periferiche USB collegate, l'USB host controller accede periodicamente al bus non permettendo alla CPU di passare nella modalità sleep. Il kernel presenta una opzione sperimentale per attivare la sospensione delle periferiche USB tramite le chiamate al driver oppure tramite uno dei file power/state in /sys.
Codice 6.3: Attivazione del supporto USB suspend nel kernel |
Device Drivers
USB support
[*] Support for Host-side USB
[*] USB suspend/resume (EXPERIMENTAL)
|
7. Stati di Sleep: sleep, standby, suspend to disk
L'ACPI definisce differenti stati di sleep. I più importanti sono
Possono essere chiamati quando il sistema non è in uso, ma non si vuole effettuare lo shutdown a causa del lungo tempo di boot.
Il supporto ACPI per questi stati di sleep è considerato sperimentale per delle buone ragioni. Gli stati di sleep APM sembrano essere più stabili, purtroppo non è possibile utilizzare contemporaneamente APM e ACPI.
Codice 7.1: Configurazione del kernel per il supporto agli stati di sleep |
Power Management Options ---> [*] Power Management support [*] Suspend to RAM and standby |
Compilato il kernel con le opzioni sopra considerate, è possibile utilizzare l'hibernate-script per attivare la sospensione o una modalità di sleep.
Codice 7.2: Installazione dell'hibernate-script |
# emerge hibernate-script
|
Sono ora necessarie alcune configurazioni in /etc/hibernate. In modo predefinito, il pacchetto appena installato contiene alcuni file di configurazione per ogni stato di sleep. In common.conf ci sono le opzioni comuni a tutti i metodi di sospensione; assicurarsi che tali opzioni siano corrette per il proprio sistema.
Per configurare lo sleep, bisogna modificare sysfs-ram.conf in /etc/hibernate. UseSysfsPowerState mem è già configurato correttamente ma se più avanti fosse necessario effettuare cambiamenti a questo stato di sleep (o anche a qualsiasi altro stato), tali cambiamenti andrebbero aggiunti al file /etc/hibernate/hibernate.conf. I commenti e i nomi delle opzioni faranno da guida. Se si utilizzano condivisioni nfs o samba, bisognerà assicurarsi di bloccare gli script init appropriati per evitare timeout.
Nota: Per ulteriori informazioni sulla configurazione degli stati di sleep, vedere man hibernate.conf. |
Giunti a questo punto, questa sarà l'ultima occasione per effettuare un backup dei propri dati prima dell'esecuzione del prossimo comando. Probabilmente per tornare indietro dallo stato di sleep, occorrerà premere un tasto speciale come Fn.
Codice 7.3: Chiamata di sleep |
# hibernate-ram
|
Se si sta ancora leggendo questa guida, sarà segno di un corretto funzionamento. Sarà possibile anche configurare lo standby (S1) in maniera simile modificando il file sysfs-ram.conf e cambiando "UseSysfsPowerState mem" in "UseSysfsPowerState standby". S3 e S4 sono gli stati di sleep più importanti poichè permetteno un grande risparmio di energia.
Questa sezione tratta dell'ibernazione; un'immagine del sistema in esecuzione viene scritta sul disco prima dello spegnimento. Alla riaccensione (resume), l'immagine viene caricata ed è possibile riprendere il proprio lavoro dal punto esatto in cui lo si è interrotto prima dell'ibernazione.
Avvertenza: Nessuna periferica hot-plug va cambiata o scambiata in stato di sospensione. Non caricare un'immagine con un kernel differente rispetto a quello con cui la si è creata. Ogni client/server samba o nfs va bloccato prima dell'ibernazione. |
Attualmente ci sono due implementazioni per S4. Quella originale è swsusp, la più recente è invece tuxonice (precedentemente nota come suspend2) dotata di un'interfaccia più piacevole (include il supporto fbsplash). È possibile trovare un'analisi comparativa nell'homepage di tuxonice. Suspend-to-Disk (pmdisk), un fork di swsusp, è stato riunito al progetto originale.
TuxOnIce non è ancora incluso nel kernel ufficiale, per questo motivo sarà necessario applicare una patch, disponibile all'indirizzo tuxonice.net, ai sorgenti del kernel oppure utilizzare sys-kernel/tuxonice-sources.
La sezione del kernel necessaria sia a swsusp che a TuxOnIce è la seguente:
Codice 7.4: Configurazione del kernel per i vari stati di sospensione |
Power Management support ---> (hibernate con swsusp) [*] Hibernation (aka 'suspend to disk') (sostituire /dev/SWAP con la propria partizione di swap) (/dev/SWAP) Default resume partition (hibernate con TuxOnIce) Enhanced Hibernation (TuxOnIce) --- Image Storage (you need at least one writer) [*] File Allocator [*] Swap Allocator --- General Options [*] Compression support [ ] Allow Keep Image Mode [*] Replace swsusp by default |
La configurazione di swsusp è piuttosto semplice. Se non si è indicata la giusta locazione della partizione di swap nella configurazione del kernel, è possibile passarla come parametro con la direttiva resume=/dev/SWAP. Se non è possibile effettuare l'avvio a causa di un'immagine rovinata, si può utilizzare il parametro del kernel noresume. Lo script di avvio hibernate-cleanup invaliderà l'immagine rovinata durante il processo di boot.
Codice 7.5: Invalidamento dell'immagine swsusp durante il processo di avvio |
# rc-update add hibernate-cleanup boot
|
Per attivare l'ibernazione con swsusp, si utilizza lo script hibernate dopo aver impostato UseSysfsPowerState disk in /etc/hibernate/sysfs-disk.
Avvertenza: È consigliabile effettuare un backup dei propri dati. Eseguendo sync prima dell'esecuzione di uno dei comandi, i dati di cache verranno scritti sul disco. Provare il tutto al di fuori dell'ambiente grafico X e, in seguito, con X in esecuzione senza essere loggati al suo interno. |
Se dovesse capitare un kernel panic a causa di uhci o simili, è utile provare a compilare il supporto USB come modulo per poterlo eventualmente "scaricare" prima che il laptop vada nello stato di sleep. Ci sono opzioni di configurazione a proposito in common.conf.
Codice 7.6: Ibernazione con swsusp |
# nano -w /etc/hibernate/common.conf (Assicurarsi di avere un backup dei propri dati) # hibernate |
La sezione seguente tratta della configurazione di TuxOnIce con il supporto fbsplash per avere una "progress bar" (barra di avanzamento) grafica durante la sospensione e il ripristino.
La prima parte della configurazione è simile alla configurazione di swsusp. Se non si è indicata la giusta locazione della partizione di swap nella configurazione del kernel, è possibile passarla come parametro con la direttiva resume=swap:/dev/SWAP. Se non è possibile effettuare l'avvio a causa di un'immagine rovinata basta aggiungere il parametro noresume. Inoltre, lo script di avvio hibernate-cleanup invaliderà l'immagine di TuxOnIce rovinata durante il processo di boot.
Codice 7.7: Invalidamento dell'immagine TuxOnIce durante il processo di avvio |
# rc-update add hibernate-cleanup boot
|
Ora è necessario modificare il file /etc/hibernate/tuxonice.conf, attivando la opzioni TuxOnIce necessarie. Per il momento non attivare le opzioni fbsplash in common.conf.
Codice 7.8: Ibernazione con TuxOnIce |
# nano -w /etc/hibernate/tuxonice.conf (Assicurarsi di avere un backup dei propri dati) # hibernate |
Ora è il momento di configurare fbsplash. Per attivare il supporto fbsplash durante l'ibernazione, è necessario il pacchetto sys-apps/tuxonice-userui con la flag USE fbsplash attivata.
Codice 7.9: Installazione di tuxonice-userui |
# echo sys-apps/tuxonice-userui fbsplash >> /etc/portage/package.use (Dovrebbe essere necessario anche eseguire il comando seguente) # echo "sys-apps/tuxonice-userui" >> /etc/portage/package.keywords # emerge tuxonice-userui |
L'ebuild richiede la creazione di un link simbolico al tema da utilizzare. Ad esempio, per utilizzare il tema livecd-2005.1, sarà necessario il comando:
Codice 7.10: Utilizzo del tema livecd-2005.1 durante l'ibernazione |
# ln -sfn /etc/splash/livecd-2005.1 /etc/splash/tuxonice
|
Se non si vuole uno schermo nero nella prima parte del processo di ripristino, bisognerà aggiungere tuxoniceui_fbsplash alla propria immagine initrd. Se si è creata la propria immagine initrd con splash_geninitramfs e la si è salvata come /boot/fbsplash-emergence-1024x768, i passi da seguire sono i seguenti:
Codice 7.11: Aggiunta di tuxoniceui_fbsplash alla immagine initrd |
# 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 |
In seguito vanno modificati grub.conf (oppure lilo.conf) a seconda del boot manager utilizzato per fare in modo che il proprio kernel TuxOnIce utilizzi /boot/fbsplash-tuxonice-emergence-1024x768 come immagine initrd. Ora è possibile effettuare un test per verificare il corretto funzionamento.
Codice 7.12: Test di ibernazione con fbsplash |
# tuxoniceui_fbsplash -t
|
A questo punto aprire ancora una volta il file /etc/hibernate/common.conf e attivare le opzioni fbsplash. Eseguire hibernate, tutto dovrebbe funzionare in maniera corretta.
D: Sto cercando di cambiare la frequenza della CPU, ma /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor non esiste.
R: Assicurati che il tuo processore supporti il frequency scaling e di aver scelto il driver giusto. Ecco una lista di processori supportati da cpufreq (kernel 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 e Intel mobile PIII-M su alcuni chipset, 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, alcuni "PowerBook" e "iBook2" e vari processori su alcuni sistemi compatibili ACPI 2.0 (solo se gli "ACPI Processor Performance States" sono disponibili attraverso l'interfaccia ACPI/BIOS).
D: Il mio notebook supporta il frequency scaling, ma /sys/devices/system/cpu/cpu0/cpufreq/ è vuoto.
R: Cerca messaggi d'errore relativi all'ACPI con dmesg | grep ACPI. Prova ad aggiornare il BIOS, specialmente se vedi errori riguardo il DSDT. Puoi anche provare a corregge il problema manualmente (ma ciò è al di fuori degli scopi di questa guida).
D: Il mio notebook supporta il frequency scaling, ma secondo /proc/cpuinfo la velocità non cambia mai.
R: Probabilmente hai attivato il supporto al symmetric multiprocessing nel kernel (CONFIG_SMP). Disattivalo e dovrebbe funzionare. Alcune vecchie versioni del kernel presentano un bug al riguardo. In questo caso, esegui emerge x86info, aggiorna il tuo kernel come richiesto e controlla il valore della frequenza con x86info -mhz.
D: Posso cambiare la frequenza della CPU, ma la scelta non è così ampia come quella disponibile in un altro sistema operativo.
R: Puoi combinare il frequency scaling con l'ACPI throttling per ottenere frequenze minori. Ricorda comunque che il throttling non risparmia molta energia e viene usato solo per una gestione termica (mantiene il notebook freddo). Puoi leggere lo stato attuale del throttling con cat /proc/acpi/processor/CPU/throttling e cambiarlo con echo -n "0:x" > /proc/acpi/processor/CPU/limit, dove la x è una degli stati Tx elencati in /proc/acpi/processor/CPU/throttling.
D: Nella configurazione del kernel powersave, performance e userspace governors vengono mostrati, ma non vedo la voce ondemand. Dove la trovo?
R: Ondemand governor è incluso solamente nelle ultime versioni del kernel. Prova ad aggiornarlo.
D: La durata della batteria sembra essere peggiorata rispetto a prima.
R: Controlla le impostazioni del tuo BIOS. Potresti aver dimenticato di riattivarne alcune.
D: La mia batteria è carica, ma per KDE è del tutto scarica (riporta 0%) e, quindi, viene avviato la sequenza di shutdown.
R: Controlla che il supporto batteria sia attivato nel tuo kernel. Se lo hai compilato come modulo, assicurati di averlo caricato correttamente.
D: Nei miei log di sistema leggo cose del tipo "logger: ACPI group battery / action battery is not defined".
R: Questo messaggio viene generato dallo script /etc/acpi/default.sh incluso con acpid. Puoi tranquillamente ignorarlo. Se ti crea fastidio, puoi commentare la riga appropriata in /etc/acpi/default.sh come mostrato di seguito:
Codice 8.1: Disabilitazione degli avvisi per eventi acpi sconosciuti |
*) # logger "ACPI action $action is not defined"
|
D: Ho un Dell Inspiron 51XX e non riesco ad ottenere eventi ACPI.
R: Sembra essere un bug del kernel. Leggi qui.
D: Ho attivato l'opzione DynamicClocks in xorg.conf e ora ottengo crash / lo schermo rimane nero / il mio notebook non effettua correttamente lo shutdown (spegnimento).
R: Questo accade purtroppo su alcuni sistemi. L'unica soluzione è la disattivazione dell'opzione DynamicClocks.
D: Voglio utilizzare TuxOnIce, ma la mia partizione di swap viene indicata come troppo piccola. Non posso effettuare un suo ridimensionamento.
R: Se non c'è abbastanza spazio libero sul tuo sistema, è possibile utilizzare il filewriter al posto dello swapwriter. hibernate-script lo supporta bene. Maggiori informazioni nel file /usr/src/linux/Documentation/power/tuxonice.txt.
D: Ho appena comprato una nuova batteria, ma dura solo per pochi minuti! Cosa faccio di sbagliato?
R: Prima di tutto segui le istruzioni del venditore su come caricare correttamente la batteria.
D: Niente, è inutile. Cosa faccio ora?
R: Alcune batterie vendute come "nuove" sono in realtà vecchie. Prova questo:
Codice 8.2: Stato della batteria |
$ grep capacity /proc/acpi/battery/BAT0/info
design capacity: 47520 mWh
last full capacity: 41830 mWh
|
Se il valore di "last full capacity" differisce di molto da quello di design capacity, la tua batteria è probabilmente rotta. Usa la garanzia.
D: Non ho trovato una soluzione al mio problema. Cosa faccio?
R: Prova a contattarmi direttamente, Dennis Nienhüser. I forum di Gentoo sono un ottimo posto in cui chiedere e trovare aiuto. Se preferisci IRC, prova il canale #gentoo-laptop.
I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.