Always the latest stable version which is _supposed_ to be available from ftp://sunsite.unc.edu/pub/Linux/kernel/tapes and http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/
At time of this writing the latest stable version is ftape-4.02.
<answer from Claus Heine>
The default version of Ftape included in the 2.0.xx kernel sources is 2.08 or 2.09 and is very out of date. Please update the Ftape drivers to the latest from the Ftape Home Page.
<answer from Tim Jones>
You need to add -D__SMP__ to the KERNEL_OPT variable in the
file MCONFIG. In newer ftape versions you only need to
uncomment a certain line in the MCONFIG file.
<answer from Claus Heine>
Ignore the depmod error messages. The problem is that the Ftape modules
have to be compiled without the version checksum feature (i.e.
CONFIG_MODVERSIONS) with 2.0.* kernels. This causes no problem, even
when the modules are used with a kernel that has support for this feature;
only that depmod wrongly complains about undefined symbols. Ignore the
complaints of depmod and try to insert the modules despite of these
complaints:
modprobe zftape
<answer from Claus Heine>
The insmod program can check the kernel version against the
version that Ftape was compiled for in two ways: It can directly
compare the kernel version number recorded in the Ftape module against
the version of the running kernel, or, if both the kernel and
Ftape is compiled with versioned symbols, compare the version of
the used kernel symbols.
If you have upgraded your version of GCC to v2.7.0 or later, you must recompile the modules utilities with gcc v2.7.x.
Newer versions of insmod allows you to "force" insertion of
a module into the kernel, even though the version string is incorrect.
<from the Ftape-Howto>
Did you remember to apply the ksyms.c patch to the kernel? If
not, read the README.linux-1.2 file in the source distribution.
<from the Ftape-Howto>
The modversions.h file is created when the kernel is compiled
with the configuration item CONFIG_MODVERSIONS turned on. With
this option enabled, the file will be created during the make dep
step.
One more handy tip is that a make mrproper will remove
/usr/include/linux/modversions.h. You will need to reconfig
the kernel and do a make dep to get the file back.
<from the Ftape-Howto>
When you say `yes' to CONFIG_MODVERSIONS during `make config',
all the symbols exported by the kernel, i.e: the symbols that the
loadable modules can "see", are augmented to include a checksum
across the types of the call/return parameters. This allows
insmod to detect whether the definition of a variable or function
in the kernel has changed since the time when Ftape was compiled.
This ensures a high degree of safety, such that you do not crash the kernel because you used an outdated module with your kernel.
If you enable CONFIG_MODVERSIONS in the kernel, make sure you have
-DMODVERSIONS -include /usr/include/linux/modversions.huncommented in the MODULE_OPT line in the Ftape Makefile. Conversely, if you do not have CONFIG_MODVERSIONS enabled, make sure you have it commented out.
<from the Ftape-Howto>
There are (at least) two possible sources of the problem:
/lib/modules/misc
instead of
/lib/modules/uname -r/misc
modprobe searches in /lib/modules/misc/ last there might be
an old ftape.o module floating around in /lib/modules/
uname -r/misc which modprobe finds first (uname -r
stands for the kernel version).
Remove the old ftape.o module.CONFIG_FTAPE) and
recompile and install it.<answer from Claus Heins>
You are probably trying to use the same IRQ and DMA settings as your on-board FDC. This does not work in versions of Ftape prior to 3.03b. Please update the Ftape Drivers to the latest from the Ftape Home Page.
<answer from Tim Jones>
Sadly to say there are some SVGA cards and Ethernet cards that do not
decode their addresses correct. This typically happens when the
Ftape buffers are in the range 0x1a0000 to 0x1c0000.
Somehow, the DMA write cycles get clobbered and every other byte
written gets a bad value (0xff). These problems are reported to
happen with both SVGA and Ethernet cards. We know of at least one
(bad?) ATI 16bit VGA card that caused this.
The easiest solution is to put the card in an 8bit slot (it is often not enough to reconfigure the card to 8bit transfers). Moving the Ftape buffer away from the VGA range is only a partial solution; All DMA buffers used in Linux can have this problem! Let us make this one clear: This has nothing to do with the Ftape software.
<from the Ftape-Howto>
You should only see this is you are trying to insmod the
ftape.o module. Try running swapout first. It is provided
with the standalone Ftape source. It doesn't appear in the
Ftape source that's provided with the kernel.
Here's an example of how you can set your rc.local file to use it.
# 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
Please note that you won't have this type of problem if you compile the Ftape driver into the kernel.
<from the Ftape-Howto>
The compile-time options NO_TRACE and NO_TRACE_AT_ALL in Ftape
control the amount of system logging. Add whichever is appropriate to the
FTAPE_OPT line in the Makefile and recompile.
<from the Ftape-Howto>
There are three ways you can do this (in order of personal preference).
While we're at it, here are the meanings of the various trace levels.
/sbin/insmod ftape.o tracing=<tracing-level>
fsr option
in mt to be used to set the tracing level. zftape does not
have this hack.
mt -f /dev/ftape fsr <tracing-level>
fsr command in mt is a hack,
and will probably disappear or change with time.
tracing.c contains a line int tracing = 3;.
Change the 3 to whatever is appropriate and recompile.
<From the Ftape-Howto>
Check the Ftape Home Page. for an even newer version. Then check the FAQ contained in the that package if your problem is listed there. Next, try to check if the manual that comes with the Ftape distribution mentions your problem.
There is no need to read the entire manual, simply check the "Concept Index" if it contains a keyword that might be related to your problem, then jump to the proper location in the manual.
If you are still convinced you've found a bug, then post a general question describing the problem to the Linux-Tape Mailing List , but do not attach your entire Ftape error-log. If we've seen the problem before, we'll let you know where the resolution effort stands. If we haven't, the Ftape maintainer will most likely request that you send him the entire Ftape error-log (snipped from your system messages file).
<answer from Tim Jones>