Bug 127327 - tar hangs when reading from SCSI tape drive
Summary: tar hangs when reading from SCSI tape drive
Alias: None
Product: Fedora
Classification: Fedora
Component: tar   
(Show other bugs)
Version: 2
Hardware: i686 Linux
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-06 18:04 UTC by Gerald Bastelica
Modified: 2008-08-02 23:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-25 20:05:01 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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
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- and tar-1.14

How reproducible:

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.

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