10. FAQ: "Compiling and installing Ftape" related questions !

10.1 What Ftape version should I use?

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>

10.2 I'm having problems getting my XYZ drive to run under the 2.0.xx kernel with the built-in driver. How do I fix this?

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>

10.3 I'm running Linux/SMP and the system just freezes when trying to access the Ftape devices!

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>

10.4 Why does depmod complain about "undefined symbols"?

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>

10.5 "insmod" says the kernel version is wrong

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>

10.6 "insmod" says that kernel 1.2.0 and 1.2.0 differ

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>

10.7 Trying to compile Ftape gives me the error "modversions.h: no such file or directory"

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>

10.8 What is this versioned symbols stuff anyway?

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.h

<from the Ftape-Howto>

10.9 I seem to be getting sftape instead of zftape. When I run "ftmt status" command, I get output that the Ftape docs says corresponds to sftape ( /dev/qft0: Invalid argument ). Why?

There are (at least) two possible sources of the problem:

• All Ftape-3.* versions prior to 3.04 install the modules into

  /lib/modules/misc
  instead of
  /lib/modules/uname -r/misc
  

  As 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.
• Your kernel has support for Ftape compiled in. Reconfigure your kernel without support for Ftape (CONFIG_FTAPE) and recompile and install it.

<answer from Claus Heins>

10.10 My Ditto DASH/FC-20/Exabyte Accelerator card works under Microsoft Windows, but I get a drive not found type of error in /var/log/messages when trying to use it under Linux.

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>

10.11 Ftape DMA transfers gives ECC errors

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>

10.12 Help! I'm getting 'dmaalloc() failed' in my syslog file.

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>

10.13 Syslogd works overtime when running Ftape

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>

10.14 How do I change the trace-level?

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.

• 0 Bugs
• 1 + Errors
• 2 + Warnings
• 3 + Information
• 4 + More information
• 5 + Program flow
• 6 + FDC/DMA info
• 7 + Data flow
• 8 + Everything else

1. Using insmod to change trace-level If you are using the modules mechanism to load the Ftape driver, you can specify the tracing level as an option to the insmod command.

           /sbin/insmod ftape.o tracing=<tracing-level>
   

2. Using mt to change trace-level The Ftape driver has a hack in it that allows the 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>
   

   The use of the fsr command in mt is a hack, and will probably disappear or change with time.
3. Recompiling to change trace-level The file tracing.c contains a line int tracing = 3;. Change the 3 to whatever is appropriate and recompile.

<From the Ftape-Howto>

10.15 I'm having problems with Ftape. I'm using the latest version of Ftape from the Ftape Home Page and believe that I've located a real bug. What should I do?

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>