Guida alla stabilità dell'hardware Linux, parte 2Un problema di stabilità non è quasi mai causato da un hardware difettoso, ma da una impropria configurazione dell'hardware o da driver sbagliati. La mia esperienza in questa area è iniziata quando ho cercato di utilizzare Linux con la mia Diamond Viper V550, una scheda grafica NVIDIA TNT, usando il driver proprietario NVIDIA con accelerazione grafica. NVIDIA ha i propri driver grafici per Linux, sviluppati in collaborazione con SGI e VA Linux. Questi driver hanno parecchi vantaggi rispetto i driver standard NVIDIA, solamente 2D, inclusi in XFree86 4.0. Uno su tutti, supportano interamente l'accelerazione 3D. Ancora meglio, eseguono una versione ufficiale di OpenGL 1.2, invece di una versione appena migliorata di Mesa. Cosi, in definitiva, questi driver accelerati sono quelli che voi vorreste utilizzare se possedeste una scheda grafica NVIDIA, almeno in teoria. Il mio tentativo di farli lavorare al meglio è stato, come minimo, una eccellente esperienza di apprendimento. Dopo aver installato i driver NVIDIA con accelerazione per Linux (si veda Risorse al termine di questo articolo), ho riavviato XFree86 e iniziato a "giocare" con le mie applicazioni 3D, ora magnificamente accelerate come dovrebbe essere. Fino a quel momento, avevo dovuto utilizzare Windows NT per approfittare dei vantaggi della accelerazione 3D. Tuttavia, dopo circa un'ora, le mie aspirazioni di utilizzare il 3D in Linux hanno subito una battuta d'arresto -- la mia macchina si è bloccata. Il mouse ha smesso di muoversi, il mio schermo si è congelato e ho dovuto riavviare il mio sistema. Si, stavo avendo alcuni problemi di stabilità. Ma non sapevo esattamente cosa stava causando il problema. Avevo un hardware difettoso, o era la scheda malconfigurata? Oppure era un problema con il driver -- a cui non piaceva la mia schedamadre VIA KT133 per Athlon? Qualunque fosse il problema, volevo risolverlo velocemente. In questo articolo, condividerò con voi la procedura con la quale ho risolto i miei problemi di stabilità dell'hardware. Sebbene voi potreste non lottare esattamente con gli stessi problemi, i passi che io ho utilizzato per diagnosticare e (probabilmente) risolvere il problema sono generalmente validi e applicabili a molti diversi problemi di hardware con Linux. La prima cosa che mi passò per la mente era che potevo avere dell'hardware difettoso o poco raffreddato. Da un lato, la mia Diamond Viper V550 sembrava non avere problemi sotto Windows NT. Dall'altro, probabilmente Linux in qualche maniera sollecitava di più il mio hardware generando blocchi per sovratemperatura. La mia V550 diventava estremamente calda, e il suo sistema di raffreddamento originale sembrava a malapena sufficiente. La combinazione dei blocchi e il fatto che la scheda era poco raffreddata mi convinse ad acquistare una ventola con estrattore di calore integrato per la mia V550 (si veda Risorse). Cosi, ricevuto il mio nuovo dissipatore, ho tolto l'originale sulla scheda video (facendo decadere la garanzia), pulito il chip TNT e montato il nuovo dissipatore. Verdetto? La mia scheda video non era più estremamente calda ora, ma i blocchi continuavano. La lezione insegnatami da questa particolare esperienza è questa -- Se ci si è assicurati che i sistemi sono adeguatamente raffreddati, non ci si deve preoccupare dei malunzionamenti dovuti a raffreddamento inadeguato. Questa è una buona ragione per investire un po' di tempo e lavoro per assicurarsi che le vostre workstation e i vostri server lavorino con un buon raffreddamento. Ora che mi ero occupato del problema del raffreddamento, sapevo che i blocchi non erano probabilmente dovuti ad hardware difettoso e ho iniziato a guardare altrove. Nuovi driver -- e una possibile soluzione? Sospettavo che i driver NVIDIA fossero loro stessi in parte causa del problema. Fortunatamente, una nuova versione dei driver era appena stata realizzata, cosi immediatamente ho aggiornato, sperando che questo risolvesse i miei problemi di stabilità. Sfortunatamente non fu cosi e, dopo aver parlato con altri sul canale #nvidia di openprojects.net, ho capito che mentre nessuno era in grado di ottenere driver stabili, i driver funzionavano per molte persone. In #nvidia, qualcuno suggerì di verificare che la V550 non condividesse un IRQ con un'altra scheda. Diversamente dal driver standard di XFree86, il driver NVIDIA con accelerazione richiede un indirizzo IRQ per il proprio funzionamento. Per verificare se il driver avesse un proprio IRQ dedicato, ho eseguito il comando cat /proc/interrupts, ed ecco! guarda! la mia scheda video condivideva un indirizzo con il mio controller IDE. Prima di spiegare come risolvere questo problema particolare, vi darò un abreve spiegazione sugli IRQ. I PC usano gli IRQ e gli indirizzi hardware in generale, per permettere alle periferiche, come le schede video e i controller degli hard-disk, per informare la CPU che hanno dei dati pronti per essere trattati. Nel passato, prima che esistessro i bus PCI, era rigorosamente necessario che ogni dispositivo avesse un proprio IRQ dedicato. Nel caso in cui stiate ancora usando delle periferche ISA nella vostra macchina, questo è ancora necessario e tutti i dispositivi non PCI dovrebbero avere un proprio IRQ dedicato. Comunque, le cose sono un po' differenti con il bus PCI. PCI riserva quattro IRQ che possono essere utilizzate dalle schede PCI/AGP nel sistema. In generale, questi IRQ possono essere condivisi tra diversi dispositivi. (Se si fa questo, siate certi che tutti i dispositivi che condividono [gli IRQ] siano PCI o AGP.) La condivisione degli IRQ è importante, specialmente per le machine moderne che hanno cinque PCI ed uno slot AGP. Senza la condivisione degli IRQ, non si sarebbe in grado di avere più di quattro schede che utilizzano gli IRQ nel sistema. Ci sono, tuttavia, alcune limitazioni alla condivisione di IRQ per PCI. Mentre i BIOS delle moderne schedemadri e il Linux kernel generalmente supportano la condivisione di IRQ per PCI, alcune schede video possono semplicemente rifiutarsi di lavorare correttamente quando condividono un IRQ con un altro dispositivo. Se avete blocchi casuali del sistema, specialmente blocchi che appaiono correlati con l'uso di un dispositivo hardware specifico, potreste volere cercare di imporre che tutti i vostri dispositivi PCI usino un loro proprio IRQ, giusto per essere sicuri. Il primo passo è vedere se nel vostro sistema ci sono degli IRQ condivisi. Per far questo, seguite questi passi:
Se uno di quei dispositivi non è un dispositivo PCI (ISA o altre schede legacy), avete trovato voi stessi un conflito di IRQ, che potete tentare di risolvere con il vostro BIOS, con il pacchetto isapnptools, o con i jumper fisici sulle vostre schede periferiche. Fate attenzione che se il vostro dispositivo è costruito nella vostra scheda madre, è molto probabile che sia un dispositivo PCI che non occupa uno slot fisico PCI. Se tutti i dispositivi in questione sono PCI o AGP, avere o non avere un problema dipende dal vostro hardware. Qui ci sono alcuni passi con i quali potete tentare di stabilire per i vostri dispositivi PCI/AGP i loro IRQ:
Se sospettate che due vostri dispositivi PCI stiano ancora condividendo un IRQ, avete ancora due opzioni. Alcuni BIOS permettono di assegnare alcuni IRQ ad uno slot PCI specifico. Se possedete uno di queti rari BIOS configurabili, potete usare queste funzionalità per eliminare i conflitti. Se non avete questa opzione nel vostro BIOS (molti non ce l'hanno), c'è un altro modo sicuro per risolvere questo problema -- Spegnete la macchina, staccate l'alimentazione e aspettate alcuni minuti. Ora, aprite il case e rimuovete fisicamente le schede dai differenti slot. Queta opzione può sembrare un po' strana, ma funzionerà sicuramente, specialmente se avete pochi slot PCI liberi nel vostro sistema (ma potrà farvi perdere un po' di tempo per trovare la corretta disposizione per ognuna delle vostre schede). Io ho ottimizzato il "trucco di permutazione delle schede PCI" e sono stato abile nel permettere a tutti i miei dispositivi di usare un unico IRQ. O quasi. Come potete osservare, due dei miei hard-disk ancora condividono un IRQ:
Tuttavia, questo è normale poichè i dispositivi IDE2 e IDE3 sono integrati nello stesso chip del mio Promise FastTrak IDE Card cosi, ora (quasi) tutti i miei dispositivi hanno un solo IRQ, ho utilizzato i miei driver con accelerazione e... un nuovo blocco in meno di un ora. Apparentemente, la condivisione di IRQ tra PCI non era il solo problema. Oh, bene ... è tempo di cercare altrove (ancora una volta). Risolto un problema, trovane un altro Dopo un po' di tempo, ho trovato qualcosa d'altro che avrei potuto fare affinché i driver NVIDIA funzionassero perfettamente, sebbene più lentamente -- disabilitare AGP. Anche se non volevo farlo, l'ultima versione dei driver permetteva alla AGP di essere disabilitata interamente semplicemente aggiungendo una linea in XF86Config. Con AGP disabilitata, avevo ridotto la larghezza di banda della mia memoria video di 4 volte, ma un 3D significativamente più lento era molto più veloce di un hardware completamente senza un'accelerazione 3D. Dopo aver disabilitato AGP avevo finalmente un sistema stabile! Tuttavia, questa soluzione temporanea creava un altro problema. Ogni volta che una animazione 3D OpenGL era in funzione, l'audio diventava estremamente confuso e disturbato. Aha! Fortunatamente ero in grado di trovare una soluzione al mio problema audio. Ho utilizzato l'utility setpci per fissare più appropriatamente il tempi di latenza del bus PCI per i miei dispositivi PCI. Vi mostrerò la soluzione in particolare tra poco -- ma prima qualche spiegazione. Come probabilmente sapete, il bus PCI è una risorsa condivisa -- tutte le schede PCI hanno un turno per la comunicazione sul bus, e normalmente, va tutto bene. Tuttavia, poichè il bus PCI è una risorsa condivisa con una banda limitata (di solito adeguata), è possibile che una scheda influisca negativamente sulle prestazioni delle altre schede nel sistema. Per esempio, che cosa succederebbe se la scheda PCI A stesse inviando dati attraverso il bus e nello stesso momento la scheda B tentasse di spedire dei dati? La scheda A potrebbe garbatamente concedere l'uso del bus, o continuerebbe con il suo trasferimento dati -- e se cosi fosse per quanto tempo? Il tempo degli stati di latenza di PCI La risposta a questa domanda dipende sempre dai parametri di configurazione di ogni dispositivo PCI, il tempo dello stato di latenza di PCI. Normalmente è il modello del driver Linux a fissare il valore del tempo di latenza di ogni dispositivo PCI, e il più delle volte il valore è adeguato (per non dire ottimo), tutti i dispositivi funzionano bene e il sistema lavora adeguatamente. Il tempo di latenza può variare da zero a 248. Se il dispositivo è configurato a zero, darà immediatamente il bus ad un altro dispositivo che ha la necessità di trasmettere. Se il dispositivo è impostato a 248, continuerà ad usare il bus per un lungo periodo prima di fermarsi, mentre l'altro dispositivo aspetterà il suo turno. Se tutti i dispositivi sono configurati con tempo di latenza relativamente alto e molti dati devono essere spediti attraverso il bus, allora le schede PCI generalmente dovranno aspettare più a lungo prima di ottenere il controllo del bus e poter iniziare a trasmettere i dati. Una volta ottenuto il controllo del bus, saranno in grado di spedire una grande quantità di dati attraverso di esso prima di dare il bus ad un altro dispositivo. Questo perchè un alto valore del tempo di latenzaaumenta la latenza (il ritardo tra la richiesta e il momento in cui viene ceduto il controllo del bus), ma anche aumenta la larghezza di banda effettiva. Ogni dispositivo invia una grande quantità di dati attraverso il bus senza interruzioni, il bus PCI è usato in modo più efficiente e il bus PCI può trasmettere più dati. D'altra parte, se tutti i tuoi dispositivi PCI hanno un basso valore del tempo di latenza, allora concederanno velocemente il bus se un'altro dispositivo richiede di trasmettere dati. Questo significa che una minore quantità di dati rimane in attesa, dato che nessun dispositivo mantiene il controllo del bus per un lungo periodo di tempo, lasciando gli altri dispositivi in attesa. Lo svantaggio di tutto questo è che un basso valore del tempo di latenza riduce l'effettiva larghezza di banda quando due o piu dispositivi PCI stanno operando simultaneamente. Questo succede perchè l'invio di una grossa quantità di dati diventa molto meno frequente e il controllo del bus cambia spesso, incrementando l'overhead. Molte distribuzioni Linux includono una suite di tool chiamati pci-utils che permettono di vedere e cambiare il tempo di latenza per i dispositivi PCI. Per vedere i vostri tempi di latenza, eseguite:
Eseguendo questo comando compariranno informazioni molto dettaliate di tutti i vostri dispositivi PCI. I valori dei tempi di latenza di ogni dispositivo sono elencati nella terza riga, prima del valore degli IRQ. Come tutto questo è collegato al mio problema di audio confuso? Avevo audio distorto perchè, per come i tempi di latenza erano impostati, la V550 dominava il bus PCI quando eseguiva accelerazioni 3D. Infatti, la mia V50 è una scheda AGP 2X, cosi quando ho disabilitato AGP (per incrementare la stabilità), avevo ridotto la larghezza di banda alla memoria principale del 75%! Poichè ora la mia V550 stava cercando di pompare la stesa quantità di dati attraverso il bus PCI più lento, il bus era vicino al 100% dell'utilizzo, e questo stava causando i problemi al mio hardware audio. I dispositivi audio sono particolarmente sensibili alla latenza di PCI poichè generalmente hanno un buffer dati piccolo e hanno bisogno che i loro dati vengano trasmessi in tempo per evitare buffer underrun. Con la mia configurazione, la V550 stava usando cosi tanto la larghezza di banda del PCI che non ce ne era abbastanza per i dati della mia scheda audio e il fenomeno dell'audio distorto era causato da buffer underrun. Ci sono due possibili soluzioni a questo problema. La prima e più ovvia soluzione, sarebbe usare il comando setpci per ridurre il tempo di latenza della mia V550. Questa le consentirebbe di condividere il bus PCI più prontamente, permettendo algli altri dispositivi di trasmettere i loro dati con minore latenza. Ho provato questa soluzione usando il comando setpci e funziona. Tuttavia, ho deciso di non seguire questa strada poichè volevo massimizzare le mie prestazioni grafiche 3D già paralizzate senza aggiungere altri ostacoli. Decisi di provare la seconda opzione per aumentare le prestazioni. Invece di ridurre la latenza del bus della V550, ho incrementato la latenza PCI di tutti gli altri dispositivi al valore relartivamente alto di 176 (normalmente i dispositivi hanno un valore di default di circa 32, ad eccetto della mia V550 che di default aveva 200). Dopo ho fissato la latenza dei miei dispositivi sensibili al massimo dei valori possibili, 248. Questo risolse il problema, come speravo, permettendo alla mia scheda video di trasmettere una relativamente grande quantità di dati attraverso il bus in una sola volta, ottimizzando l'uso del bus ed evitando condizioni di buffer underrun. Allo stesso tempo, i miei altri dispositivi possono trasmettere dati in quantità abbastanza piccole senza intasare il bus, ma abbastanza grandi da usare il bus in modo efficiente. Ero particolarmente compiaciuto con questa soluzione perchè risolveva i miei problemi audio mentre allo stesso tempo incrementavo la larghezza di banda effettiva del bus della mia macchina di sviluppo. Qui c'è la parte dello script di startup del mio sistema che implementa la soluzione:
Nella prima riga, l'opzione -d *:* dice a setpci di applicare il comando a tutti i dispositivi PCI. L'opzione latency_timer=b0 fissa il tempo di latenza a 176 (b0 è la notazione esadecimale di 176). L'opzione -s nelle due ultime righe specifica i dispositivi PCI, che saranno interessati dal comando, attraverso il numero dello slot del bus, invece che il nome e l'ID del dispositivo. Il numero dello slot è il primo che compare per ogni dispositivo quando si esegue setpci. Il valore ff indica un tempo di latenza di 256, che viene diminuito a 248 da setpci. Se avete problemi di latenza PCI, dovrete sperimentare con i comandi lspci e setpci per trovare i valori ottimali per il vostro sistema. Se il vostro hardware lo permette, valori alti del tempo di latenza sono i migliori. Spero abbiate trovato il mio problema hardware un buon esempio per imparare. Ora sto pazientemente aspettando la prossima realise dei driver NVIDIA. Speriamo che questi risolvano i problemi legati alla stabilità di AGP. Più sotto troverete molte risorse interessanti che riguardano NVIDIA che potrebbero interessarvi.
Daniel Robbins vive ad Albuquerque, New Mexico (USA). Era presidente/CEO della Gentoo Technologies Inc, Chief Architect del Gentoo Project ed è co-autore di parecchi libri pubblicati da MacMillan: Caldera OpenLinux Unleashed, SuSE Linux Unleashed, and Samba Unleashed. Daniel è stato affascinato dai computer fin dalla seconda elementare, quando fu esposto per la prima volta al linguaggio di programmazione Logo e a una dose letale di PacMan. Questo probabilmente spiega perchè ha lavorato come Lead Graphic Artist alla SONY Electronic Publishing/Psygnosis. Daniel ama passare il suo tempo con sua moglie Mary e la sua bambina Hadassah. Potete contattare Daniel al suo indirizzo mail, Daniel Robbins. |
|