Red Hat Bugzilla – Bug 127327
tar hangs when reading from SCSI tape drive
Last modified: 2008-08-02 19:40:33 EDT
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:
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.
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.
Closed per above message and lack of response. Note that FC2 is not even supported by Fedora Legacy currently.