Bug 243568 - unable to access ide tape drive
unable to access ide tape drive
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
9
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-09 17:21 EDT by Craig Goodyear
Modified: 2009-07-15 04:16 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-15 04:16:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
the output from dmesg and smolt (31.24 KB, text/plain)
2007-06-09 17:21 EDT, Craig Goodyear
no flags Details
output from "strace -tt mt -f /dev/nst0 status" (2.42 KB, text/plain)
2007-07-24 16:31 EDT, Craig Goodyear
no flags Details
Describes the hardware (1.32 KB, application/octet-stream)
2007-08-10 23:03 EDT, Kelly-Rand
no flags Details
strace output for working session in Fc6 (2.57 KB, text/plain)
2007-08-10 23:05 EDT, Kelly-Rand
no flags Details
strace output from nonworking F7 session (2.30 KB, text/plain)
2007-08-10 23:06 EDT, Kelly-Rand
no flags Details
dmesg output relative to the Seagate STT8000A tape drive (346 bytes, text/plain)
2007-08-10 23:09 EDT, Kelly-Rand
no flags Details
describes the hardware (1.32 KB, text/plain)
2007-08-15 22:09 EDT, Kelly-Rand
no flags Details
kernel messages w/ tape as master (7.28 KB, text/plain)
2007-08-29 18:36 EDT, Craig Goodyear
no flags Details
IDE Tape Error with FC7 (5.73 KB, text/plain)
2007-09-23 11:32 EDT, ronsteiner
no flags Details
strace output Post kernel-2.6.23.12-52.fc7 with libata enabled (16.34 KB, text/plain)
2008-01-13 14:46 EST, Kelly-Rand
no flags Details

  None (edit)
Description Craig Goodyear 2007-06-09 17:21:13 EDT
Description of problem:
Any attempt to use the ide tape drive rewults in the 
error: Input/output error

Version-Release number of selected component (if applicable):
kernel 2.6.21-1.3194.fc7
tar 1.15.1-26.fc7
mt 0.9b-3.fc7

How reproducible:
every time

Steps to Reproduce:
1. try to tar a file to the tape drive
or
2. try to use mt commands on tape drive


Actual results:
[root@itox data]# tar -cf /dev/nst0 cube
tar: /dev/nst0: Cannot open: Input/output error
tar: Error is not recoverable: exiting now

[root@itox data]# mt -f /dev/nst0 status
/dev/nst0: Input/output error


Expected results:
The file would be written to the drive.

Additional info:
In previous FC versions I would use ide-scsi for ide tape 
access, but this module isn't included with the current
kernel.

