Bug 127327

Summary: tar hangs when reading from SCSI tape drive
Product: [Fedora] Fedora Reporter: Gerald Bastelica <ggnoos>
Component: tarAssignee: Peter Vrabec <pvrabec>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: mattdm
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-25 20:05:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Gerald Bastelica 2004-07-06 18:04:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
I need to read/write tar DLT tapes from a SCSI drive. mt command works
well: i can setblk, get status, fsf, rewind, tell... But when trying
any kind of tar command (-tvf, -cvf, -xvf), nothing happen, the
command simply hangs, and trying to CTRL+C or kill it, nothing happen
during a long time (some minutes).

I've tried two very different computers:
- One is an Intergraph GT1 with PII processor, symbios SCSI
controllers, SCSI hardrives and CDROM and serverworks chipset
- The other is an Intel motherboard with PIV processor, Intel 875
chipset and ide hard drives and CDROM, and an Adaptec 2940 SCSI adapter.
So i believe this is not and hardware related issue.

I've also tried to yum -update everything including kernel
2.6.6-1.435.2.3. I also downloaded and compiled tar v1.14 from gnu.org.

In addition, on exactly the same configurations, using Red Hat 9, it
works !

In dmesg i can see:

SCSI subsystem initialized
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36
        <Adaptec 2940 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
 
(scsi0:A:5): 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
  Vendor: HP        Model: Ultrium 1-SCSI    Rev: E21V
  Type:   Sequential-Access                  ANSI SCSI revision: 03
(scsi0:A:8): 20.000MB/s transfers (10.000MHz, offset 8, 16bit)
  Vendor: TANDBERG  Model: DLT8000           Rev: 011A
  Type:   Sequential-Access                  ANSI SCSI revision: 02
Attached scsi tape st1 at scsi0, channel 0, id 8, lun 0
st1: try direct i/o: yes (alignment 512 B), max page reachable by HBA
1048575
st1: Block limits 2 - 16777214 bytes.
Attached scsi generic sg0 at scsi0, channel 0, id 5, lun 0,  type 1
Attached scsi generic sg1 at scsi0, channel 0, id 8, lun 0,  type 1
kudzu: Using deprecated /dev/sg mechanism instead of SG_IO on the
actual device
kudzu: Using deprecated /dev/sg mechanism instead of SG_IO on the
actual device
python: Using deprecated /dev/sg mechanism instead of SG_IO on the
actual devicepython: Using deprecated /dev/sg mechanism instead of
SG_IO on the actual device

You can see also an Ultrium tape drive, but i've also tested without it.

After waiting a long time after i have launch tar, i can see:
(scsi0:A:8:0): Unexpected busfree in Command phase
SEQADDR == 0x156
st1: Error 70000 (sugg. bt 0x0, driver bt 0x0, host bt 0x7).

and tar says:
tar: /dev/nst1: ne peut read: Erreur d'entr�e/sortie
tar: Au d�but du ruban, fin pr�matur�e.
tar: Erreur non r�cup�rable: fin de l'ex�cution imm�diate








Version-Release number of selected component (if applicable):
tar-1.13.25.14 and tar-1.14

How reproducible:
Always

Steps to Reproduce:
1. mt -f /dev/nst1 setblk 262144 (it can be st0, or a smaller block
size, even standard 10240)
2. tar -tvf /dev/nst1

    

Actual Results:  Tar hangs a long time and fails when SCSI bus free
(timeout ?).

Additional info:

Comment 1 Need Real Name 2004-08-31 10:15:54 UTC
I have seen this behaviour too, on an IDE tape with SCSI emulation,
and using dump instead of tar. The console still responds, but disk
access does not work (i.e. no way to log in). Also, I can't ping the
computer from the network.

Kernel version is 2.6.8-1.521.

Comment 2 Matthew Miller 2005-04-26 15:02:58 UTC
Fedora Core 2 is now maintained by the Fedora Legacy project for
security updates only. If this problem is a security issue, please
reopen and reassign to the Fedora Legacy product. If it is not a
security issue and hasn't been resolved in the current FC3 updates or
in the FC4 test release, reopen and change the version to match.

Comment 3 John Thacker 2006-10-25 20:05:01 UTC
Closed per above message and lack of response.  Note that FC2 is not even
supported by Fedora Legacy currently.