Bug 243568
Description
Craig Goodyear
2007-06-09 21:21:13 UTC
Created attachment 156658 [details]
the output from dmesg and smolt
Apparently there is no equivalent of ide-scsi available for the new PATA drivers. Nothing to do with the bug report Chuck - st handles tape drives Does the device file /dev/nst0 exist? The device file /dev/nst0 does exist, as does /dev/st0. (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 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 Created attachment 159885 [details]
output from "strace -tt mt -f /dev/nst0 status"
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. Created attachment 161103 [details]
Describes the hardware
Created attachment 161104 [details]
strace output for working session in Fc6
Created attachment 161105 [details]
strace output from nonworking F7 session
Created attachment 161106 [details]
dmesg output relative to the Seagate STT8000A tape drive
Created attachment 161424 [details]
describes the hardware
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. 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. 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".
Created attachment 203491 [details]
IDE Tape Error with FC7
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". 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 Already reported upstream and being worked on... http://www.mail-archive.com/linux-ide@vger.kernel.org/msg09984.html 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 Is there a 2.6.23 kernel that I can test? 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. Fix went into 2.6.23.9-47 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 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.
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 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. :-) 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 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 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. |