<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
 <TITLE>The Ftape-FAQ: "Compiling and installing Ftape" related questions !</TITLE>
 <LINK HREF="Ftape-FAQ-3.html" REL=next>
 <LINK HREF="Ftape-FAQ-1.html" REL=previous>
 <LINK HREF="Ftape-FAQ.html#toc2" REL=contents>
</HEAD>
<BODY>
<A HREF="Ftape-FAQ-3.html"><IMG SRC="next.gif" ALT="Next"></A>
<A HREF="Ftape-FAQ-1.html"><IMG SRC="prev.gif" ALT="Previous"></A>
<A HREF="Ftape-FAQ.html#toc2"><IMG SRC="toc.gif" ALT="Contents"></A>
<HR>
<H2><A NAME="s2">2. "Compiling and installing Ftape" related questions !</A></H2>

<P>
<P>
<H2><A NAME="ss2.1">2.1 What Ftape version should I use?</A>
</H2>

<P>
<P>Always the latest stable version which is _supposed_ to be available from
<A HREF="ftp://sunsite.unc.edu/pub/Linux/kernel/tapes">ftp://sunsite.unc.edu/pub/Linux/kernel/tapes</A>
and
<A HREF="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/">http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/</A><P>At time of this writing the latest stable version is <CODE>ftape-4.02</CODE>.
<P>&lt;answer from Claus Heine&gt;
<H2><A NAME="ss2.2">2.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?</A>
</H2>

<P>
<P>The default version of <EM>Ftape</EM> included in the 2.0.xx kernel sources is   
2.08 or 2.09 and is very out of date.  Please update the <EM>Ftape drivers</EM>   
to the latest from the 
<A HREF="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/">Ftape Home Page</A>.
<P>&lt;answer from Tim Jones&gt;
<H2><A NAME="ss2.3">2.3 I'm running Linux/SMP and the system just freezes when trying to access the Ftape devices!</A>
</H2>

<P>
<P>You need to add <CODE>-D__SMP__</CODE> to the <CODE>KERNEL_OPT</CODE> variable in the
file <CODE>MCONFIG</CODE>. In newer <CODE>ftape</CODE> versions you only need to
uncomment a certain line in the <CODE>MCONFIG</CODE> file.
<P>&lt;answer from Claus Heine&gt;
<P>
<H2><A NAME="ss2.4">2.4 Why does depmod complain about "undefined symbols"?</A>
</H2>

<P>
<P>Ignore the depmod error messages. The problem is that the <EM>Ftape modules</EM>   
have to be compiled without the version checksum feature (i.e.   
<CODE>CONFIG_MODVERSIONS</CODE>) with 2.0.&ast; kernels. This causes no problem, even   
when the modules are used with a kernel that has support for this feature;   
only that <CODE>depmod</CODE> wrongly complains about undefined symbols. Ignore the   
complaints of <CODE>depmod</CODE> and try to insert the modules despite of these   
complaints: 
<BLOCKQUOTE><CODE>
<PRE>
modprobe zftape
</PRE>
</CODE></BLOCKQUOTE>

If this fails, something is wrong.
<P>&lt;answer from Claus Heine&gt;
<P>
<H2><A NAME="ss2.5">2.5 "insmod" says the kernel version is wrong</A>
</H2>

<P>
<P>The <CODE>insmod</CODE> program can check the kernel version against the
version that <EM>Ftape</EM> was compiled for in two ways: It can directly
compare the kernel version number recorded in the <EM>Ftape module</EM> against
the version of the running kernel, or, if both the kernel and
<EM>Ftape</EM> is compiled with versioned symbols, compare the version of
the used kernel symbols.
<P>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.
<P>Newer versions of <CODE>insmod</CODE> allows you to "force" insertion of
a module into the kernel, even though the version string is incorrect.
<P>&lt;from the Ftape-Howto&gt;
<P>
<H2><A NAME="ss2.6">2.6 "insmod" says that kernel 1.2.0 and 1.2.0 differ</A>
</H2>

<P>
<P>Did you remember to apply the <CODE>ksyms.c</CODE> patch to the kernel?  If
not, read the <CODE>README.linux-1.2</CODE> file in the source distribution.
<P>&lt;from the Ftape-Howto&gt;
<P>
<H2><A NAME="ss2.7">2.7 Trying to compile Ftape gives me the error "modversions.h: no such file or directory"</A>
</H2>

