pierloz.com

Utilizzando un eeepc 1015pd ho riscontrato un bug (in linux) nella gestione della retroilluminazione del display lcd.

Accade in certi casi che la luminosità massima del display sia più bassa di quanto dovrebbe essere.

Ad esempio, se si abbassa la luminosità al minimo e si riavvia il sistema, non sarà possibile riportare la luminosità al suo livello massimo.

La regolazione dei vari livelli di luminosità funziona, ma tutti i livelli sono traslati verso luminosità più basse del normale.

E’ possibile aggirare questo bug (in attesa di un probabile fix nel kernel) usando il comando:

setpci -s 00:02.0 f4.b=ff

Per rendere definitivo il fix, occorre eseguirlo ad ogni boot (inserendolo ad esempio in /etc/rc.local).

Ho trovato la giusta combinazione di tempo/voglia/karma per mettere mano prima agli script di init (con quick-init) e poi a init stesso (con finit-arc).

Tutto questo grazie al lavoro di adriano

Ho provato entrambe le soluzioni, e alla fine ho scelto finit-arc perchè 1) mi consente di fare il boot “alla vecchia maniera” in caso di necessità e 2) è risultato anche più veloce di quick-init.

Cronometro manuale alla mano (nessuna voglia di installare bootchart) ora l’eeepc 901 di cui dispongo fa il boot da grub a X in circa 8 secondi.

Utilizzo un kernel che compilo personalmente (si tratta di un vanilla + zen), senza immagine di init e con tutti i moduli statici eccetto ethernet, wlan e eeepc_laptop.
In particolare, eeepc_laptop impiega più di 10 secondi a caricarsi, quindi l’ho aggiunto a /usr/sbin/services.sh per farlo caricare in background.

Questo il services.sh attuale:


#!/bin/sh

#Starting background daemons
/etc/rc.d/syslog-ng start &>/dev/null &
(/etc/rc.d/hal start && /etc/rc.d/wicd start) &> /dev/null &
modprobe eeepc_laptop &
echo "24 17 15 15" > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids &
echo "24 17 15 15" > /sys/devices/system/cpu/cpu1/cpufreq/phc_vids &


Dei benefici del downvolting della cpu ne ho scritto già in passato, e il mio pentium M 740 è 3 anni che gira downvoltato.

La bella notizia è che anche l’atom può essere downvoltato, e l’altra bella notizia è che la patch phc (già integrata in zen) lo supporta già.

La mezza cattiva notizia è che non si può abbassare il voltaggio della cpu quando ha moltiplicatore minimo. Ovvero a 0,8Ghz il voltaggio minimo è quello di default.

Per ora me la sono cavata con l’aggiunta in rc.conf di queste due righe:

echo “24 17 15 15″ > /sys/devices/system/cpu/cpu0/cpufreq/phc_vids
echo “24 17 15 15″ > /sys/devices/system/cpu/cpu1/cpufreq/phc_vids

Con il tempo vedrò se i voltaggi vanno bene.
La ventolina al massimo potrebbe essere un ricordo :)

Sul forum inglese di arch (e non solo lì) diversi utenti si sono lamentati di un calo di prestazioni dei driver video intel.

Ho voluto verificare se il consiglio di utilizzare XAA come AccelMethod sia valido.

Ho usato il bechmark gtkperf per controllare le prestazioni dell’intel 945GME integrata nell’eeepc 901.

Ecco i risultati per quanto riguarda XAA:

GtkEntry – time: 0,15
GtkComboBox – time: 2,30
GtkComboBoxEntry – time: 1,47
GtkSpinButton – time: 0,28
GtkProgressBar – time: 0,21
GtkToggleButton – time: 0,42
GtkCheckButton – time: 0,28
GtkRadioButton – time: 0,66
GtkTextView – Add text – time: 2,07
GtkTextView – Scroll – time: 0,70
GtkDrawingArea – Lines – time: 1,81
GtkDrawingArea – Circles – time: 3,98
GtkDrawingArea – Text – time: 5,76
GtkDrawingArea – Pixbufs – time: 0,28
—
Total time: 20,37

e per quanto riguarda EXA:
GtkEntry – time: 0,15
GtkComboBox – time: 2,33
GtkComboBoxEntry – time: 1,42
GtkSpinButton – time: 0,27
GtkProgressBar – time: 0,21
GtkToggleButton – time: 0,38
GtkCheckButton – time: 0,28
GtkRadioButton – time: 0,73
GtkTextView – Add text – time: 2,22
GtkTextView – Scroll – time: 0,92
GtkDrawingArea – Lines – time: 2,39
GtkDrawingArea – Circles – time: 5,45
GtkDrawingArea – Text – time: 5,03
GtkDrawingArea – Pixbufs – time: 0,28
—
Total time: 22,07

Infine, EXA con opzione “MigrationHeuristic” “greedy”

GtkEntry – time: 0,12
GtkComboBox – time: 2,07
GtkComboBoxEntry – time: 1,69
GtkSpinButton – time: 0,28
GtkProgressBar – time: 0,24
GtkToggleButton – time: 0,47
GtkCheckButton – time: 0,24
GtkRadioButton – time: 0,68
GtkTextView – Add text – time: 2,27
GtkTextView – Scroll – time: 0,89
GtkDrawingArea – Lines – time: 2,45
GtkDrawingArea – Circles – time: 5,71
GtkDrawingArea – Text – time: 18,29
GtkDrawingArea – Pixbufs – time: 0,55
—
Total time: 35,96

Come si può vedere, XAA risulta il più performante, seguito a ruota da EXA, mentre EXA con l’opzione “greedy” risulta molto molto più lento (eppure viene consigliata in certi siti).

Sembra però che con la recente inclusione del GEM di intel (graphics execution manager) nel kernel 2.6.28, EXA (o meglio, il nuovo UXA) migliorerà al punto da essere finalmente più veloce di XAA.

Non tentare di aggiornare il bios di un eeepc nel cuore della notte, a meno di non essere soli.

Bippa da morire, maledetto :/

Oggi pomeriggio ho voluto sperimentare sreadahead sull’eeepc 901.

Prima cosa da fare è stato portare la patch da ext3 a ext2, visto che sul piccolino ho scelto ext2 come filesystem per la root.

Considerato la diretta discendenza di ext3 da ext2, è stato molto semplice prendere la patch di sreadahead scritta per ext3 e crearne una per ext2.

Ho poi ricompilato il kernel (lo zen presente nel repository di robertek), ovviamente con l’aggiunta della patch appena scritta.

Ora ho sreadahead funzionante, anche se a onor del vero non vedo nessun incremento di velocità di boot (ovvero, anche senza sreadahead, sono sempre sotto i 20 secondi compreso ambiente grafico openbox+lxpanel+qualche_altra_robetta).

Mi resta da togliermi lo sfizio di guardare un bootchart, perchè stranamente bootchart non vuole funzionare.

A presto per altre osservazioni.