Bug 92051
| Summary: | (IDE MAGICDEV??)mt retension hangs machine with STT3401A drive | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Damian Menscher <menscher> | ||||
| Component: | kernel | Assignee: | Arjan van de Ven <arjanv> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Brian Brock <bbrock> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 9 | CC: | alan, than | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | i686 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2004-09-30 15:41:02 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Damian Menscher
2003-06-02 03:28:43 UTC
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: rmmod ide-tape rmmod ide-scsi insmod ide-scsi insmod sg 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 more.... 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:
killall magicdev
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
logs.
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 about this, so hopefully they can fix this in a future firmware release. 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 persists. 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/ |