From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) tar , bru allow creation of backup tape files but get an I/O error pc=8 key=5 asc=2c ascq=0 when trying to read tape. tape can be read from any 2.2 kernel Reproducible: Always Steps to Reproduce: 1. tar cf /dev/ht0 /etc 2. tar tf /dev/ht0 3. Actual Results: Error described in Description Expected Results: Listing of tape tar file error is as follows on a valid tar file tar tf /dev/ht0 ide-tape: ht0: I/O error, pc=8, key=5, asc=2c, ascq=0 tar: /dev/ht0: Cannot read: Input/output error tar: At beginning of tape, quitting now tar: Error is not recoverable: exiting now
What SCSI controller is this tapedrive connected to ?
tape drive is connected as a master to a standard ide1 - running on a va 503+ MB 128 MB ram - amd k6-II 450 cpu. error remains when on ide0 as slave or ide1 as slave.
Doh :) What IDE controller / motherboard is this ? (or just paste the output of dmesg )
Created attachment 15744 [details] Listing of dmesg
Could you try booting with "ide=nodma" on the lilo commandline ? 7.0 didn't enable DMA, 7.1 does and if there is something wrong there this should make it work again.
Created attachment 15745 [details] dmesg with ide=nodma - same error
I have a very similar problem as this (bug 36628). In addition my system freezes and requires power cycling/re-boot to recover. I'm using a Gateway select 650 w/ AMD K6/650MHz processor and 256 MB memory. An HP Colorado 5GB tape drive on IDE:1.1 (slave), IDE:1.0 is cdrom (master). The following is "mt" command output. # mt -f /dev/ht0 stat SCSI 2 tape drive: File number=0, block number=0, partition=0. Tape block size 512 bytes. Density code 0x0 (default). Soft error count since last status=0 General status bits on (0): If I try to "tar" or "dump" to this device the system locks up. I can "echo hello > /dev/ht0" and it seems to work (tape moves, etc.), but if I try to "cat /dev/ht0" I get the following error. cat: /dev/ht0: Input/output error. It seems any attempt to read the device fails. Thanks, Dale Wisard
I have the same proble with Exabyte TR4 IDE tape drive on channel 2 as slave. tar cvf /dev/ht0 /etc works fine. Tape spins and files are listed. But tar tf /dev/ht0 Return nothing. Also dump -0 -f /dev/ht0 /home Runs, dumps, and reports no errors. But restore -f /dev/ht0 Results in 'Tape read error: Success'!!!
Priority of this bug should be HIGH since it breaks backup system, preventing migration to 7.1 for production.
I have the same problem. I have tryed a Segate IDE Travan and a HP SCSI Travan. I cannot dd ; tar or cpio to the drive. It seems to write but cannot get a full read. I get a premature end of archive. This is a very high Priority. I cannot get good backups.
This is the same problem as bug# 38404. Please review comments and merge the two problems.
I have noticed that the ide-tape driver does not act like a char device, but as a block device. If you write or read Multiples of the tape devices buffer size, all is ok. But if you read anything that is either a multiple of the block size and 1 byte (or 512 or 1k), you get a read error, and the data is not returned. If you uyse the ide-scsi module and access the tape as an st? device it works like a good char device.
This issue exists with Fairfax Beta3. I will test if anything has changed in Fairfax RC1.
We think this may well be fixed in Roswell2 -- we pulled a fix from the 2.2 kernel into 2.4 that might be related. Please do test, thanks.
With Fairfax, /dev/ht0 can't be used. Trying to tar to /dev/ht0 generates an error message stating 'device /dev/ht0 can't be open' or something to that nature. This forces users to use /dev/st0 device with ide-scsi driver.
Pete, can you try to reproduce this with your tape drive? The previous patch does not appear to have fixed everything.
Nope, my TR5 works great. The problem is generic to Linux, I am getting many reports from linux-kernel. Apparently, I was the lust guy who looked into the driver, so the community turned to me, duh... Stay tuned.
Mark, can you send us one of the offending tape drives? Unless it is a TR5, in which case it's a more specific problem that might have to do with the IDE chipset or something like that.
Created attachment 32818 [details] May be the fix
What jcyr and joel report has nothing to do with the bug. Fortunately, I can reproduce that one. It also may be related to what Mark mentions, with exception. I think it is not possible to read less than a basic block of 512 bytes, but certainly, you ought to be able to read less than the buffer size, in multiplies of 512. Opening a new one for them in a moment. tesfamariam_michael reports yet another problem, which happens when opening for WRITE, not READ (as far as I can tell: he neglected to attach the command and its output). I DO NOT ACCEPT FALSE DUPLICATES FOR THIS BUG.
Rawhide kernel version linux-2.4.9-4.1. Will push upstream.
Trimming the cc: list. jim, can you close this issue now that it appears a solution (and released errata kernels) have been released?