I am using redhat 5.0, kernel 2.0.32, and ftape 4.02 A combination of errors can cause the ftape modules to lock themselves into memory, and then the modules cannot be unloaded without rebooting. I have suspected this bug ever since I first started using ftape 4.02, but only recently I have I found a way to reproduce it consistently: #!/bin/bash echo make sure there is no tape in the drive and press enter read REPLY insmod /lib/modules/2.0.32/ftape-4.02/ftape.o insmod /lib/modules/2.0.32/ftape-4.02/zftape.o insmod /lib/modules/2.0.32/ftape-4.02/ftape-internal.o mt -f /dev/nqft0 setblk 1024 mt -f /dev/nqft0 fsf 1 echo insert a blank tape and press enter read REPLY mt -f /dev/nqft0 fsf 1 mt -f /dev/nqft0 setblk 10240 ftmt -f /dev/nqft0 reset rmmod ftape-internal rmmod zftape rmmod ftape exit If you try to run the script, you may need to change the paths for the modules, and maybe change the device or add IO address or IRQ parameters. The script triggers the bug with two errors: it tries to move the tape forward when there is no tape in the drive, and then it tries to move the tape forward to the next data when there is no data on the tape. Module ftape-internal unloads successfully, but modules zftape and ftape fail to unload; this is the same as what happens if I change the block size and do not change it back to 10240. The script is two bugs in one: the errors should not lock the ftape modules into memory, and ftmt reset should fix the error, but does not. After running the script, I have used ps to see if there is some zombie tar process or something still using the tape drive. ps shows nothing that should be using the tape. If the two mt setblk commands are removed from the script, there is a 25% to 50% chance the modules will fail to unload; failure is more likely if it is tested soon after turning on the computer, before doing anything else with the tape drive. This might or might not be related to my unusual hardware, or might be a hardware bug: I have a CMD 640 VL bus IDE/floppy controller (which is rumored to be buggy), with an Exabyte tape controller sharing IRQ and DMA. I have installed ftape's floppy driver patch, which might not have been intended for the CMD 640 floppy controller, or for the CMD 640 enhanced IDE driver. This might or might not be related to another bug: I cannot format floppy disks under linux. However, the floppy driver is usually not loaded when I use ftape, so floppy drive issues are probably irrelevant. Note that I am not using the latest version of ftape, and I am not using the latest kernel either. I do not know if this bug affects the latest version of ftape. This bug is not important for two reasons: Since it is triggered by a combination of errors, it never occurs during normal, error-free operation. The only time it affects me is when I am testing messed-up backup scripts. Second, this bug has no affect on normal tape operations. Even though module zftape does not unload, I can still reload module ftape-internal and read and write the tape drive normally. If you are loading modules automatically, you would probably never notice if the modules did not unload. Since this bug does not cause any real trouble, I do not need a solution; and I am not expecting any replies to this message. But if anyone is thinking about ever doing any more work on ftape, then they might want to save this information and look into this. I could recompile ftape with full tracing and get more information about this bug, if anyone cares.
