The commands 'mt -f /dev/nst0 fsf 1' and 'mt -f /dev/nst0 bsf 1' seem to be broken since I upgraded to redhat 5.2. These worked find under rh 5.1. In order to get the the fourth tar dump on a tape, instead of: 'mt -f /dev/nst0 rewind' 'mt -f /dev/nst0 fsf 3', I have to do: 'mt -f /dev/nst0 rewind' 'mt -f /dev/nst0 bsfm' 'mt -f /dev/nst0 bsfm' 'mt -f /dev/nst0 bsfm' (!) In order to go backwards, instead of 'bsf', I have to use 'fsfm'. This is all that I can get to work. I have a Dell precision workstation 410 with 2 processors. My tape drive is an exabyte 8500 SCSI-2 8mm drive.
This bug has been assigned to a developer for further review.
please try the mt-st that is currently in rawhide, and report if you are still having the error. We do not have an exabyte tape drive to duplicate this behaviour on, so we need your help.
*** Bug 1085 has been marked as a duplicate of this bug. *** There is a problem in the way mt handles command line arguments. If the "-f device" option is specified, subsequent arguments are mangled such that "count" always becomes 0 or "arguments" are misinterpreted. Here are some examples. (The SCSI tape driver st.c has been compiled with debugging enabled.) (1)Forward space the tape using the norewind device: bash# mt -f /dev/nst0 fsf 1 Detected scsi tape st0 at scsi1, channel 0, id 3, lun 0 st: Buffer size 32768 bytes, write threshold 30720 bytes. st: Allocated tape buffer 0 (32768 bytes, dma: 1, a: 00f98000). st: Allocated tape buffer 1 (32768 bytes, dma: 1, a: 00f90000). st0: Block limits 1 - 16777215 bytes. st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 st0: Density 25, tape length: 0, drv buffer: 1 st0: Block size: 0, buffer size: 32768 (1 blocks). st0: Spacing tape forward over 0 filemarks. st0: arg = 0. Please note: the last displayed line "st0: arg = 0.", from the st driver was added by me, it is not part of the driver as distributed. (2) Set the "debug" argument to the "stoptions" operation while using the "-f" option: bash# mt -f /dev/nst0 stoptions debug Detected scsi tape st0 at scsi1, channel 0, id 3, lun 0 st: Buffer size 32768 bytes, write threshold 30720 bytes. st: Allocated tape buffer 0 (32768 bytes, dma: 1, a: 00f98000). st: Allocated tape buffer 1 (32768 bytes, dma: 1, a: 00f90000). st0: Block limits 1 - 16777215 bytes. st0: Mode sense. Length 11, medium 0, WBS 10, BLL 8 st0: Density 25, tape length: 0, drv buffer: 1 st0: Block size: 0, buffer size: 32768 (1 blocks). Illegal property name '/dev/nst0'. The implemented property names are: buffer-writes -> buffered writes async-writes -> asynchronous writes read-ahead -> read-ahead for fixed block size debug -> debugging (if compiled into driver) two-fms -> write two filemarks when file closed fast-eod -> space directly to eod (and lose file number) auto-lock -> automatically lock/unlock drive door def-writes -> the block size and density are for writes can-bsr -> drive can space backwards well no-blklimits -> drive doesn't support read block limits can-partitions -> drive can handle partitioned tapes scsi2logical -> logical block addresses used with SCSI-2 bash# Here is a possible fix: *** mt.c.orig Sun Apr 12 00:58:25 1998 --- mt.c Mon Feb 8 17:08:10 1999 *************** *** 282,288 **** mtfd = (-1); if (comp->cmd_function != NULL) ! i = comp->cmd_function(mtfd, comp, argc - 2, &(argv [2])); else { fprintf(stderr, "mt: Internal error: command without function.\n"); i = 1; --- 282,288 ---- mtfd = (-1); if (comp->cmd_function != NULL) ! i = comp->cmd_function(mtfd, comp, argc - argn, argv + argn); else { fprintf(stderr, "mt: Internal error: command without function.\n"); i = 1; --------------------------- The author of the fix was Geoff Hort (g.hort.au) Thank you, Tim Hespe t.hespe.au ------- Additional Comments From t.hespe.au 02/08/99 20:36 ------- This was apparently fixed by the maintainer Kai Makisara (Kai.Makisara) on August 15 1998. I would have thought it could have made it into 5.2. This has also been reported before in reports 577 and 691. Neither is flagged as fixed. Tim Hespe (t.hespe.au)
*** Bug 691 has been marked as a duplicate of this bug. *** Problem Report RPM Package: mt-st-0.5-1.rpm Problem: When issuing `mt -f /dev/nst0 fsf 2` command to my scsi tape drive, it wouldn't wind the tape forward. Hardware: SCSI card - Adaptec 1540b using 1542 driver DDS2 Tape Drive - ARCHIVE Python 28454-XXX Rev: 4.44 (Sun) Solution: Went to url below and obtained the latest mt, compiled and installed it. Working fine now. --------------- http://metalab.unc.edu/pub/Linux/system/backup/mt-st- 0.5b.tar.gz Extract from Readme file: Changes in version 0.5b: - corrected the bug that caused the command argument to be ignored if option -f was used - added #include <errno.h> to stinit.c (for glibc) - density 0x45 (TR-4) added to known density list
*** Bug 577 has been marked as a duplicate of this bug. *** After upgrading to RedHat 5.2 (from 4.2) I was no longer able to space the tape backwards with mt -f /dev/nst0 bsf, which I could on RedHat 4.2. Without it verification of written data is hard. The hardware: Adaptec AHA2940 UW HP DAT/8 (C1533A) ------- Additional Comments From dkl 12/30/98 18:00 ------- *** Bug 577 has been marked as a duplicate of this bug. *** The command "mt -f /dev/nst0 fsf 13" does not advance the tape under release 5.2. Similarly "bsf 1" does not work. Work around: 1. Symlink /dev/tape to /dev/nst0 then "mt fsf 13" or 2. Replace /bin/mt of RedHat 5.2 with that of RedHat release 5.1 ------- Additional Comments From borgia.unibo.it 01/05/99 02:10 ------- version 0.5 has a parser bug: Changes in version 0.5b: - corrected the bug that caused the command argument to be ignored if option -f was used - added #include <errno.h> to stinit.c (for glibc) - density 0x45 (TR-4) added to known density list BTW, when I see "bug so and so has been marked a duplicate of this bug"... for which values of "this" is it true? ;-)
Raw Hide now has mt-st-0.5b-1. Recompile from the src rpm if you need this fix on 5.2.
*** Bug 1245 has been marked as a duplicate of this bug. *** mt -f /dev/nst0 fsf 1(2,3,etc) or mt -f /dev/nst0 retension yield no result. the same problem experienced with mt-st versions 0.5-2 and 0.5b-1 downloaded from RawHide-1.0. mt-st version 0.4-5, which is a part of RH 5.1 distribution, does work. my system is as follows - i686 (PII-400) - DPT PM2044UW Ultra Wide SCSI controller - HP C1537A SureStore DDS-3 DAT24 tape drive running stock RH 5.2 with kernel upgraded to 2.0.36-1 ------- Additional Comments From jbj 02/19/99 13:09 ------- Could you please verify (again) that mt-st-0.5b-1 from Raw Hide does not fix your problem? (See bug #276) ------- Additional Comments From sasha.edu 02/19/99 13:38 ------- attempting to recreate the problem with mt-st-0.5b-1: unable to execute mt: # rpm -Uvh mt-st-0.5b-1.i386.rpm mt-st ############################################## # mt -f /dev/nst0 stat mt: error in loading shared libraries : undefined symbol: __register_frame_info # mt mt: error in loading shared libraries : undefined symbol: __register_frame_info i also erroneouly submitted the same bug report as 1247, please disregard thanks ------- Additional Comments From jbj 02/20/99 14:38 ------- *** Bug 1247 has been marked as a duplicate of this bug. *** mt -f /dev/nst0 fsf 1(2,3,etc) or mt -f /dev/nst0 retension yield no result. the same problem experienced with mt-st versions 0.5-2 and 0.5b-1 downloaded from RawHide-1.0. mt-st version 0.4-5, which is a part of RH 5.1 distribution, does work. my system is as follows - i686 (PII-400) - DPT PM2044UW Ultra Wide SCSI controller - HP C1537A SureStore DDS-3 DAT24 tape drive running stock RH 5.2 with kernel upgraded to 2.0.36-1