Bug 276 - mt tape positioning commands do not work on my SCSI exabyte tape: Worked under Redhat 5.1
mt tape positioning commands do not work on my SCSI exabyte tape: Worked und...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: mt-st (Show other bugs)
5.2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Preston Brown
:
: 577 691 1085 1245 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1998-12-03 12:13 EST by dhunt
Modified: 2008-05-01 11:37 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-02-19 13:07:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dhunt 1998-12-03 12:13:15 EST
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.
Comment 1 David Lawrence 1998-12-11 12:26:59 EST
This bug has been assigned to a developer for further review.
Comment 2 Preston Brown 1999-02-10 16:48:59 EST
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.
Comment 3 Jeff Johnson 1999-02-19 13:01:59 EST
*** 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@unsw.edu.au)
Thank you,
              Tim Hespe t.hespe@unsw.edu.au

------- Additional Comments From t.hespe@unsw.edu.au  02/08/99 20:36 -------
This was apparently fixed by the maintainer Kai Makisara
(Kai.Makisara@metla.fi) 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@unsw.edu.au)
Comment 4 Jeff Johnson 1999-02-19 13:03:59 EST
*** 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
Comment 5 Jeff Johnson 1999-02-19 13:04:59 EST
*** 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@redhat.com  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@students.cs.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? ;-)
Comment 6 Jeff Johnson 1999-02-19 13:07:59 EST
Raw Hide now has mt-st-0.5b-1. Recompile from the src rpm
if you need this fix on 5.2.
Comment 7 Preston Brown 1999-08-18 10:01:59 EDT
*** 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@redhat.com  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@forum.swarthmore.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@redhat.com  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

Note You need to log in before you can comment on or make changes to this bug.