Questa sezione fornisce un elenco dei problemi in cui la gente incorre comunemente. Se non c'è nulla qui che risponda alle vostre domande, dovreste consultare anche le sezioni che riguardano la vostra scheda di interfaccia SCSI ed i dispositivi che vi stanno procurando dei problemi.
Se vi capitano errori casuali, le cause più probabili sono problemi di cavi e terminazioni.
Alcuni prodotti, come quelli basati sui più recenti chip NCR, sono caratterizzati da filtraggio digitale e negazione attiva del segnale, e non sono molto sensibili ai problemi di cablaggio.
Altri, come Adaptec 154xC, 154xCF, e 274x sono _estremamente_ sensibili ai problemi di cablaggio e di terminazione e possono dare problemi anche con cavi che funzionano con altri sistemi.
Insisto: alcuni adattatori host sono _estremamente_ sensibili ai problemi di cablaggio e di terminazione, quindi cavi e terminatori devono essere le due cose da controllare per prime nel caso in cui insorgano problemi.
Per minimizzare i vostri problemi, dovreste usare cavi che:
La tensione di terminazione dovrebbe essere fornita da tutti i dispositivi sul bus SCSI, tramite un diodo, in modo tale da prevenire cali di corrente, cosicché ci sia sempre potenza sufficiente nella parte terminale dei cavi, laddove è necessaria. Per prevenire danni nel caso in cui il bus vada in corto, TERMPWR dovrebbe essere fatto passare tramite un fusibile o altri dispositivi di limitazione di corrente.
Se vengono utilizzati dispositivi multipli, cavi esterni, o FAST SCSI 2, dovrebbe essere utilizzata su entrambe le estremità del bus SCSI una perfetta terminazione attiva o forzata.
Per ulteriori infomazioni a riguardo della terminazione attiva consultate le FAQ di Comp.Periphs.Scsi (disponibili presso tsx-11 in pub/linux/ALPHA/scsi).
Altre parti del documento si riferiscono ad una ``linea di comandi kernel''.
La linea di comandi kernel è un insieme di opzioni che potete specificare o dal prompt di LILO dopo il nome di un'immagine, o nel campo append nel vostro file di configurazione LILO (in LILO .14 e più recenti, usate /etc/lilo.conf, per versioni più vecchie, usate /etc/lilo/config).
Eseguite un boot del vostro sistema con LILO, e schiacciate uno dei tasti alt, control, o shift quando appare il prompt. LILO dovrebbe rispondere con
:
A questo prompt potete selezionare un'immagine kernel di cui eseguire il boot, od averne un elenco con ?. Ad esempio
:?
ramdisk floppy harddisk
Per eseguire il boot di quel kernel con le opzioni della linea di comando che avete selezionato, semplicemente inserite il nome seguito da una lista di opzioni separate fra loro da spazi bianchi, terminando con invio.
Le opzioni assumono la forma di:
variabile=lista_di_valori
Dove lista_di_valori può essere un singolo valore o una lista di valori separati da virgole senza nessuno spazio bianco. Con l'eccezione del dispositivo di root, valori individuali sono numeri, e possono essere specificati sia in decimale che in esadecimale.
Ad esempio, per eseguire un boot di Linux con un clone Adaptec 1520 non riconosciuto al bootup, potete digitare
:floppy aha152x=0x340,11,7,1
Se non volete digitare tutto questo nel momento del boot, è anche possibile utilizzare l'opzione ``append'' del file di configurazione LILO con LILO .13 e versioni più recenti.
Ad esempio
append="aha152x=0x340,11,7,1"
Se questo è il caso, avete impostato il dispositivo allo stesso indirizzo del controller (solitamente 7, anche se alcune schede usano altri indirizzi: il 6 viene usato da alcune schede di Future Domain.
Cambiate l'impostazione dei jumper.
Il dispositivo ha un firmware difettoso.
Come soluzione temporanea dovreste provare a usare l'opzione della riga di comando kernel:
max_scsi_luns=1
Se funziona c'è una lista di dispositivi difettosi nel sorgente del
kernel, in drivers/scsi/scsi.c nella variabile blacklist (``lista nera'').
Aggiungete il vostro dispositivo alla lista e inviate un messaggio a
Linus Torvalds <Linus.Torvalds@cs.Helsinki.FI>.
Alcune volte questo è causato da cavi scadenti o da terminazioni improprie. Vedete la sezione Malfunzionamento Generale.
Le routine di autorilevamento per molti driver di rete non sono passive, e la loro esecuzione interferisce con alcuni dei driver SCSI.
Un dispositivo SCSI viene individuato dal kernel, ma non siete in grado di accedervi, ad esempio mkfs /dev/sdc, tar xvf /dev/rst2, ecc. non funzionano.
Non avete un file speciale in /dev per il dispositivo.
I dispositivi Unix sono identificati come dispositivi a blocchi (block) o a caratteri (character) (i dispositivi a blocchi passano attraverso un buffer, i dispositivi a carattere no), con un ``numero primario'' (major number) (che identifica il driver che viene utilizzato - block major 8 corrisponde ai dischi SCSI) ed un ``numero secondario'' (minor number) (che corrisponde all'unità resa accessibile tramite un dato driver - ad esempio character major 4, minor 0 è la prima console virtuale, minor 1 la successiva, eccetera). Comunque, l'accedere a questi dispositivi tramite questi nomi sarebbe contrario alla metafora di unix/Linux secondo cui ``tutto è un file'', perciò vengono creati sotto /dev file speciali di dispositivo a blocchi e a caratteri. Questo vi permette di accedere al terzo disco SCSI (nell'insieme, non ad una partizione) con /dev/sdc, alla prima porta seriale come /dev/ttyS0, ecc.
Il metodo preferibile per creare un file è quello di usare MAKEDEV -
andate sulla directory /dev (cd /dev)
ed eseguite MAKEDEV (come root) per i dispositivi che volete creare; ad esempio:
./MAKEDEV sdc
anche i caratteri jolly ``dovrebbero'' funzionare, ad esempio:
./MAKEDEV sd\*
``dovrebbe'' creare tutti i dispositivi di dischi SCSI (facendo questo dovrebbero essere creati i dispositivi da /dev/sda a /dev/sdp, con quindici partizioni ciascuno).
./MAKEDEV sdc\*
``dovrebbe'' creare /dev/sdc e tutte e quindici le partizioni permesse su /dev/sdc, ecc.
Dico ``dovrebbe'' perché questo è il comportamento standard di unix - lo script MAKEDEV nella vostra installazione potrebbe non essere conforme a questo comportamento, o il numero di dispositivi che andrà a creare potrebbe essere minore.
Se MAKEDEV non farà la magia giusta per voi, dovrete creare i file di dispositivo a mano con il comando mknod.
La tipologia blocco/carattere, numeri primari e secondari sono indicati in maniera specifica per i vari dispositivi SCSI nella sezione File di dispositivo.
Prendete quei numeri e usate (come root):
mknod /dev/device b|c major minor
ad esempio:
mknod /dev/sdc b 8 32
mknod /dev/rst0 c 9 0
I motivi possono essere molti. Consultate anche la sezione specifica per il vostro adattatore host per ulteriori possibili soluzioni.
Ci sono casi in cui sembra che il blocco avvenga quando più dispositivi sono in funzione contemporaneamente. In questi casi, potete provare a mettervi in contatto con il produttore dei dispositivi in modo da vedere se ci sono disponibili degli aggiornamenti del firmware in grado di risolvere il problema. Se vi è possibile provate un cavo SCSI diverso, oppure provate su un altro sistema. Può dipendere anche da blocchi difettosi sui dischi, o da un cattivo utilizzo del DMA da parte della scheda madre (per adattatori host che fanno DMA). Ci sono probabilmente molte altre possibili cause che possono portare a problemi del genere.
Qualche volta questi problemi insorgono quando sul bus sono in funzione più dispositivi contemporaneamente. In questo caso, se il vostro driver dell'adattatore host supporta la presenza contemporanea sul bus di più comandi, provate a ridurne il numero a 1 e vedete se ciò porta a dei miglioramenti. Se avete sul bus dispositivi a nastro o lettori CD lenti, quella appena esposta potrebbe non essere una soluzione praticabile.
Driver SCSI inutilizzati occupano memoria, aggravando il problema della mancanza di memoria in sistemi piccoli, dato che la memoria kernel è ``non paginabile''.
La cosa migliore è quindi costruire un kernel ``personalizzato'' per il vostro sistema, con installati solo i driver di cui c'è effettiva necessità.
andate sulla directory /usr/src/linux
Se state utilizzando un dispositivo root diverso da quello corrente, o uno schermo diverso da VGA 80x25, e state scrivendo un floppy per il boot, dovreste editare il makefile, e accertarvi che le righe
ROOT_DEV =
e
SVGA_MODE =
siano come le desiderate.
Se avete installato delle patch, potreste voler essere certi che tutti i file siano ricompilati. In questo caso, dovreste digitare
make mrproper
Sia che abbiate eseguito make mrproper sia che non l'abbiate fatto, digitate
make config
e rispondete alle domande di configurazione. Poi eseguite
make depend
e infine
make
Una volta che la compilazione è completata, potrete aggiornare la configurazione di lilo, o scrivere un floppy di boot. Un disco di boot può essere fatto eseguendo
make zdisk
Molti dispositivi SCSI sono terribilmente difettosi, bloccano il bus SCSI, e causano altri problemi quando tentate di parlar loro a una unità logica il cui numero sia diverso da zero.
Quindi normalmente le versioni recenti del kernel di Linux non individueranno lun diversi da zero. Per modificare questo comportamento, dovete usare l'opzione della riga di comando max_scsi_luns, o ricompilare il kernel con l'opzione CONFIG_SCSI_MULTI_LUN. Solitamente inserirete sulla vostra riga dei comandi LILO:
max_scsi_luns=8
Se dopo aver seguito questo suggerimento i vostri dispositivi multi-LUN non sono ancora individuati correttamente (come può essere il caso di molte vecchie bridge board SCSI->MFM, RLL, ESDI, SMD, e simili), il problema deriva da questa parte di codice:
/* Some scsi-1 peripherals do not handle lun != 0.
I am assuming that scsi-2 peripherals do better */
if((scsi_result[2] & 0x07) == 1 &&
(scsi_result[3] & 0x0f) == 0) break;
che si trova in scan_scsis() in drivers/scsi/scsi.c. Cancellate questo codice e tutto dovrebbe funzionare a dovere.