<P>
<P>The <CODE>modversions.h</CODE> file is created when the kernel is compiled  
with the configuration item <CODE>CONFIG_MODVERSIONS</CODE> turned on.  With  
this option enabled, the file will be created during the <CODE>make dep</CODE>  
step.
<P>One more handy tip is that a <CODE>make mrproper</CODE> will remove  
<CODE>/usr/include/linux/modversions.h</CODE>.  You will need to reconfig  
the kernel and do a <CODE>make dep</CODE> to get the file back.  
<P>&lt;from the Ftape-Howto&gt;
<P>
<H2><A NAME="ss2.8">2.8 What is this versioned symbols stuff anyway?</A>
</H2>

<P>
<P>When you say `yes' to <CODE>CONFIG_MODVERSIONS</CODE> during `<CODE>make config</CODE>',  
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  
<CODE>insmod</CODE> to detect whether the definition of a variable or function  
in the kernel has changed since the time when <EM>Ftape</EM> was compiled.
<P>This ensures a high degree of safety, such that you do not crash the  
kernel because you used an outdated module with your kernel.
<P>If you enable <CODE>CONFIG_MODVERSIONS</CODE> in the kernel, make sure you have  
<PRE>
-DMODVERSIONS -include /usr/include/linux/modversions.h
</PRE>

uncommented in the MODULE_OPT line in the <EM>Ftape</EM> Makefile.  Conversely,   
if you do not have CONFIG_MODVERSIONS enabled, make sure you have it  
commented out.
<P>&lt;from the Ftape-Howto&gt;
<P>
<H2><A NAME="ss2.9">2.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?</A>
</H2>

<P>
<P>There are (at least) two possible sources of the problem:
<UL>
<LI>All Ftape-3.&ast; versions prior to 3.04 install the modules into
<BLOCKQUOTE><CODE>
<PRE>
/lib/modules/misc
instead of
/lib/modules/uname -r/misc
</PRE>
</CODE></BLOCKQUOTE>

As <CODE>modprobe</CODE> searches in <CODE>/lib/modules/misc/</CODE> last there might be   
an old <CODE>ftape.o</CODE> module floating around in <CODE>/lib/modules/</CODE><EM>  
uname -r</EM><CODE>/misc</CODE> which <CODE>modprobe</CODE> finds first (<CODE>uname -r</CODE>   
stands for the kernel version).
Remove the old <CODE>ftape.o</CODE> module.</LI>
<LI>Your kernel has support for <EM>Ftape</EM> compiled in. Reconfigure  
your kernel without support for <EM>Ftape</EM> (<CODE>CONFIG_FTAPE</CODE>) and  
recompile and install it.</LI>
</UL>
<P>&lt;answer from Claus Heins&gt;
<P>
<H2><A NAME="ss2.10">2.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.</A>
</H2>

<P>
<P>You are probably trying to use the same IRQ and DMA settings as your on-board  
FDC. This does not work in versions of <EM>Ftape</EM> prior to 3.03b. Please   
update the <EM>Ftape Drivers</EM> to the latest from the
<A HREF="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/">Ftape Home Page</A>.
<P>&lt;answer from Tim Jones&gt;
<P>
<H2><A NAME="ss2.11">2.11 Ftape DMA transfers gives ECC errors</A>
</H2>

<P>
<P>Sadly to say there are some SVGA cards and Ethernet cards that do not
decode their addresses correct.  This typically happens when the
<EM>Ftape</EM> buffers are in the range <CODE>0x1a0000</CODE> to <CODE>0x1c0000</CODE>.
Somehow, the DMA write cycles get clobbered and every other byte
written gets a bad value (<CODE>0xff</CODE>).  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.
<P>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
<EM>Ftape</EM> 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 <EM>Ftape</EM>
software.
<P>&lt;from the Ftape-Howto&gt;
<P>
<H2><A NAME="ss2.12">2.12 Help! I'm getting 'dmaalloc() failed' in my syslog file.</A>
</H2>