I have attached the output from dmesg and smolt.
Comment 1 Craig Goodyear 2007-06-09 17:21:13 EDT
Created attachment 156658 [details]
the output from dmesg and smolt
Comment 2 Chuck Ebbert 2007-07-23 12:37:59 EDT
Apparently there is no equivalent of ide-scsi available for the new
PATA drivers.
Comment 3 Alan Cox 2007-07-23 13:15:56 EDT
Nothing to do with the bug report Chuck - st handles tape drives
Comment 4 Chuck Ebbert 2007-07-23 14:59:24 EDT
Does the device file /dev/nst0 exist?
Comment 5 Craig Goodyear 2007-07-23 15:44:38 EDT
The device file /dev/nst0 does exist, as does /dev/st0.
Comment 6 Chuck Ebbert 2007-07-23 15:50:04 EDT
(In reply to comment #5)
> The device file /dev/nst0 does exist, as does /dev/st0.

Can you post output from:

  strace -tt mt -f /dev/nst0 status

Comment 7 Doug Durning 2007-07-23 16:02:34 EDT
Here's output from "strace -tt mt -f /dev/nst0 status"

15:01:34.116349 execve("/bin/mt", ["mt", "-f", "/dev/nst0", "status"], [/* 32
vars */]) = 0
15:01:34.118473 brk(0)                  = 0x9a7a000
15:01:34.119164 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd2000
15:01:34.119980 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
directory)
15:01:34.120720 open("/etc/ld.so.cache", O_RDONLY) = 3
15:01:34.121469 fstat64(3, {st_mode=S_IFREG|0644, st_size=122075, ...}) = 0
15:01:34.122260 mmap2(NULL, 122075, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fb4000
15:01:34.122925 close(3)                = 0
15:01:34.123625 open("/lib/i686/nosegneg/libc.so.6", O_RDONLY) = 3
15:01:34.124352 read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320p\21"..., 512) = 512
15:01:34.125112 fstat64(3, {st_mode=S_IFREG|0755, st_size=1686036, ...}) = 0
15:01:34.125870 mmap2(0x101000, 1406416, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x101000
15:01:34.126528 mmap2(0x253000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x151) = 0x253000
15:01:34.127274 mmap2(0x256000, 9680, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x256000
15:01:34.127966 close(3)                = 0
15:01:34.128681 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fb3000
15:01:34.129382 set_thread_area({entry_number:-1 -> 6, base_addr:0xb7fb36c0,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
15:01:34.130213 mprotect(0x253000, 8192, PROT_READ) = 0
15:01:34.130843 mprotect(0xcdf000, 4096, PROT_READ) = 0
15:01:34.131571 munmap(0xb7fb4000, 122075) = 0
15:01:34.132388 open("/dev/nst0", O_RDONLY|O_NONBLOCK) = -1 EIO (Input/output error)
15:01:45.841694 dup(2)                  = 3
15:01:45.842679 fcntl64(3, F_GETFL)     = 0x8002 (flags O_RDWR|O_LARGEFILE)
15:01:45.843999 brk(0)                  = 0x9a7a000
15:01:45.844871 brk(0x9a9b000)          = 0x9a9b000
15:01:45.846008 fstat64(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
15:01:45.847313 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fd1000
15:01:45.848138 _llseek(3, 0, 0xbfc7bf84, SEEK_CUR) = -1 ESPIPE (Illegal seek)
15:01:45.849176 write(3, "/dev/nst0: Input/output error\n", 30/dev/nst0:
Input/output error
) = 30
15:01:45.850465 close(3)                = 0
15:01:45.851383 munmap(0xb7fd1000, 4096) = 0
15:01:45.852499 exit_group(1)           = ?
Process 12840 detached


Comment 8 Craig Goodyear 2007-07-24 16:31:18 EDT
Created attachment 159885 [details]
output from "strace -tt mt -f /dev/nst0 status"
Comment 9 Kelly-Rand 2007-08-10 06:49:41 EDT
I also just installed F7_x86_64 and can no longer access my seagate tape drive.
I am currently in Fc6 and have a work around to the partial libata system as
documented in bug # 150335. This work around obviously won't work in F7. I will
post the output of strace when I next boot into F7.
Comment 10 Kelly-Rand 2007-08-10 23:03:34 EDT
Created attachment 161103 [details]
Describes the hardware
Comment 11 Kelly-Rand 2007-08-10 23:05:10 EDT
Created attachment 161104 [details]
strace output for working session in Fc6
Comment 12 Kelly-Rand 2007-08-10 23:06:59 EDT
Created attachment 161105 [details]
strace output from nonworking F7 session
Comment 13 Kelly-Rand 2007-08-10 23:09:52 EDT
Created attachment 161106 [details]
dmesg output relative to the Seagate STT8000A tape drive
Comment 14 Kelly-Rand 2007-08-15 22:09:56 EDT
Created attachment 161424 [details]
describes the hardware
Comment 15 Kelly-Rand 2007-08-23 22:53:45 EDT
I recompiled the kernel for version 2.6.22.1-33(F7)x86_64 to include all the
standard ide modules plus ide-tape. Installing this kernel I am able to now
access the tape drive as usual. This seems to have disabled libata as all the
drives are recognized as hda and hdb instead of sda and sdb. Also one mount
point was not re-established, the one containing the root of my Fc6 install.
If I knew which modules to make in /usr/src/kernels/<version> I would attempt to
see if a less drastic measure could be taken than compiling from source.
Comment 16 Chuck Ebbert 2007-08-29 14:40:37 EDT
Are there any messages at all in the kernel logs when trying to check the status
of the tape drive? The log that was posted shows some messages, but no way to
tell when they happened.

Also, has anyone tried a tape drive as a master device on its own cable? In one
case we have the drive as a slave with another device, and in the other it is a
slave on its own cable.

Comment 17 Craig Goodyear 2007-08-29 18:36:12 EDT
Created attachment 179901 [details]
kernel messages w/ tape as master 

I have attached the ide tape drive as the master with 
no other devices on the cable.	I have attached the 
kernel messages for the tape drive during boot, kernel 
message from "mt -f /dev/nst0 status", and the output 
from "strace -tt mt -f /dev/nst0 status".
Comment 18 ronsteiner 2007-09-23 11:32:14 EDT
Created attachment 203491 [details]
IDE Tape Error with FC7
Comment 19 ronsteiner 2007-09-23 11:36:03 EDT
I also have the same error with an IDE tape connected as master with no slave on
the cable when running FC7. Following Craig's lead, I have attached the kernel
messages for the tape drive during boot, kernel message from "mt -f /dev/st0
status", and the output from "strace -tt mt -f /dev/nst0 status".
Comment 20 Kelly-Rand 2007-09-23 13:17:01 EDT
Kernel Maintainers!
Are there any other tests we can run to narrow the code search?
Are there any test patches that we might try?
Has any of the output from what has been posted on this bug and bug #150335 been
of any help?

Jim K-R
Comment 21 Chuck Ebbert 2007-09-24 14:58:59 EDT
Already reported upstream and being worked on...

http://www.mail-archive.com/linux-ide@vger.kernel.org/msg09984.html
Comment 22 Kelly-Rand 2007-09-24 22:04:43 EDT
I read through the link you sent. It sounds good, though they were using an
older atapi drive for their testing. I posted the partial specs of the seagate
drive earlier. If the whole Spec would help I could post that. Otherwise I am
willing to test a patch. 

Jim
Comment 23 Kelly-Rand 2007-10-08 21:03:19 EDT
Is there a 2.6.23 kernel that I can test?

Comment 24 ronsteiner 2007-10-15 13:35:13 EDT
I just tried the live version of fc8 test 3, which, I think, includes kernel
2.6.23 and I still get the same I/O error when trying to access /dev/st0 or
/dev/tape.
Comment 25 Chuck Ebbert 2007-12-11 17:08:30 EST
Fix went into 2.6.23.9-47
Comment 26 Kelly-Rand 2008-01-03 23:11:07 EST
I am testing the updated kernel-2.6.23.12-52.fc7 and device nst0 now. So far it
works. I will follow up when I have run a few tests.
Jim
Comment 27 Kelly-Rand 2008-01-13 14:46:34 EST
Created attachment 291511 [details]
strace output Post kernel-2.6.23.12-52.fc7 with libata enabled

These were run in a sequence over a period of an hour or two.
Comment 28 Bug Zapper 2008-05-14 08:58:47 EDT
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 29 Peter van Egdom 2008-05-17 08:29:41 EDT
Changing Fedora version from "7" to "9".

I tried the Fedora 9 live CD on my (old) computer with an IDE-tape device. This
bug report is 100% reproducable on that machine. In the past (on Red Hat Linux
7.x) it worked fine (with kernel 2.4.x and the "ide-tape" module).

Ever since the Linux kernel moved to "libata" I haven't been able to get the
tape device working anymore.

Admittedly, this old machine is of no real use any more today, but I
periodically try testing Fedora live CD's on it, just to try the tape device. :-)
Comment 30 Kelly-Rand 2008-05-17 09:11:23 EDT
I have discontinued use of tape backups. The fix provided in the 2.6.23...
kernel did allow access, read and writes to the tape drive but it was
inconsistent. I might get a full backup or it might stall at 90%. It would hang
on appends. I could not wait for a fix and changed to usb disks and a completely
different schema for backups. 

I think ide-tape drives have gone the way of floppy drives.

The tape drive capacity and speed has not kept up with the needs of today.

Jim KR
Comment 31 Bug Zapper 2009-06-09 18:38:53 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 32 Bug Zapper 2009-07-15 04:16:51 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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