Description of problem:
If I do an "mt retension" it works for a bit, then the machine hangs completely
(keyboard lights fixed, can't move mouse, can't ping).
According to Seagate, this drive was tested with kernel 2.4.18-17. I've
confirmed the hardware is good by testing with their stdiag.exe program under
WinXP. All other tape operations appear to be working properly.
The specific drive is the Seagate "Hornet" Travan 40. Model number is STT3401A.
I've got ide-scsi.o and sg.o loaded.
Version-Release number of selected component (if applicable):
mt-st-0.7-10 under kernel-smp-2.4.20-13.9
(I'm listing the kernel because this is likely a driver issue, not an mt issue.)
Steps to Reproduce:
1.mt -f /dev/nst0 retension
Actual Results: Appears to work for a minute or so, and then machine is
Expected Results: Should wind to end of tape, then rewind back to beginning.
assign to correct component
I'm puzzled that you are using st not ide-tape for this drive ?
Seagate tech support specifically stated (in email) to do:
They also said to modify /etc/modules.conf to contain:
alias ide-tape off
below st ide-scsi
As far as getting things to work, they claim it works on their end with a
default install of RH9. We're currently investigating whether the firmware
might be different between our machines. I'll add another comment when I know
Ok - seagate are choosing to use the scsi tape driver - that should be fine, and
is the best thing for some drives. One other question then - is the drive
sharing a bus with anything else especially
a disk or CD-ROM ?
My initial tests were done with the drive wired as the secondary slave (a CD
burner (Samsung) was the master), hyperthreading enabled, the patched RedHat9
SMP kernel. I repeated the tests with it wired as the secondary master (with
no slave), hyperthreading disabled, and the unpatched RedHat9 UP kernel.
It is interesting to note that Seagate claims it works for them using RedHat9
with the 2.4.18-17 kernel. Their boot drive is SCSI (mine is IDE) so they
might have different modules loaded than I have. I've tried loading the extra
modules without success.
The most recent development is that, while Seagate claims there has never been
a firmware upgrade with this drive, I have a different firmware revision than
they have on their test machine. They are using firmware revision 309C, while
I am using revision 309I. I'm expecting a call from them tomorrow, when they
hope to be able to test with a 309I drive.
The fact it is shared with a CD burner might be important because it changes
some of the commands Linus will be sending to that IDE bus.
Can you try the following
log out of the GUI so it is back at the login box
hit ctrl-alt-f1 to switch to a text console
Login as root
At the prompt type the mt retension command and see what is displayed if anything
If it works in that situation then I have a suspicion I know what is up
Created attachment 92334 [details]
/var/log/messages logs relating to tape drive
I took a hint from your revision to the bug summary, and did a:
mt -f /dev/nst0 retension
and it ran to completion. Normally it would hang the machine within 30
seconds. So that was definitely it! I guess it's now just a question of what
to do next.
There's also the question of the meaning of the log messages I've seen, but
that's of course low priority, since it appears the drive is at least
functional. In case they're important, though, I'm attaching a sample of the
I managed to determine (by running a modified st.o module) that the log messages
were coming about as a result of SCSI opcode 5: READ_BLOCK_LIMITS, which
apparently this tape drive does not understand. I've emailed
TapeSupport@seagate.com about this, so hopefully they can fix this in a future
Regarding the other issue, is the only solution to rpm -e magicdev?
For now yes, or make sure there are no cd drives sharing the tape bus. I need to
fix the real bug its triggering
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/