Bug 150335 - IDE: DMA TAPE: unable to read tar file on ide tape drive after kernel update
Summary: IDE: DMA TAPE: unable to read tar file on ide tape drive after kernel update
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Alan Cox
QA Contact: Brian Brock
URL:
Whiteboard:
: 234106 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-03-04 17:54 UTC by Craig Goodyear
Modified: 2007-12-03 17:18 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-12-03 17:18:39 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Excerpt from Seagate tape drive manual (14.05 KB, application/vnd.oasis.opendocument.text)
2007-04-07 17:22 UTC, Kelly-Rand
no flags Details
Hdparm query output (1.25 KB, text/plain)
2007-04-07 17:25 UTC, Kelly-Rand
no flags Details

Description Craig Goodyear 2005-03-04 17:54:30 UTC
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:

Comment 1 Dave Jones 2005-07-15 17:57:16 UTC
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.

Comment 2 Craig Goodyear 2005-07-15 22:00:29 UTC
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.


Comment 3 Dave Jones 2005-09-30 06:23:38 UTC
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.


Comment 4 Craig Goodyear 2005-10-03 17:33:08 UTC
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.

Comment 5 Dave Jones 2005-11-10 19:23:30 UTC
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.


Comment 6 Craig Goodyear 2005-11-11 15:34:04 UTC
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.


Comment 7 Gordon Larsen 2006-01-06 03:58:06 UTC
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.

Comment 8 Dave Jones 2006-02-03 05:28:53 UTC
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.


Comment 9 Craig Goodyear 2006-02-03 18:04:47 UTC
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.


Comment 10 David Nadle 2006-08-08 21:22:42 UTC
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.



Comment 11 David Nadle 2006-08-08 21:26:00 UTC
Sorry left out a potentially important point:

3a. After first tar -tvf, mt status reports ONLINE, file = 0, block = 40.

Comment 12 Dave Jones 2006-09-17 01:58:11 UTC
[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.

Comment 13 David Nadle 2006-09-17 12:59:56 UTC
Changing status back to assigned. I did encounter this bug in FC5.

Comment 14 Craig Goodyear 2006-09-17 20:58:13 UTC
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.


Comment 15 Dave Jones 2006-10-16 18:02:48 UTC
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.

Comment 16 Craig Goodyear 2006-10-17 22:05:11 UTC
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.


Comment 17 David Nadle 2006-10-18 09:17:33 UTC
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.

Comment 18 Alan Cox 2006-10-18 10:08:07 UTC
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


Comment 19 Craig Goodyear 2006-10-18 21:01:42 UTC
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.


Comment 20 David Nadle 2006-10-21 06:31:18 UTC
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.

Comment 21 Kelly-Rand 2007-04-04 02:01:03 UTC
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. 

Comment 22 Craig Goodyear 2007-04-04 14:40:25 UTC
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

Comment 23 Kelly-Rand 2007-04-07 01:11:34 UTC
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? 

Comment 24 Kelly-Rand 2007-04-07 03:39:10 UTC
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.

Comment 25 Kelly-Rand 2007-04-07 17:17:41 UTC
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.

Comment 26 Kelly-Rand 2007-04-07 17:22:00 UTC
Created attachment 151918 [details]
Excerpt from Seagate tape drive manual

Comment 27 Kelly-Rand 2007-04-07 17:25:18 UTC
Created attachment 151919 [details]
Hdparm query output

Comment 28 Craig Goodyear 2007-04-07 17:48:36 UTC
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.


Comment 29 Kelly-Rand 2007-04-08 00:38:37 UTC
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?

Comment 30 Kelly-Rand 2007-04-09 17:55:37 UTC
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. 


Comment 31 Craig Goodyear 2007-04-09 19:14:00 UTC
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.

Comment 32 Chuck Ebbert 2007-04-09 19:35:59 UTC
*** Bug 234106 has been marked as a duplicate of this bug. ***

Comment 33 Kelly-Rand 2007-04-10 00:48:18 UTC
(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.

Comment 34 Kelly-Rand 2007-04-10 01:10:06 UTC
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?

Comment 35 Kelly-Rand 2007-05-12 23:54:44 UTC
(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. 

Comment 36 Alan Cox 2007-12-03 17:18:39 UTC
FC7/FC8 use the libata layer so I'm closing this bug as obsolete.




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