Sempre l'ultima versione stabile che si suppone sia disponibile agli indirizzi ftp://sunsite.unc.edu/pub/Linux/kernel/tapes e http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/.
Nel momento in cui sto scrivendo, l'ultima versione stabile è la
ftape-4.02.
<risposta di Claus Heine>
La versione predefinita di Ftape inclusa con i sorgenti del kernel 2.0.xx è la 2.08 o la 2.09 ed è alquanto datata. Si prega di aggiornare i driver di Ftape all'ultima versione disponibile all' home-page di Ftape.
<risposta di Tim Jones>
È necessario aggiungere -D__SMP__ alla variabile KERNEL_OPT
nel file MCONFIG. Nelle versioni di ftape piú aggiornate è
sufficiente togliere il commento ad alcune linee presenti nel file
MCONFIG.
<risposta di Claus Heine>
depmod si lamenta di certi ``undefined symbols'' [simboli indefiniti]?
Si ignorino i messaggi d'errore di depmod. Il problema è che i
moduli di Ftape devono essere compilati senza la caratteristica
del checksum di versione (cioè CONFIG_MODVERSIONS) con i
kernel 2.0.*;. Questo non comporta alcun problema, anche quando i
moduli vengono utilizzati con un kernel che supporta questa
caratteristica; solo che depmod erroneamente si lamenta di certi
simboli indefiniti. Si ignorino le lamentele di depmod e si
provi ad inserire i moduli nonostante queste lamentele:
modprobe zftape
Se non funziona, c'è qualcosa di sbagliato.
<risposta di Claus Heine>
insmod dice che la versione del kernel è sbagliata.
Il programma insmod può confrontare la versione del kernel con la
versione per la quale Ftape è stato compilato in due modi: può
direttamente comparare il numero di versione del kernel registrato nel
modulo di Ftape con la versione del kernel che sta girando,
oppure, se sia il kernel che Ftape sono stati compilati con i
simboli di versione, confrontare la versione dei simboli utilizzati
dal kernel.
Se la versione di GCC è stata aggiornata alla v2.7.0 o successive, è
necessario ricompilare le utility dei moduli con gcc v2.7.x.
Versioni di insmod piú recenti permettono di ``forzare''
l'inserimento di un modulo nel kernel, anche se la stringa di versione
non è corretta.
<dall'Ftape-HOWTO>
insmod dice che kernel 1.2.0 e 1.2.0 differiscono.
Ci si è ricordati di applicare il patch ksyms.c al kernel? Se
non lo si è fatto, leggere il file README.linux-1.2 nella
distribuzione dei sorgenti.
<dall'Ftape-HOWTO>
modversions.h: no such file or directory».
Il file modversions.h viene creato quando il kernel è compilato
con il flag di configurazione CONFIG_MODVERSIONS attivato. Con
questa opzione abilitata, il file verrà creato durante il passo
make dep.
Un consiglio piú pratico: make mrproper rimuoverà
/usr/include/linux/modversions.h. È necessario riconfigurare
il kernel ed impartire un make dep per riottenere il file.
<dall'Ftape-HOWTO>
Rispondendo affermativamente al CONFIG_MODVERSIONS durante il
make config, tutti i simboli esportati dal kernel, cioè i simboli
che i moduli caricabili possono ``vedere'', vengono aumentati per
comprendere una somma di controllo attraverso i tipi dei parametri di
chiamata/ritorno. Ciò permette ad insmod di rilevare se la
definizione di una variabile o funzione nel kernel è cambiata dal
tempo in cui Ftape è stato compilato.
Questo assicura un alto grado di sicurezza, tale da evitare un tracollo del kernel nel caso si utilizzi un modulo vecchio con il proprio kernel.
Se si abilita CONFIG_MODVERSIONS nel kernel, assicurarsi di aver
tolto il commento da
-DMODVERSIONS -include /usr/include/linux/modversions.halla linea
MODULE_OPT nel Makefile di Ftape. Viceversa, se
non si ha CONFIG_MODVERSIONS abilitato, assicurarsi di avere la
linea commentata.
<dall'Ftape-HOWTO>
ftmt status, ottengo una risposta che, nei documenti di Ftape, corrisponde a sftape (/dev/qft0: Invalid argument). Perché?
Ci sono (almeno) due possibili cause a questo problema:
/lib/modules/misc invece di /lib/modules/uname
-r/misc. Poiché modprobe cerca in
/lib/modules/misc/ come ultima risorsa, ci potrebbe essere un
vecchio modulo ftape.o disperso in
/lib/modules/uname -r/misc che
modprobe trova prima (``uname -r'' sta per la versione del
kernel). In questo caso rimuovere il vecchio modulo ftape.o.
CONFIG_FTAPE), ricompilarlo ed installarlo.<risposta Claus Heins>
Probabilmente si sta provando ad utilizzare le stesse impostazioni di IRQ e DMA dell'FDC installato. Ciò non funziona per le versioni di Ftape precedenti alla 3.03b. Si prega di aggiornare il driver di Ftape all'ultima versione disponibile dall' home-page di Ftape.
<risposta di Tim Jones>
Sono spiacente di dover dire che ci sono alcune schede SVGA e schede
Ethernet che non decodificano correttamente i propri indirizzi.
Questo tipicamente accade quando i buffer di Ftape si trovano
nell'intervallo 0x1a0000-0x1c0000. In qualche modo i cicli
di scrittura DMA vengono rovinati ed ogni altro byte scritto ottiene
un valore sbagliato (0xff). Questi problemi si sono avuti sia
con schede SVGA che schede Ethernet. Siamo a conoscenza di almeno una
(cattiva?) scheda VGA ATI 16bit che provoca questo.
La soluzione piú semplice consiste nel mettere la scheda in uno slot ad 8bit (spesso non è abbastanza riconfigurare la scheda per trasferimenti ad 8bit). Spostare il buffer di Ftape lontano dall'intervallo della VGA è solo una soluzione parziale. Tutti i buffer DMA utilizzati in Linux possono avere questo problema! Vorrei che fosse chiaro questo concetto: questo non ha niente a che fare con il software di Ftape.
<dall'Ftape-HOWTO>
dmaalloc() failed'' nel mio file di syslog.
Si dovrebbe vedere questo solo se si sta tentando di eseguire un
insmod con il modulo ftape.o. Provare a lanciare prima
swapout. Viene fornito con i sorgenti di Ftape distribuito
singolarmente. Non compare nei sorgenti di Ftape che vengono
forniti con il kernel.
Qui di seguito è riportato un esempio di come si possa impostare il
file rc.local per un suo utilizzo.
# Install the Floppy Tape Driver
if [ -f /boot/modules/`uname -r`/misc/ftape.o ]; then
echo Installing ftape for Linux `uname -r`
swapout
insmod /boot/modules/`uname -r`/misc/ftape.o
fi
Si noti che questo problema non compare se il driver di Ftape viene compilato nel kernel.
<dall'Ftape-HOWTO>
Le opzioni in fase di compilazione NO_TRACE e
NO_TRACE_AT_ALL in Ftape controllano l'ammontare dei log di
sistema. Aggiungere tutto quello che si ritiene opportuno alla linea
FTAPE_OPT nel Makefile e ricompilare.
<dall'Ftape-HOWTO>
Ci sono tre modi per fare questo (in ordine di preferenza personale). Quando ci arriveremo, qui ci sono i significati dei vari trace-level.
insmod per cambiare trace-level: se si sta
utilizzando il meccanismo dei moduli per caricare il driver di
Ftape, è possibile specificare il trace-level come opzione del
comando insmod.
/sbin/insmod ftape.o tracing=<trace-level>
mt per cambiare trace-level: il driver di
Ftape ha un hack
taglioche permette all'opzione
fsr di mt di venir utilizzata per impostare il trace-level.
zftape non ha questo hack.
mt -f /dev/ftape fsr <trace-level>
fsr in mt è un hack e
probabilmente sparirà o cambierà col tempo.
tracing.c contiene una linea int tracing = 3;. Cambiare il
3 in ciò che si ritiene opportuno e ricompilare.<dall'Ftape-HOWTO>
Controllare l' home-page di Ftape per una versione ancora piú recente. Poi controllare che le FAQ contenute nel pacchetto non riportino il problema riscontrato. Successivamente provare a controllare che il manuale che arriva con la distribuzione di Ftape non menzioni i problema.
Non c'è bisogno di leggere l'intero manuale. Piú semplicemente si cerchi nell'indice analitico una parola che possa riferirsi al proprio problema e leggere il paragrafo relativo.
Se ancora si è convinti di aver trovato un baco, allora postare una domanda di carattere generale che descriva il problema nella mailing-list di Linux-Tape, ma non allegare tutto il log dell'errore di Ftape. Se ci siamo già imbattuti nel problema in passato, faremo sapere dove si trova la soluzione. Se, invece, non lo abbiamo mai visto, il manutentore di Ftape probabilmente richiederà l'intero log d'errore (ottenuto dal proprio file dei messaggi di sistema).
<risposta di Tim Jones>