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 :)

I dettagli li rimando, lascio solo un breve resoconto dell’installazione e della prima configurazione.

Partizioni Originarie

Il disco principale dell’eeepc (4 GB) si presenta partizionato in 4 partizioni. Le prime due sono utilizzate da xandros (di cui una in sola lettura). Le restanti 2 sono due piccole partizioni di circa 8 MB (mega!), una utilizzata per eventuali aggiornamenti bios (è possibile copiarci li il file del bios e al boot questo verrà aggiornato), e l’altra utilizzata per la funzione fastboot del bios.

Io ho piallato tutto eccetto l’ultima partizione, visto che il fastboot è assai splendido :)

Eventuali aggiornamenti del bios li farò passare da una pennetta usb.

Installazione di arch

Ho usato un masterizzatore dvd usb e l’iso di test 2008.12, per installare un sistema base.

Ho creato un’unica partizione nel disco da 4GB (eccetto quella per il fastboot) e l’ho formattata in ext2.

Niente swap.

Ho in seguito utilizzato la connessione ethernet (il modulo era già presente nel kernel) per compilare il modulo wifi (rt2860, si trova in AUR).

netcfg ha qualche problemino a funzionare. Seguendo il consiglio del wiki di arch ho optato per wicd.

Xorg funziona splendidamente senza dover scrivere nessun file di configurazione. Nota: ricordarsi di installare hal e aggiungerlo ai demoni, altrimenti xorg parte senza le periferiche di input e bisogna riavviare la macchina.

Improving it!

Tra le prime cose che ho fatto, ho montato un tmpfs in /tmp e lì ci ho fatto anche cachare (non è una brutta parola!) firefox.

Oggi ho un po giocato con i kernel di robertek, uno zen ricompilato su misura (oserei dire “striminzito”, sono 5MB) per il 901.

Installato il kernel zen-eee dal suo repo, ho installato anche acpi-eee901, che contiene gli script acpi per gestire i tasti funzione. Contiene anche il programma asusosd, che lanciato all’avvio di openbox mi da un riscontro visivo con un popup quando alzo/abbasso volume e luminosità.

Successivamente ho ricompilato il kernel zen-eee per includere un po di moduli che non so per quale motivo erano stati lasciati fuori.

A breve scrivero di qualche altro pasticcio, e di tutto quello che causa dimenticanza e fretta ho sicuramente dimenticato di dire.

Ovviamente affinchè il gioco valga la candela, occorre che  il processo di compressione/decompressione dei dati sia pur sempre più veloce del corrispettivo utilizzo dello swap su disco (e normalmente ciò è vero).

Per utilizzare compcache occorre un kernel patchato (ad esempio zen), e compilato con il supporto a compcache (come modulo o statico).

Se compilato come modulo, occorrerà inserire il modulo “compcache” alla lista dei moduli in rc.conf

In fstab andrà messo il dispositivo virtuale di swap:

/dev/ramzswap0   swap             swap        pri=1,defaults         0   0

“pri=1″ serve per aumentare la priorità di questo dispositivo di swap rispetto ai restanti (in questo modo avrà la precedenza, e solo se si saturerà verrà utilizzata la partizione di swap del sistema)

Di default compcache alloca il 25% della ram.

Sul mio portatile (512 MB di ram e un disco non propriamente veloce) l’utilizzo di compcache risulta vantaggioso.

Ho iniziato a mettere mano al config del kernel26-zen per adattarlo alla mia specifica configurazione hardware, e allo stesso tempo ho messo mano ai flag in /etc/makepkg.conf per produrre pacchetti strettamente ottimizzati sulla mia macchina.

A questo aggiungiamo la recente difficoltà a stare dietro a tutti pacchetti dei moduli aggiuntivi (che tra l’altro nemmeno uso personalmente! a parte nvidia-beta), moduli che non sempre compilano, visto il naturale frequente aggiornamento del kernel zen (è syncato alle rc del kernel vanilla).

Ho deciso di mettere per iscritto che per ora si tratta di un semplice freeze, il repo non chiude ma rimane congelato, sperando di avere al più presto tempo e voglia di riprenderlo in mano.

Ho rimosso i pacchetti klibc-zen e v86d-zen in quanto inutili. In [core] si trovano già klibc (linkato ad un kernel compilato con uvesafb) e si trova anche v86d.

In particolare, mi sono imbattuto in un kernel panic in fase di boot dovuto all’uso di uvesafb (e quindi v86d compilato su klibc e linkato nell’immagine di initcpio).

Se ne parla anche sul forum ufficiale di arch, e questo bug conferma l’esistenza di problemi tra klibc e il kernel 2.6.24 (http://bugs.archlinux.org/task/9482)

Di conseguenza, fino a che non sarà fixata la situazione, ho provveduto a rimuovere il supporto a uvesafb dal kernel26zen che distribuisco nel mio repo. Inoltre ora kernel26zen risulterà in conflitto con klibc-zen.

• Official thread: “zen-sources”
• Official thread: “zen-sources” – Part II
• Official thread: “zen-sources” – Part III

Repository git:

• linux-2.6/zen-sources.git

Homepage:

• http://www.zen-sources.org/

Allo stato attuale contiene:

catalyst-zen 7.11-20071212
kernel26zen-git 2.6.24.rc5.zen0.20071212-1
klibc-zen 1.5-20071212
ndiswrapper-zen 1.50-20071212
nvidia-beta-zen 169.04-20071212
nvidia-utils-beta 169.04-1
nvidia-zen 100.14.19-20071212
v86d-zen 0.1.2-20071212
virtualbox-modules-zen 1.5.2-20071212

Come potete vedere, ho deciso di utilizzare una data come release number dei pacchetto: trovo che sia più comodo visto che tanto ad ogni aggiornamento che farò di kernel26-git dovrò ricompilare pure i moduli esterni (e prevedo aggiornamenti frequenti, almeno uno a settimana, sempre che ci sia “materiale” nuovo nel repository git di zen).

Devo fare alcune precisazioni: la versione di kernel26zen che fornisco è compilata con la dimensione dello stack a 4KB, questo significa che la compatibilità di ndiswrapper con i driver windows è minore (non sono sicuro in quale misura, ma è sicuramente minore). E’ anche vero però che in zen sono inclusi aggiornamenti per quanto riguarda il sottosistema wifi del kernel, e quindi ci sono moduli nativi nuovi/migliorati che potrebbero, in alcuni casi, sostituire egregiamente ndiswrapper.
Inoltre voglio segnalare quali sono i pacchetti che posso testare direttamente (e che di fatto utilizzo quotidianament): klibc-zen, v86d-zen nvidia-utils-beta, nvidia-beta-zen, virtualbox-modules-zen.

Nota: nvidia-zen è la versione del driver nvidia compilata per il pacchetto nvidia-utils che trovate in extra. Tengo anche questa versione per non forzare l’aggiornamento di nvidia-utils, e mantenere così la compatibilità con il modulo del pacchetto ufficiale compilato per il kernel -ARCH.

Se c’è interesse per altri pacchetti, non esitate a farmelo sapere.

La notizia bella è che morto kamikaze, nasce zen: ad occuparsene sarà sempre il mitico Waninoko insieme a rmh3093.

La novità più grossa consiste in un repository git dal quale poter attingere sempre all’ultima versione delle patch impiegate nel patchset.

Ci saranno lo stesso una serie di rilasci (snapshot) stabili.

In AUR il buon p4ddY ha già reso disponibili i PKGBUILD per kernel26zen-git e i moduli aggiuntivi.