From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050224 Firefox/1.0.1 Fedora/1.0.1-1.3.1 Description of problem: After updating the kernel from 2.6.9-1.667 to 2.6.10-1.766_FC3, I can no longer extract files that were created with tar or dump to my tape drive. My tape drive is a Seagate STT8000A ATAPI. I am using the ide-scsi module. No errors are generated with either tar or dump while the files are being written to the tape drive. However, I am unable to extract any files from the drive after they have been written. Tar returns no errors and writes no files to the hard disk during the extract command. Dump's restrore command returns the following error: "restore: Tape is not a dump tape." The mt and cpio commands work without any problems. I had no problem with any of the tape operations while I was using the 2.6.9-1.667 kernel. I am able to extract files, if they were written to the tape drive while the 2.6.9-1.667 kernel was running. Version-Release number of selected component (if applicable): kernel 2.6.10-1.766_FC3 How reproducible: Always Steps to Reproduce: 1. execute the following commands: mt -f /dev/nst0 rewind tar cf /dev/nst0 /home/craig mt -f /dev/nst0 rewind tar xf /dev/nst0 2. 3. Actual Results: No errors are generated and no files are written to the hard disk. Expected Results: Files should have been written to the hard disk. Additional info:
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I have upgraded to FC4 since the original bug report. My system is fully updated, including kernel 2.6.12-1.1398_FC4. I have tested the tape drive, and the problem still exist. I have found a work around. The tape drive will function normally, if I disable DMA for the drive.
Mass update to all FC4 bugs: An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream kernel (2.6.13.2). As there were ~3500 changes upstream between this and the previous kernel, it's possible your bug has been fixed already. Please retest with this update, and update this bug if necessary. Thanks.
I have installed the new kernel (2.6.13-1.1526_FC4). I retested and found no change the operation of my tape drive. The DMA must be disabled for it to function correctly.
2.6.14-1.1637_FC4 has been released as an update for FC4. Please retest with this update, as a large amount of code has been changed in this release, which may have fixed your problem. Thank you.
I have installed the new kernel (2.6.14-1.1637_FC4), and I have tar version 1.15.1-11.FC4 installed. I still must turn off DMA for the tape drive to function correctly.
I have a new (2 weeks old) Travan (Seagate/Certance) STT20000A which exhibits similar behaviour. It worked fine running CentOS 4.1 with kernel kernel-2.6.9-22.0.1.EL. Since changing to Fedora 4 with any kernel since kernel-2.6.14-1.1637_FC4 (this one and those following up to 1653_FC4 are the only ones I've used) this drive will now only work with DMA disabled, unless I force blocksize to 512 Bytes, which is dismally slow for obvious reasons. The problem exists using tar as well as bacula.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
I have installed the new kernel (2.6.15-1.1830_FC4) and all other available updates for this FC4 system. There is no difference in the tape dirve. DMA must be turned off for it to function correctly.
I am running 2.6.17-1.2157_FC5 with an ATAPI Seagate STT20000A using ide-scsi and I'm seeing this exact problem. tar -cvf appears to work normally. mt operations work normally (except for sense error messages in dmesg) mt asf 0,1,2,... appears to work nomrally, moving tape to starts of files. tar -tvf exits with no file listing and no errors. The following test was performed with a brand new tape: 1. tar -cvf and mt rewind appear to work normally. 2. mt status reports BOT, file = 0, block = 0. 3. tar -tvf causes some drive activity but exits code 0 without listing or errors. 4. Subsequent tar -tvf exits code 0 immediately with no drive activity, listing, or errors. BIOS IDE UDMA setting (on, off) did not affect test outcome.
Sorry left out a potentially important point: 3a. After first tar -tvf, mt status reports ONLINE, file = 0, block = 40.
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
Changing status back to assigned. I did encounter this bug in FC5.
I have all of the current updates for this FC5 system installed, including kernel 2.6.17-1.2187_FC5. There is no change in the operation of the tape drive. DMA must be turned off for it to function correctly.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
I have all of the current updates for this FC5 system installed, including kernel 2.6.18-1.2200.fc5. There is no change in the operation of the tape drive. DMA must be turned off for it to function correctly.
I applied all updates including 2.6.18-1.2200.fc5. This did not change the behavior I reported in comment #10. HOWEVER, picking up on Craig's comment about DMA I performed the following steps: 1. MAKEDEV -x hdd (the dev was missing from my system for some reason) 2. hdparm -d0 /dev/hdd After this I was able to read back tarred files from the tape.
Can the folks seeing this tell me two other things #1 What IDE controller and which port and whether master/slave #2 Whether you need DMA off for read and write or just to read the tape
I have two systems with IDE tape drives: System 1: NFORCE2 IDE controller tape drive on ide1 (secondary) as slave System 2: NFORCE-CK804 IDE controller tape drive on ide0 (primary) as slave Both have all FC5 updates installed. Both systems behave the same. If I write to the tape with DMA turned off, I can read with or without DMA. If I write to the tape with DMA turned on, I can not read the tape with or without DMA.
My tape is slave on secondary. Writing with DMA on appears to work, i.e. it takes time. Readback fails. I haven't tried writing with DMA on and reading back with it off.
I believe that bug 234106 is related to this bug in a round about way. I have always used the ide-tape.ko module that I compiled to use my Seagate STT8000a atapi drive on ide1. This had worked flawlesly for 5 years till now that the ide subsystem has been fazed out. Ide1 shares the tape drive and CD/DVD device as is typical on ide based systems. I tried the ide-scsi route once but found it only worked when the tape was the only device on the cable. Now I can read the tapes created on the ide subsystem with the sg module but not write or erase (one and the same). If someone can point me to find out how to turn off DMA for the tape device I will give that a try.
This is the process that I use to turn off DMA for ide tape at hdb: a) use "MAKEDEV hdb" to create /dev/hdb b) "cp -a /dev/hdb /etc/udev/devices" c) add "hdparm -d0 /dev/hdb" to /etc/rc.d/rc.local d) reboot
Craig, I did as you described above for my tape device on hdd. When I rebooted I was not able to access the drive, and received the following output: # mt -f /dev/nst0 eod /dev/nst0: Input/output error # ll /dev/hdd brw-r----- 1 root disk 22, 64 Apr 6 20:24 /dev/hdd # ll /etc/udev/devices/hdd brw-r----- 1 root disk 22, 64 Apr 6 20:24 /etc/udev/devices/hdd ]# less /etc/rc.local | grep hd hdparm -d0 /dev/hdd Since the history of your problems pre-date mine and the libata module I presume you are still using the old setup for ide-scsi. Do you have special boot parameters in grub?
I have read the Scsi-Howto and now have hdd=ide-scsi set in grub.conf. I also had to add the -c1 switch to /sbin/hdparm -d0. After that I could write to the tape drive and then read back what was written. When I run the full backup I will beable to see what the performance is. The block location on the tape is still not reported so the scsi module is not accessing all the performance available. I will try some other hdparm settings tomorrow.
Today a tried some of the other hdparm parameters. hdparm -d0 -c3 does not allow write access the drive will not move hdparm -d1 -X34 does not write to tape though there is tape activity tar -tf /dev/nst0 outputs nil hdparm -d1 -c1 allows tape writes and reads ###############Tar Commands and Output###################### # tar -cf - /var/tmp | dd of=/dev/nst0 obs=126 tar: Removing leading `/' from member names dd: writing to `/dev/nst0': Invalid argument 1+0 records in 0+0 records out 0 bytes (0 B) copied, 0.085466 seconds, 0.0 kB/s # notice that no data is written to tape # tar -cf - /var/tmp | dd of=/dev/tape tar: Removing leading `/' from member names 40+0 records in 40+0 records out 20480 bytes (20 kB) copied, 17.2292 seconds, 1.2 kB/s # here data is written. the obs=126 parameter of dd is not supported. My backup script is based on dd output to tape I will run a full backup of my machine Monday after I remove the obs=126 parameter of dd. I will be able to get and idea of the performance of the drive without DMA support then. I am attaching the tape drive specifications (excerpt) and output of hdparm -i and hdparm -I for reference.
Created attachment 151918 [details] Excerpt from Seagate tape drive manual
Created attachment 151919 [details] Hdparm query output
I am using ide-scsi to access the tape drive by adding "hdb=ide-scsi" to grub.conf. I use amanda and tar for backup and restore to the tape. The data transfer rate to my Seagate STT8000A ATAPI tape is about 550 KB/sec.
There is no code specific to tape devices in ide-scsi.c or sg.c, as there is in ide-tape.c. What is adaptable from ide-tape.c that could be incorporated into the ide-scsi.c to address the DMA access differences? If you are getting data transfer rates approaching 550KB/sec then that is equivalent to what I was getting with ide-tape.ko. 600KB/sec is the Spec top transfer rate for the device. Is the DMA io function of any value? Can libata.c be written to automatically turn off DMA but set 32 bit controller speed for atapi tape drives?
Well, my backup script stalled on this command: mt -f /dev/nst0 eod Once I commented out that line the script started the backup process. I need to figure out how to ensure that the tape advances to the end of data, so that I can append data to the tape. Typically I run the command as a cron job. Is there an alternative command under ide-scsi? To un-freeze the io to the drive I have to issue the retentsion command or physically remove the tape and re-insert. How do I set the debug info level higher, so that I can get better information on the io errors? "mt -f /dev/nst0 stoptions [option]" did not have an effect.
I no longer append backups to the previous backup, but when I did, I used the mt parameters tell and seek. After the write to tape was complete, I would write the block number returned by tell to a file. Then I would use seek to position the tape at the previously written block number prior to starting the next backup.
*** Bug 234106 has been marked as a duplicate of this bug. ***
(In reply to comment #32) > *** Bug 234106 has been marked as a duplicate of this bug. *** Look for the package 'mt-st' on the Fc6 install disks. I didn't know there was a st component to the mt package. I will try some of the calls over the next week to see if I can get them to work.
I just checked the backup log and it was complete, but it took 8 Hrs to run. It normally takes 2 Hrs. So it is not viable yet. So does anyone know the st commands to get good through put on a fixed block (512 byte) drive?
(In reply to comment #34) Well it's been a month, and I was never able to get the ide-scsi route to work for me. I could get faster through put but I couldn't write to tape past the 3339000 block (1.7 gig). I created a work around that restores the ide-tape functionality by adding the following to rc.local: MAKEDEV ht0 nht0 /sbin/rmmod ide-tape ide-scsi #sata_nv st sg libata modprobe ide-tape This works so I'm back in business.
FC7/FC8 use the libata layer so I'm closing this bug as obsolete.