E’ pur sempe richiesta una patch nel kernel, ma almeno adesso non è richiesto ext3 come fs.

Conto di metterci le mani sopra quanto prima!

A dire il vero ho scoperto ora per caso che esiste in aur il pacchetto del solo modulo acpi-cpufreq per il kernel -ARCH, già patchato.

Quindi anche chi usa il kernel -ARCH può rimpiazzare quel modulo installando il pacchetto da aur e avvalersi del downvolting.

W aur!

Link: http://aur.archlinux.org/packages.php?ID=18310

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

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.

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.

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.

info: http://downloads.archlinux.de/iso/archboot/2008.12/

Non è una release ufficiale, sono in test, però possono tornare utili a chi serve un cd di installazione con l’ultimissimo kernel.

Ovvero mi sono interessato a questo: http://lwn.net/SubscriberLink/299483/fa0208e48cf3eeac/

L’interesse è partito da un topic sul forum archlinux.it iniziato dal buon adriano (http://adrinux.wordpress.com/2008/12/04/boot-rapido-5-secondi-anche-su-archlinux/).

Per farla breve, fino ad adesso si è lavorato su questi due punti:

• inclusione nel kernel -ARCH della patch fastboot, che riduce il tempo di avvio del kernel facendo alcune cose in modo asincrono
• inclusione di sreadahead negli script di init di arch (rc.sysinit in particolare) e con esso anche l’integrazione della patch a ext3 per marcare i file utilizzati in fase di boot (è necessaria una root in ext3)

A giudicare dai grafici bootchart di adriano fatti su una macchina reale (io per ora sto lavorando su una macchina virtuale), sreadahead fa il suo dovere.

Il tempo di boot però non pare ridursi così tanto, anzi si notano ancora delle pause indesiderate (in particolare nella fase finale, guardate nel topic del forum i grafici).

C’è dell’altro da fare con gli script di init, quasi sicuramente.

Aggiornamenti a seguire.

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.

A questo link il changelog “umano” redatto da Linux Kernel Newbies: http://kernelnewbies.org/LinuxChanges

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.

Una volta collegato mi sono accorto che il modulo usb_storage non veniva caricato.

Considerato l’uptime della macchina (100 giorni e spiccioli) ho immaginato quale potesse essere il problema: il kernel in esecuzione – 2.6.23-ARCH – differiva dal kernel installato con pacman (ovvero kernel26) – 2.6.24-ARCH -

Effettivamente era andata proprio così: i vari aggiornamenti del pacchetto kernel26 hanno sovrascritto (com’è giusto che sia, d’altronde) i moduli del kernel correntemente in esecusione, e questo su una macchina che non viene riavviata di frequente è un bel problema, visto che la versione dei moduli installati non coincide con il kernel attivo.

Per ora ci ho messo una pezza aggiungendo

IgnorePkg = kernel26

in pacman.conf. Ovvero evito di aggiornare il kernel, cercando di aggiornarlo selettivamente solo in caso di reboot.

Se qualcun’altro avesse idee migliori, o se mi dovesse sfuggire qualcosa, sono ben accetti consigli.

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.

Un po’ a malincuore, ho constatato di non potermi più permettere così tanto tempo libero da dedicare al patchset -pierlo.

Inoltre il patchset kamikaze (dal quale prendevo la maggior parte delle patch) sta dimostrando una continua evoluzione, e sembra andare proprio nella direzione che speravo di prendere io con il mio patchset.

Ho pensato quindi di concentrare le eventuali poche forze disponibili nel contribuire come meglio posso allo sviluppo di kamikaze.

Colgo l’occasione per ringraziare i numerosi utenti che hanno avuto il coraggio di sperimentare con il mio patchset, e coloro che con i loro preziosi suggerimenti hanno contribuito a migliorarlo.

Un ringraziamento molto speciale va anche a imachine aka Mateusz Jedrasik, per il continuo aiuto (in modo specifico per quanto concerne la piattaforma x86_64)

English:I have decided to stop the development of -pierlo patchset due to time constrains.

The kamikaze patchset (which was the main source of the patches I included in -pierlo) is getting better day after day. I hope to be able to concentrate my (reduced) forces in improving it.

Thank you all for using -pierlo, reporting bugs, giving me suggestions.

I want to say “thank you” in particular to imachine aka Mateusz Jedrasik for his big help (especcially about the x86_64 platform)

Alle patch di kamikaze ho aggiunto poi qualche piccola patch da ragnarok e le patch presenti in kernel26 (kernel ufficiale archlinux).

Questo è quanto, per il momento. Il tutto è disponibile in aur (kernel+moduli) e nel mio repo personale.

Da notare che ancora non è pronto il supporto a x86_64 (basta preparare il config, ma non ho macchine su cui testarlo), e che il logo è ancora quello del kernel viper, il logo con il tag aggiornato l’ho preparato e verrà shippato con la terza release.

Graditissimi i commenti.

Ho deciso inoltre di riportare come default vesafb al posto di vesafb_tng perchè quest’ultima:

• non è compatibile con i 64 bit
• a fronte di pochi vantaggi (maggiore semplicità di configurazione e in certi casi velocità) risulta essere problematica per certi utenti

Ovviamente il kernel rimarrà patchato per supportare vesafb_tng, ma questa non sarà abilitata nel config di default e di conseguenza nemmeno nei binari che metto a disposizione nel mio repo.

Quanto questo cambiamento avverrà, un apposito messaggio nel post_upgrade vi informerà di aggiornare la stringa della risoluzione nel bootloader.

2.6.22-ck1 will be the last -ck ever

La stessa (triste) notizia è riportata anche nel topic del canale IRC di supporto (irc.oftc.net #ck).

L’unica speranza rimane per quanto riguarda l’annuncio ufficiale in ML che Kolivas deve ancora postare. Speriamo in un ripensamento, o se questo è troppo, almeno nella notizia che non tutto il lavoro di Con sia destinato a morire.

[edit]: il messaggio di addio è arrivato, e pare veramente che sarà difficile che Kolivas si riavvicini al kernel, come lui stesso scrive con amarezza:

1. If whatever performance advantage it has is all but abolished compared to
mainline then there is no point maintaining alternate patches to achieve the
same endpoint.
2. All interest I have in kernel development, even out of the mainline
spotlight, has been… abolished (I had nastier words but decided not to use
them.)

Descrive come risolvere l’incompatibilità tra la patch linux-phc e il kernel 2.6.21.

Ho ricompilato kernel26viper patchando come dovuto, e ora finalmente posso beneficiare del downvolting anche sul kernel più recente.

Ovviamente ho anche postato la patch sul thread nel forum di gentoo: http://forums.gentoo.org/viewtopic-p-4048985.html#4048985