E’ un problema noto, elencato insieme alla soluzione nel sito del progetto Fedora.

I sintomi riguardano specialmente i notebook, dove per qualche motivo il processore va sempre alla massima velocità, anche se non ci sono applicazioni in esecuzione. Il demone cpuspeed non funziona perché non trova il supporto nel kernel alla variazione di velocità del processore.

Questo succede perché l’installer anaconda, per motivi che non sono ancora stati appurati, durante l’installazione sceglie l’architettura errata per il kernel: invece di i686 installa un kernel i586.

Per evitare il problema al momento dell’installazione, al prompt boot: che appare all’avvio dal supporto di installazione si passano i parametri:

linux i686

indicando al programma di installazione di selezionare un kernel di questo tipo.

Se invece abbiamo già Fedora funzionante, per verificare il tipo di kernel installato basta questo comando, dato da un terminale:

$ rpm -qa "kernel*" --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n"
kernel-devel-2.6.18-1.2798.fc6.i586
kernel-2.6.18-1.2798.fc6.i586

Se i pacchetti installati sono per architettura i586 ed avete da un Pentium II™ in su, vuol dire che avete il kernel sbagliato.

Per correggere la situazione potete operare in questo modo, dall’utente root:

1. installate il pacchetto yum-utils, che contiene l’utility yumdownloader
2. scaricate la giusta versione di kernel
3. se il kernel installato è di una versione predecente rispetto a quello scaricato da yumdownloader, potete installare direttamente il nuovo kernel e riavviare il computer
4. se invece la versione di kernel è la stessa, occorre forzare l’installazione.

Per il passo 1 il comando è:

# yum install yum-utils

Per il passo 2 il comando è:

# yumdownloader kernel.i686

Per il passo 3:

# rpm -ivh kernel-*.rpm

Se invece la versione del pacchetto è la stessa, invece del passo 3 occorre eseguire il passo 4:

# rpm -ivh --replacefiles --replacepkgs kernel-*.rpm

e poi riavviare il computer in tutti e due i casi.

Al riavvio per avere conferma della giusta versione di kernel basta ripetere il comando rpm visto prima:

$ rpm -qa "kernel*" --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n"
kernel-devel-2.6.18-1.2798.fc6.i586
kernel-2.6.18-1.2868.fc6.i686
kernel-headers-2.6.18-1.2868.fc6.i386
kernel-2.6.18-1.2798.fc6.i586


C’è ancora un problema: il pacchetto kernel-devel è per l’architettura sbagliata. Se abbiamo bisogno di compilare un driver non ci riusciremo a causa della differente configurazione del kernel i586 rispetto al tipo i686.

Da utente root togliamo il pacchetto kernel-devel per i586, prima di fare qualsiasi altra operazione:

# rpm -e kernel-devel-2.6.18-1.2798.fc6

Ora installiamo di nuovo il pacchetto kernel-devel, che viene scelto da yum con la giusta architettura:

yum install kernel-devel

Ora, controlliamo che sia usato il kernel giusto:

# uname -a
Linux aborigeno 2.6.18-1.2868.fc6 #1 SMP Fri Dec 15 17:32:54 EST 2006 i686 athlon i386 GNU/Linux

poi possiamo rimuovere il kernel i586:

# rpm -e kernel-2.6.18-1.2798.fc6

Fine. Attenzione, il comando rpm non avverte se si rimuove il kernel in esecuzione! Quindi ricontrollate tre volte i comandi digitati prima di eseguirli.

Per rendere le cose più semplici, potete usare questa procedura:

1. installate Fedora Core 6 passando linux i686 al prompt boot: e siete a posto.
2. Se avete già installato, NON eseguite l’aggiornamento
3. cambiate kernel e kernel-devel come spiegato sopra
4. procedete al normale aggiornamento.

Così non vi troverete altri pacchetti installati dall’aggiornamento con l’architettura errata.

(Modificato il 21 marzo 2007, su segnalazione di Alessandro Carducci)

E’ quindi evidente che non potrò pubblicare più nulla a riguardo, né potrò fornire alcun tipo di aiuto a nessuno, non potendo più sperimentare.

Spiacente.

