296 lines
12 KiB
HTML
296 lines
12 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
|
||
|
<HTML>
|
||
|
<HEAD>
|
||
|
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
|
||
|
<TITLE>Ftape-HOWTO: FAQ: "Compiling and installing Ftape" related questions !</TITLE>
|
||
|
<LINK HREF="Ftape-HOWTO-11.html" REL=next>
|
||
|
<LINK HREF="Ftape-HOWTO-9.html" REL=previous>
|
||
|
<LINK HREF="Ftape-HOWTO.html#toc10" REL=contents>
|
||
|
</HEAD>
|
||
|
<BODY>
|
||
|
<A HREF="Ftape-HOWTO-11.html">Next</A>
|
||
|
<A HREF="Ftape-HOWTO-9.html">Previous</A>
|
||
|
<A HREF="Ftape-HOWTO.html#toc10">Contents</A>
|
||
|
<HR>
|
||
|
<H2><A NAME="s10">10. FAQ: "Compiling and installing Ftape" related questions !</A></H2>
|
||
|
|
||
|
<P>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.1">10.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><answer from Claus Heine>
|
||
|
<H2><A NAME="ss10.2">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?</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><answer from Tim Jones>
|
||
|
<H2><A NAME="ss10.3">10.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><answer from Claus Heine>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.4">10.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.* 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><answer from Claus Heine>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.5">10.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><from the Ftape-Howto>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.6">10.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><from the Ftape-Howto>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.7">10.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><from the Ftape-Howto>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.8">10.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><from the Ftape-Howto>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.9">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?</A>
|
||
|
</H2>
|
||
|
|
||
|
<P>
|
||
|
<P>There are (at least) two possible sources of the problem:
|
||
|
<UL>
|
||
|
<LI>All Ftape-3.* 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><answer from Claus Heins>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.10">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.</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><answer from Tim Jones>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.11">10.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><from the Ftape-Howto>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.12">10.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><from the Ftape-Howto>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.13">10.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><from the Ftape-Howto>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.14">10.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=<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 <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><From the Ftape-Howto>
|
||
|
<P>
|
||
|
<H2><A NAME="ss10.15">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?</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><answer from Tim Jones>
|
||
|
<P>
|
||
|
<HR>
|
||
|
<A HREF="Ftape-HOWTO-11.html">Next</A>
|
||
|
<A HREF="Ftape-HOWTO-9.html">Previous</A>
|
||
|
<A HREF="Ftape-HOWTO.html#toc10">Contents</A>
|
||
|
</BODY>
|
||
|
</HTML>
|