Debugging the <CODE>ftape</CODE> driver

# 9. Debugging the `ftape` driver

Contents of this section

## 9.1 The kernel/`ftape` crashes on me when I do `...' - is that abug?

No, that is a feature `;‐)`

Seriously, reliable software do not crash. Especially kernels do not or rather should not crash. If the kernel crashes upon you when you are running `ftape`, and you can show that it is `ftape` that is messing things up, regard it as a Bug That Should Be Fixed. Mail the details to Bas (`<bas@vimec.nl>`) and to the tape channel.

## 9.2 OK, it's a bug ...ehhh... feature - How do I submit a report?

First, make sure you can reproduce the problem. Spurious errors are a pain in the ass, since they are just about impossible to hunt down `:-/` This is a quick check list:

- Kernel version, and patches applied
- `ftape` version
- tape drive model / manufacturer
- Expansion bus type (EISA, ISA, PCI, or VL-bus)
- What you did to expose the problem
- What went wrong on your system.
- Do not delete the kernel and the `ftape.o` file. We may want you run try some patches out or run a different test on your system.

Increase the tracing level to 7 (just below maximum tracing) and run the offending command again. Get the tracing data from the kernel log or `/proc/kmsg`, depending on where you harvest your error messages. Try to look at what `ftape` spews out at you. It may look in-comprehensible to you at first, but you can get valuable information from the logfile. Most messages have a function name prepended, to make it easier to locate the problem. Look through the source, don't just cry ``WOLF!'', without giving it a try. If your version of the kernel (or `ftape` for that matter), is ``old'', when compared to the newest version of the kernel, try to get a newer (or even the newest) kernel and see if the problem goes away under the new kernel. When you post your problem report, include the information about ftape version, kernel version, expansion bus type (ISA, VL-bus, PCI or EISA), bus speed, floppy controller, and tape drive. State exactly what you did, and what happened on your system. Some people have experienced that `ftape` would not run in a PCI based box, but ran flawlessly in a normal ISA based 386DX machine (see section Getting PCI motherboards to work with `ftape` on PCI machines above)

Also, please think of the poor souls who actually pay the their Internet access (like me): avoid posting a (huge) log from the `ftape` run, without reason. Instead, you could describe the problem, and offer to send the log to the interested parties.

Send your bug report to `<linux-tape@vger.rutgers.edu>`. You might also want to mail the bug to `<bas@vimec.nl>`.

## 9.3 How do I change the trace-level?

You can do this two ways: either change the default trace-level (the var ``tracing`' in file ``ftape-rw.c`') and recompile or say

> `

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

## 9.4 `ftape` keep saying `... new tape', what do I do?

[You cannot do this anymore; I do not know a way of fixing it]

To get rid of this, do this (blindfold): login as root and say ``rmmod ftape`'. `ftape` should choke a few times, give three segmentation violations (or so), and give up life.

Check the activity LED on your floppy drive (you do have one, don't you?). If it is constantly lit, you have turned the floppy cable upside down somewhere. Check your cable between controller, tape drive and floppy drive. Usually, one (or more) of the connectors have been turned upside down, such that pin 1 in one end connects to pin 34 in the other end. (All the even-numbered pins are grounded, so you wont be able to use your floppy either). Don't worry; this cannot damage your hardware.

Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter