Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 84843

Summary: mt does not know density code for SDLT-320
Product: [Retired] Red Hat Linux Reporter: Jason Tibbitts <tibbs>
Component: mt-stAssignee: Ngo Than <than>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: low Docs Contact:
Priority: low    
Version: 8.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-02-22 20:00:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jason Tibbitts 2003-02-21 23:09:54 UTC
Wow, this is almost the same bug I reported a year ago, except this time it's a
slightly different tape drive.

I have a Quantum SDLT-320 drive.  mt does not know the density code for the
drive in 160GB naitive mode:

> mt -f /dev/nst1 stat
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x49 (no translation).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

I downloaded mt-st-0.7-8.src.rpm from Rawhide and rebuilt it on this machine; it
doesn't know the code either.

The following patch does the trick:

--- mt.c.orig   Fri Feb 21 17:01:05 2003
+++ mt.c        Fri Feb 21 17:01:16 2003
@@ -221,6 +221,7 @@
     {0x45, "QIC-3095-MC (TR-4)"},
     {0x47, "TR-5"},
     {0x48, "Quantum SDLT220"},
+    {0x49, "Quantum SDLT320"},
     {0x80, "DLT 15GB uncomp. or Ecrix"},
     {0x81, "DLT 15GB compressed"},
     {0x82, "DLT 20GB uncompressed"},

Comment 1 Ngo Than 2003-02-22 20:00:55 UTC
mt-st-0.7-9 has this fix. Thank you for the fix.