Con il driver MadWifi si può attivare, ecco come.

Da utente root, aprire in modifica il file /etc/sysctl.conf, ed aggiungere queste due righe in fondo al file:

dev.wifi0.softled = 1
dev.wifi0.ledpin = 1

poi impartire il comando:

# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
dev.wifi0.softled = 1
dev.wifi0.ledpin = 1

Il led dovrebbe iniziare a lampeggiare lentamente, ad indicare la presenza della connessione wireless, per poi lampeggiare rapidamente in corrispondenza dell’attività sull’interfaccia.

Tutto qui. Ad ogni avvio le impostazioni saranno applicate automaticamente dagli script di configurazione di Fedora.

Nel sistema di tracciamento dei bug del driver siamo in tre a segnalare il medesimo sintomo, che si presenta in questo modo:

1. all’avvio dell’interfaccia wireless si riesce ad ottenere l’associazione con l’access point ed il rilascio di un indirizzo IP (se si lavora in DHCP), ma solo se ci si trova molto vicini all’access point (meno di 4 metri)
2. dopo pochi secondi (meno di dieci) la velocità della connessione piomba da 54mbit a 1mbit, poi si perde l’associazione con l’access point
3. il driver inizia a fare scansioni su tutti i canali radio disponibili, senza mai riprendere la connessione, solo se ci si avvicina drasticamente all’access point (meno di un metro), e comunque la velocità della connessione non risale mai a 54mbit, ma spesso rimane fissa ad 1mbit.

Questo succede indipendentemente dalla presenza di cifratura, dal modello di access point (ne ho provati tre, di marche diverse, anche rinomate), dalla presenza di DHCP o di indirizzo IP statico.

Ho smanettato a lungo, ma senza risultato, provando varie versioni del driver, compresa l’ultima al momento in cui scrivo (r1860).

Il problema risiede a quanto pare nel codice HAL del driver, che è fornito precompilato senza sorgenti, e che quindi non è ispezionabile, né tantomeno modificabile. Come dicevo, dalla versione r1611 è cambiato tutto il modulo HAL e da quel momento ha smesso di funzionare.

Luca Gugelmann, che cito col suo permesso, ha fatto test molto più estesi dei miei, ed ha scoperto che se si forza il driver ad usare lo standard 802.11b, quindi con velocità massima di 11mbit, la scheda funziona perfettamente senza il minimo problema. Per far questo occorre impartire il comando:

iwpriv ath0 mode 2

da utente root, subito dopo aver attivato l’interfaccia wireless. Per rendere permanente il comando, si può modificare la configurazione indicata nella guida per Fedora Core 4 al capitolo per il wireless, aggiungendo questa riga:

SECURITYMODE=restricted

se usate cifratura WEP, e modificando la riga con il parametro IWPRIV in questo modo:

IWPRIV="mode 2"

per “forzare” la scheda in modo 802.11b.

Tutto qui. Ovviamente rimane sempre la possibilità di tentare la compilazione del vecchio driver come spiegato nella guida per Fedora Core 6, ma attendiamo fiduciosi che qualcuno degli sviluppatori trovi il tempo di dare uno sguardo al problema, che pare abbiamo solo noi con i Thinkpad di ultima generazione.

Poi a metà di ottobre è uscita Fedora Core 6. Ho letto un po’ di note e di commenti sulle varie mailing list di Fedora a cui sono iscritto, e visto che nessuno lamentava problemi seri, ho deciso di fare un aggiornamento. Scaricata l’immagine via Bittorrent, anche perché il sito di Fedora era irraggiungibile per il sovraccarico, il 27 ottobre ho installato.

Che dire… sono rimasto senza parole. Il lavoro del team di Fedora si vede, e i miglioramenti ci sono.

Per prima cosa, niente più parametri da passare prima dell’installazione, l’accoppiata schermo/chipset video viene riconosciuta e tutta l’installazione fila via liscia senza problemi. Al termine il sistema è pronto per l’uso immediatamente.

Senza ricompilazioni e pezze al kernel, funziona tutto, compreso il lettore di memorie SD: basta inserirne una nello slot e compare una icona sul desktop con la forma di una SD appunto.