<P>
<P>You should only see this is you are trying to <CODE>insmod</CODE> the
<CODE>ftape.o</CODE> module.  Try running <CODE>swapout</CODE> first.  It is provided
with the standalone <EM>Ftape</EM> source.  It doesn't appear in the
<EM>Ftape</EM> source that's provided with the kernel.
<P>Here's an example of how you can set your rc.local file to use it.
<P>
<BLOCKQUOTE><CODE>
<PRE>
# 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
</PRE>
</CODE></BLOCKQUOTE>
<P>Please note that you won't have this type of problem if you compile
the <EM>Ftape driver</EM> into the kernel.
<P>&lt;from the Ftape-Howto&gt;
<P>
<H2><A NAME="ss2.13">2.13 Syslogd works overtime when running Ftape</A>
</H2>

<P>
<P>The compile-time options <CODE>NO_TRACE</CODE> and <CODE>NO_TRACE_AT_ALL</CODE> in <EM>Ftape</EM>  
control the amount of system logging.  Add whichever is appropriate to the
<CODE>FTAPE_OPT</CODE> line in the Makefile and recompile.
<P>&lt;from the Ftape-Howto&gt;
<P>
<H2><A NAME="ss2.14">2.14 How do I change the trace-level?</A>
</H2>

<P>
<P>There are three ways you can do this (in order of personal
preference).
<P>While we're at it, here are the meanings of the various trace levels.
<P>
<UL>
<LI>0 Bugs  </LI>
<LI>1 + Errors  </LI>
<LI>2 + Warnings  </LI>
<LI>3 + Information  </LI>
<LI>4 + More information  </LI>
<LI>5 + Program flow  </LI>
<LI>6 + FDC/DMA info  </LI>
<LI>7 + Data flow  </LI>
<LI>8 + Everything else  </LI>
</UL>
<P>
<OL>
<LI>Using insmod to change trace-level

If you are using the modules mechanism to load the <EM>Ftape</EM>  
driver, you can specify the tracing level as an option to the insmod  
command.
<BLOCKQUOTE><CODE>
<PRE>
        /sbin/insmod ftape.o tracing=&lt;tracing-level>
</PRE>
</CODE></BLOCKQUOTE>
</LI>
<LI>Using mt to change trace-level

The <EM>Ftape</EM> driver has a hack in it that allows the <CODE>fsr</CODE> option  
in <CODE>mt</CODE> to be used to set the tracing level.  <CODE>zftape</CODE> does not  
have this hack.
<BLOCKQUOTE><CODE>
<PRE>
        mt -f /dev/ftape fsr &lt;tracing-level>
</PRE>
</CODE></BLOCKQUOTE>

The use of the <CODE>fsr</CODE> command in <CODE>mt</CODE> is a <EM>hack</EM>,  
and will probably disappear or change with time.
</LI>
<LI>Recompiling to change trace-level

The file <CODE>tracing.c</CODE> contains a line <CODE>int tracing = 3;</CODE>.  
Change the 3 to whatever is appropriate and recompile.
</LI>
</OL>
<P>&lt;From the Ftape-Howto&gt;
<P>
<H2><A NAME="ss2.15">2.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?</A>
</H2>

<P>
<P>Check the 
<A HREF="http://www-math.math.rwth-aachen.de/~LBFM/claus/ftape/">Ftape Home Page</A>.
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 <EM>Ftape distribution</EM> mentions your problem.
<P>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.
<P>If you are still convinced you've found a bug, then post a general question   
describing the problem to the 
<A HREF="mailto:linux-tape@vger.rutgers.edu">Linux-Tape Mailing List</A>
, but do not attach your entire <EM>Ftape</EM> error-log. If we've seen the   
problem before, we'll let you know where the resolution effort stands.  If   
we haven't, the 
<A HREF="mailto:heine@math1.rwth-aachen.de">Ftape maintainer</A>
will most likely request that you send him the entire <EM>Ftape</EM> error-log  
(snipped from your system messages file).
<P>&lt;answer from Tim Jones&gt;
<P>
<HR>
<A HREF="Ftape-FAQ-3.html"><IMG SRC="next.gif" ALT="Next"></A>
<A HREF="Ftape-FAQ-1.html"><IMG SRC="prev.gif" ALT="Previous"></A>
<A HREF="Ftape-FAQ.html#toc2"><IMG SRC="toc.gif" ALT="Contents"></A>
</BODY>
</HTML>
