1 luglio 2008, 20:27
Questo post per avvisare gli utenti del mio repo personale che (come forse avranno già notato) è un periodo che non aggiorno.
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.
6 aprile 2008, 21:08
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.
5 aprile 2008, 00:51
Per un certo motivo qualche ora fa mi sono trovato a dover collegare un hard disk esterno (usb) al muletto (sempre lui, muloserver).
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.
24 febbraio 2008, 16:47
Sembra che klibc abbia dei problemi con l’ultimo kernel (2.6.24).
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.
2 novembre 2007, 14:33
Solo per informare gli utilizzatori del mio repo: sto mantenendo i binari di kernel26kamikaze e di tutti i moduli accessori.
27 ottobre 2007, 19:39
English readers: see below
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)
2 agosto 2007, 14:57
Ho messo su un patchset per il kernel, nulla di incredibile. Si basa sul patchset kamikaze, al quale però ho tolto alcune patch (ad esempio quella per avere lo stack a 4k invece che a 8k, perchè poco compatibile con ndiswrapper, ipw3945 e gspca1 perchè tanto abbiamo il pacchetto con il modulo a parte).
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.
22 giugno 2007, 19:50
In attesa di capire che cosa ne sarà di tutto il codice targato -ck, ci sono buone notizie per quanto riguarda kernel26viper. Ho trovato un utente (Mateusz) disposto a occuparsi del testing per l’architettura x86_64: preparerà quindi un config quanto più simile possibile a quello per x86, ovviamente ottimizzato per i 64 bit .
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.
17 giugno 2007, 10:16
Così recita la homepage di Con Kolivas, kernel hacker, autore del noto patchset -ck:
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.)
9 maggio 2007, 23:56
Ho trovato questo messaggio nella mailing list di linux-phc: https://www.dedigentoo.org/pipermail/linux-phc-user/2007-May/000082.html
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
