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
Steps to Reproduce:
1. tar cf /dev/ht0 /etc
2. tar tf /dev/ht0
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.
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.
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
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
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 firstname.lastname@example.org and email@example.com 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.
firstname.lastname@example.org 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. email@example.com, can you close this issue now that it
appears a solution (and released errata kernels) have been released?