Bug 477772
| Summary: | mtx fails during unload operations | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vadym Chepkov <vchepkov> |
| Component: | mtx | Assignee: | Dan Horák <dan> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 11 | CC: | dan, rothrock |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-06-28 11:01:04 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: | |||
What was your previous versions of both Fedora and mtx? Previous was Fedora 9 and I was keeping it up-to-day until Fedora 10 has arrived. I assume it was the same version maybe something has changed in the kernel? # grep mtx yum.log May 13 14:53:02 Updated: mtx - 1.3.11-3.fc9.i386 Sep 26 10:57:43 Updated: mtx-1.3.12-1.fc9.i386 Nov 25 14:08:36 Updated: mtx-1.3.12-1.fc10.i386 I am suspecting the kernel too. The F-9 and F-10 kernels are based on the same vanilla version, but can contain different sets of additional patches. Can you install some F-9 kernel into your F-10 and test the unloads with the old kernel? You can select a kernel at https://admin.fedoraproject.org/updates/search/kernel?tg_paginate_limit=48 and then download the rpms from Koji by clicking the "Builds" link (eg. http://koji.fedoraproject.org/koji/buildinfo?buildID=63641). I have installed 2.6.26.5-45.fc9.i686 but result is the same :(
# mtx status
Storage Changer /dev/changer:1 Drives, 6 Slots ( 0 Import/Export )
Data Transfer Element 0:Full (Storage Element 6 Loaded)
Storage Element 1:Full
Storage Element 2:Full
Storage Element 3:Full
Storage Element 4:Full
Storage Element 5:Full
Storage Element 6:Empty
# mtx unload
Unloading drive 0 into Storage Element 6...mtx: Request Sense: Long Report=yes
mtx: Request Sense: Valid Residual=no
mtx: Request Sense: Error Code=70 (Current)
mtx: Request Sense: Sense Key=Hardware Error
mtx: Request Sense: FileMark=no
mtx: Request Sense: EOM=no
mtx: Request Sense: ILI=no
mtx: Request Sense: Additional Sense Code = 44
mtx: Request Sense: Additional Sense Qualifier = 00
mtx: Request Sense: BPV=no
mtx: Request Sense: Error in CDB=no
mtx: Request Sense: SKSV=no
MOVE MEDIUM from Element Address 1 to 7 Failed
Have you noticed Element address 7? I sure don't have one, it seems something went wrong with elements numbering.
I forgot to mention one fact that I have some custom udev rules: # cat /etc/udev/rules.d/local.rules KERNEL=="sg4",MODE="0660",OWNER="root",GROUP="disk",SYMLINK+="changer" KERNEL=="nst0",MODE="0660",OWNER="root",GROUP="disk",SYMLINK+="ntape" I added them, because standard permissions on tape and changer devices do not allow amandabackup user to access them for writing. Commenting them out didn't seem to make a difference, though. Still an issue in kernel kernel-2.6.27.12-170.2.5.fc10.i686: # mtx unload Unloading drive 0 into Storage Element 5...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Hardware Error mtx: Request Sense: FileMark=no mtx: Request Sense: EOM=no mtx: Request Sense: ILI=no mtx: Request Sense: Additional Sense Code = 44 mtx: Request Sense: Additional Sense Qualifier = 00 mtx: Request Sense: BPV=no mtx: Request Sense: Error in CDB=no mtx: Request Sense: SKSV=no MOVE MEDIUM from Element Address 1 to 6 Failed # mtx unload Unloading drive 0 into Storage Element 5...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Hardware Error mtx: Request Sense: FileMark=no mtx: Request Sense: EOM=no mtx: Request Sense: ILI=no mtx: Request Sense: Additional Sense Code = 00 mtx: Request Sense: Additional Sense Qualifier = 00 mtx: Request Sense: BPV=no mtx: Request Sense: Error in CDB=no mtx: Request Sense: SKSV=no MOVE MEDIUM from Element Address 1 to 6 Failed # mtx unload Data Transfer Element 0 is Empty It still didn't work last week but it works now, here is the whole list of the packages that changed in this timeframe, it doesn't make sense to me, maybe will give you some clues policycoreutils-2.0.57-21.fc10 Fri 22 May 2009 08:09:14 AM EDT ypbind-1.20.4-11.fc10 Fri 22 May 2009 08:09:08 AM EDT squirrelmail-1.4.18-2.fc10 Wed 20 May 2009 07:59:17 AM EDT ipsec-tools-0.7.2-1.fc10 Wed 20 May 2009 07:58:52 AM EDT netpbm-progs-10.35.64-1.fc10 Wed 20 May 2009 07:58:39 AM EDT selinux-policy-targeted-3.5.13-59.fc10 Wed 20 May 2009 07:56:05 AM EDT selinux-policy-3.5.13-59.fc10 Wed 20 May 2009 07:54:53 AM EDT libX11-1.1.5-4.fc10 Wed 20 May 2009 07:54:44 AM EDT netpbm-10.35.64-1.fc10 Wed 20 May 2009 07:54:31 AM EDT sos-1.8-11.fc10 Sat 16 May 2009 08:14:23 AM EDT false alarm, still doesn't work:( # mtx unload Unloading drive 0 into Storage Element 6...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Hardware Error mtx: Request Sense: FileMark=no mtx: Request Sense: EOM=no mtx: Request Sense: ILI=no mtx: Request Sense: Additional Sense Code = 00 mtx: Request Sense: Additional Sense Qualifier = 00 mtx: Request Sense: BPV=no mtx: Request Sense: Error in CDB=no mtx: Request Sense: SKSV=no MOVE MEDIUM from Element Address 1 to 7 Failed Is the last line looks ok to you? At first it says drive 0 to element 6 but failure occurs when moving element 1 to element 7. It should be OK, because there are some numbering inconsistencies in the mtx code. Thanks for the status update, I should receive a DAT autoloader in the next days so hopefully there should be some progress then. Upgraded to Fedora 11 mtx-1.3.12-3.fc11.i586 same issue. same issue - Fedora 10 - fresh install slot numbering is incorrect r:~/projects/powerfile> mtx -f /dev/sg10 nobarcode noattach transfer 201 1 mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Illegal Request mtx: Request Sense: FileMark=no mtx: Request Sense: EOM=no mtx: Request Sense: ILI=no mtx: Request Sense: Additional Sense Code = 24 mtx: Request Sense: Additional Sense Qualifier = 00 mtx: Request Sense: Field in Error = 00 mtx: Request Sense: BPV=yes mtx: Request Sense: Error in CDB=no mtx: Request Sense: SKSV=yes mtx: Request Sense: Field Pointer = 00 00 MOVE MEDIUM from Element Address 1 to 4 Failed I can provide additional support information if needed. Verified same observation on 2.6.29.4-167.fc11.x86_64 mtx -f /dev/sg4 nobarcode noattach transfer 201 1 mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Illegal Request mtx: Request Sense: FileMark=no mtx: Request Sense: EOM=no mtx: Request Sense: ILI=no mtx: Request Sense: Additional Sense Code = 24 mtx: Request Sense: Additional Sense Qualifier = 00 mtx: Request Sense: Field in Error = 00 mtx: Request Sense: BPV=yes mtx: Request Sense: Error in CDB=no mtx: Request Sense: SKSV=yes mtx: Request Sense: Field Pointer = 00 00 MOVE MEDIUM from Element Address 1 to 4 Failed I finally bought myself an autoloader (TSL-10000) and run few loading/unloading tests and they didn't show any problems. What are your environments? Any relevant output in /var/log/messages or when running "dmesg"? My environment is F-10/x86_64 with mtx-1.3.12-1.fc10.x86_64 (there are no functional changes in F-11 and later) kernel-2.6.27.35-170.2.94.fc10.x86_64 autoloader is Compaq/Sony TSL-10000 SCSI adapter is Adaptec 19160 mtx unload ALWAYS unload tape only after you run it 2 times.
mtx load works with no issues.
kernel-PAE-2.6.29.6-217.2.16.fc11.i686
mtx-1.3.12-3.fc11.
# dmesg|grep ch0
ch0: type #1 (mt): 0x0+0 [medium transport]
ch0: type #2 (st): 0x2+6 [storage]
ch0: type #3 (ie): 0x0+0 [import/export]
ch0: type #4 (dt): 0x1+1 [data transfer]
ch0: dt 0x1: ID 6, LUN 0, name: HP C1557A U812
ch0: INITIALIZE ELEMENT STATUS, may take some time ...
ch0: ... finished
ch 2:0:6:1: Attached scsi changer ch0
# mtx status
Storage Changer /dev/changer:1 Drives, 6 Slots ( 0 Import/Export )
Data Transfer Element 0:Full (Storage Element 5 Loaded)
Storage Element 1:Full
Storage Element 2:Full
Storage Element 3:Full
Storage Element 4:Full
Storage Element 5:Empty
Storage Element 6:Full
# mtx unload
Unloading drive 0 into Storage Element 5...mtx: Request Sense: Long Report=yes
mtx: Request Sense: Valid Residual=no
mtx: Request Sense: Error Code=70 (Current)
mtx: Request Sense: Sense Key=Hardware Error
mtx: Request Sense: FileMark=no
mtx: Request Sense: EOM=no
mtx: Request Sense: ILI=no
mtx: Request Sense: Additional Sense Code = 44
mtx: Request Sense: Additional Sense Qualifier = 00
mtx: Request Sense: BPV=no
mtx: Request Sense: Error in CDB=no
mtx: Request Sense: SKSV=no
MOVE MEDIUM from Element Address 1 to 6 Failed
# mtx unload
Unloading drive 0 into Storage Element 5...mtx: Request Sense: Long Report=yes
mtx: Request Sense: Valid Residual=no
mtx: Request Sense: Error Code=70 (Current)
mtx: Request Sense: Sense Key=Hardware Error
mtx: Request Sense: FileMark=no
mtx: Request Sense: EOM=no
mtx: Request Sense: ILI=no
mtx: Request Sense: Additional Sense Code = 00
mtx: Request Sense: Additional Sense Qualifier = 00
mtx: Request Sense: BPV=no
mtx: Request Sense: Error in CDB=no
mtx: Request Sense: SKSV=no
MOVE MEDIUM from Element Address 1 to 6 Failed
# mtx unload
Data Transfer Element 0 is Empty
I see one difference between our setups - I don't have the "ch" driver loaded and my /dev/changer is a symlink to /dev/sg7. Vadym, can you try to remove it? not sure what do you ask me to remove this is what I have, and it's created by udev, just installed new one: udev-141-7.fc11.i586 # ls -l /dev/changer lrwxrwxrwx. 1 root root 3 2009-10-14 20:04 /dev/changer -> sg4 # ls -l /dev/sg4 crw-rw----. 1 root tape 21, 4 2009-10-14 20:04 /dev/sg4 # ls -l /dev/nst0 crw-rw----. 1 root tape 9, 128 2009-10-14 20:04 /dev/nst0 Stuart, can you still reproduce the issue and are you sure that your hardware is OK? I had a private discussion with Vadym and he is most likely experiencing hardware problems with his setup. It will take a few days to schedule the work but I can have it hooked up to a windows box to tst the hardware and can recreate the problem IF it will help resolve the issue if it still exists. Let me know. Thanks. (In reply to comment #18) > It will take a few days to schedule the work but I can have it hooked up to a > windows box to tst the hardware and can recreate the problem IF it will help > resolve the issue if it still exists. Let me know. Thanks. Because I can't reproduce the problem myself and I am not aware of any known issues with mtx in Fedora or RHEL, the next step should be to find out whether it's a hardware issue or it's related to a version update of some package. . And using windows box (with or without windows build of mtx) or linux box with eg. CentOS 5 installed can help here. Also what type is your autoloader? Are your comments 12 and 13 from first tries of mtx on Fedora? This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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. |
After upgrade to Fedora 10 mtx started to fail on unload operations. I have mtx-1.3.12-1.fc10.i386 installed. Heare are the symptomps: # mtx status Storage Changer /dev/changer:1 Drives, 6 Slots ( 0 Import/Export ) Data Transfer Element 0:Full (Storage Element 5 Loaded) Storage Element 1:Full Storage Element 2:Full Storage Element 3:Full Storage Element 4:Full Storage Element 5:Empty Storage Element 6:Full # mtx unload Unloading drive 0 into Storage Element 5...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Hardware Error mtx: Request Sense: FileMark=no mtx: Request Sense: EOM=no mtx: Request Sense: ILI=no mtx: Request Sense: Additional Sense Code = 44 mtx: Request Sense: Additional Sense Qualifier = 00 mtx: Request Sense: BPV=no mtx: Request Sense: Error in CDB=no mtx: Request Sense: SKSV=no MOVE MEDIUM from Element Address 1 to 6 Failed # mtx status Storage Changer /dev/changer:1 Drives, 6 Slots ( 0 Import/Export ) Data Transfer Element 0:Full (Storage Element 5 Loaded) Storage Element 1:Full Storage Element 2:Full Storage Element 3:Full Storage Element 4:Full Storage Element 5:Empty Storage Element 6:Full It fails even if I specify the full address: # mtx unload 5 0 Unloading drive 0 into Storage Element 5...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Hardware Error mtx: Request Sense: FileMark=no mtx: Request Sense: EOM=no mtx: Request Sense: ILI=no mtx: Request Sense: Additional Sense Code = 00 mtx: Request Sense: Additional Sense Qualifier = 00 mtx: Request Sense: BPV=no mtx: Request Sense: Error in CDB=no mtx: Request Sense: SKSV=no MOVE MEDIUM from Element Address 1 to 6 Failed But tape gets unloaded: # mtx status Storage Changer /dev/changer:1 Drives, 6 Slots ( 0 Import/Export ) Data Transfer Element 0:Empty Storage Element 1:Full Storage Element 2:Full Storage Element 3:Full Storage Element 4:Full Storage Element 5:Full Storage Element 6:Full # mtx -f /dev/changer inquiry Product Type: Medium Changer Vendor ID: 'HP ' Product ID: 'C1557A ' Revision: 'U812' Attached Changer API: No