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:
If this fails, something is wrong.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:
As/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.
The use of themt -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 , 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 will most likely request that you send him the entire Ftape error-log (snipped from your system messages file).
<answer from Tim Jones>