Il chipset video viene riconosciuto in tutto e (finalmente) OpenGL usa il Direct Rendering. Fra le voci del menu “Sistema/Preferenze” ce n’è una con la scritta “Desktop Effects”. Attivandola si passa al window manager Compiz, che funziona sfruttando l’OpenGL. Il risultato è veramente d’effetto: passando da un desktop all’altro con Ctrl-Alt-Sinistra o Ctrl-Alt-Destra si vedono ruotare come sulle facce di un cubo; prendendo una finestra dalla barra del titolo e trascinandola si deforma come se fosse elastica; lo stesso quando si massimizza, rimbalzando sui bordi dello schermo; portando la freccia del mouse in alto a destra del desktop, le finestre aperte si dispongono in parata, e basta cliccare su quella voluta per portarla in primo piano; usando Alt-Tab, il desktop arretra leggermente, scurendosi, e le varie finestre appaiono in miniatura con il contenuto “vivo”; i bordi delle finestre sono semitrasparenti. Non sono un fanatico degli effetti speciali, ma in questo caso devo ammettere che l’effetto è degno di nota. Senza contare che alcune delle funzioni sono veramente comode.

Ovviamente, non tutto è rose e fiori. Il dispositivo APS (l’accelerometro) non è ancora riconosciuto, e, da quanto leggo in alcuni messaggi nella mailing list del progetto, pare che al momento non sia pronta una patch per parcheggiare le testine del disco al volo, o meglio, c’è ma presenta problemi di stabilità, per cui preferisco che sia qualcun altro a rischiare dati ed hardware per i test.

Per un bug nel programma di installazione di Fedora (nome in codice anaconda) viene installato il kernel sbagliato, cosa piuttosto seccante, ma c’è la correzione, da applicare subito, prima di fare qualsiasi altra cosa.

Altro problema piuttosto ostico è con l’interfaccia di rete wireless. Per qualche motivo che non sono riuscito ad appurare, il driver MadWifi dalla versione r1611 ha smesso di funzionare quasi del tutto: solo se sono a meno di un metro dal mio access point riesco ad acquisire l’indirizzo di rete, ed in ogni caso se mi allontano a due metri il collegamento cade.

Ho scritto un bug report agli sviluppatori del driver, e pare che non sia il solo ad avere questo problema, ma per ora nessuna risposta.

Per non rimanere “scollegato”, ho preso la versione r1605 del driver ed ho provato a compilarla, ma l’operazione non va a buon fine, anche perché sono cambiate parecchie cose nel kernel nel frattempo. Pasticciando con make e con il poco linguaggio C che conosco, sono riuscito a compilare con successo il driver, ed ora vado senza problemi con la mia scheda wireless.

Per chi volesse fare un po’ di bricolage, qui trovate la patch da applicare alla versione r1605 dei driver MadWifi per compilarli con successo su Fedora Core 6. La versione r1605 del driver si può prelevare direttamente dal sito MadWifi.

Insomma, se avete un ThinkPad Z60t e state pensando di passare a Fedora Core, non indugiate oltre: ne rimarrete più che soddisfatti.

Un ultimo consiglio: se potete installate sempre la directory /home su una partizione separata. Quando vi troverete a cambiare distribuzione Linux potrete sempre fare una installazione ex-novo, invece di essere costretti a fare un upgrade, portandovi poi appresso configurazioni obsolete e problemi vari. I vostri dati saranno al sicuro sulla partizione /home, e per di più conservate le vostre impostazioni: nel mio caso i bottoni aggiuntivi che mi ero configurato nei pannelli e le applet di Gnome erano tutte al loro posto, come pure tutta la posta di Evolution con i filtri e gli indirizzi.

Anche questa guida è citata sul sito:

NB: la vecchia guida rimane valida per tutto quello che riguarda le impostazioni della console, della rete wireless, ed in generale per tutti i consigli di installazione. Quando ci saranno altri aggiornamenti verranno pubblicati a parte sotto la categoria apposita.

Pubblicato qui.

La guida è citata sul sito:

E su:

Aggiornamento

Non dimenticate di dare uno sguardo anche all’installazione di Fedora Core 6 ed agli altri articoli riguardanti il Thinkpad Z60t.