SCSI error HHC00205E for each SCSI drive #97
Comments
|
Interesting! Given that the only place where we do a Further, it would seem our scsimount logic is also either very sick (some race condition somewhere perhaps?) or else something else running on the host is perhaps interfering with it. Notice the results of the several The first time it says scsimount is not active for Something very weird is obviously going on somewhere! Do you have some type of "Storage Manager" product installed on this box perhaps? Some type of software that is wanting/expecting to be "in control of" your tape drives? If so, try disabling it. I know that on Windows such software will cause scsimount to misbehave. Perhaps the same thing is happening with you? What type of tape drives do you have? What brand/model? We might need to add some additional "smarts" to our open/scsimount logic. Right now we're relying on the In any case there's nothing more I can do or even suggest. Sorry! Just tun off whatever Tape Storage Manager software you might have (if any) and try again. |
|
When the problem occurs and your |
|
Some additional information: There is no storage manager software on this system. Tape drives are fibre channel attached (scsi over fiber channel). /dev/nst0 is a StorageTek 9840 fiber channel drive To rule out that the errors had anything to do with the fiber channel HBA or fabric I connected the TZ07 drive directly via SCSI interface but see the same problem. Could it be that the SETBLK is rejected at the Linux tape driver because the drive is ‘not ready’? Here is how the tape drives respond on Linux without Herc running: (*** with Drives in 'NOT READY' condition ***) root@debian8:/home/ken# mt -f /dev/nst0 status root@debian8:/home/ken# mt -f /dev/nst1 status root@debian8:/home/ken# mt -f /dev/nst2 status (set blocksize results in I/O error) root@debian8:/home/ken# mt -f /dev/nst0 setblk 0 (*** with Drives in READY condition ***) root@debian8:/home/ken# mt -f /dev/nst0 status root@debian8:/home/ken# mt -f /dev/nst1 status root@debian8:/home/ken# mt -f /dev/nst2 status (set variable block size is accepted) root@debian8:/home/ken# mt -f /dev/nst0 setblk 0 |
|
Thank you for that, Ken. It is still unclear to me what you mean by the drives being "ready" or "not ready" however. Does "ready" mean the drive is simply online and accessible? Or does it mean a tape is mounted on the drive? This is what I hate about SCSI tape handling across host operating systems. There's apparently no consistency. According to SCSI Tape Driver documentation on kernel.org, the However, according to Hewlett Packard's documentation (pages 95-96), the But even that is ambiguous. In the mainframe world, whether or not a tape drive is ready and whether or not a tape is mounted are two completely different statuses, both of which need to be reported separately to us. Does HP's Kern Sibbald lamented about the same issues back in 2005 in the "Tape drive handling on FreeBSD" thread: Based on what I'm seeing in this Hercules issue it doesn't appear that things have improved all that much since. He does however go on to suggest a possible workaround: I must have missed that in my earlier research from years ago. Perhaps all I need to do is add some additional code to also check the permissions associated with the returned file descriptor (however one does that on *Nix) upon being returned a status where the Or... maybe we need to define a new code block in Or... Maybe we need to define a new special option for HP tape drives? (or other manufacturers, brands or models whose tape drivers don't use It's clear to me now what was going on in your original test: because the status that your HP system was returning didn't have the (sigh) What a mess. |
|
Sorry for inconsistent terminology, by READY I mean tape mounted and the ONLINE led lit. I will add some more detail with and without automount enabled. Thanks |
|
I'd also like to see some additional In other words, I'd like to see separate
Ideally we should see four different sets of statuses, but I'm going to pessimistically guess we probably won't. |
|
To continue with the ready/online subject. If the drive is powered-up and connected to the host via FC or SCSI, it is online in the sense that the host can query it for status. In the classical mainframe and mincomputer sense it is online when a tape is mounted and the "ONLINE" button has been pressed. You can't get "ONLINE" to light-up if there is not a tape mounted & ready. The additional mt status results below. We have 2nd and 3rd generation tape drives here, the ONLINE status bit seems consistent. I would suggest that the STATUS inquiry be used to test that bit to see if as tape is mounted. If ONLINE is set, then issue BLKSIZE 0 to set variable length block mode on the drive (if necessary).
root@debian8:/home/ken# mt -f /dev/nst0 status
not possible on 9840 drive
not possible on 9840 drive
root@debian8:/home/ken# mt -f /dev/nst0 status
root@debian8:/home/ken# mt -f /dev/nst2 status
root@debian8:/home/ken# mt -f /dev/nst2 status
not possible on TSZ07 drive
root@debian8:/home/ken# mt -f /dev/nst2 status |
|
Closed this in error |
|
Herc started with "SCSIMOUNT NO" and MVS 3.8J has been IPL'd HHC01603I scsimount (tapes are mounted and ONLINE now) HHC01603I scsimount |
New option "--online" to test GMT_ONLINE bit for SCSI tape mounts. Also new "-d" (debug) option to enable display of status bits during open process. Refer to updated documentation for further details. This hopefully closes issue #97.
|
@kensmyth: Commit a68c119 (scsitape enhancements to fix for issue #97) should hopefully resolve this issue without impacting existing behavior for others. Please give it a try and let me know:
(Note: if it doesn't then please re-open this issue.) Briefly, in order for this change to address your problem you need to add a new driver option to your Hercules configuration file device statement called The For more information please refer to the updated configuration file documentation for tape drives. Thanks. |
New option "--online" to test GMT_ONLINE bit for SCSI tape mounts. Also new "-d" (debug) option to enable display of status bits during open process. Refer to updated documentation for further details. This hopefully closes issue hercules-390#97.
|
Built the modified version but hit another problem. SCSI errors (start Hercules) (job HERC01TT wants to allocate drives 481 & 482) (drive 480 get checked and tape dismounted, 480 is not assigned by job HERC01TT ?) (MVS tries to check the tape labels and decides they are not correct (probably b/c scsi read error, then dismounts them)) (after tapes are reloaded and ready) (nothing else happens) (JCL for the job HERC01TT that was running, this normally runs to completion on older Herc 4.00 after timeouts with SCSI errors HHC00205E ) |
(Environment: Debian 8.3 Linux, Hyperion 4.00, hardware HP DL380g5)
With SCSIMOUNT active, an error occurs ~every 2 minutes as each SCSI drive is checked. It would seem that a SETBLK command is being issued but a drive will not accept that if it is not-ready. Seems like a STATUS command would make more sense here as it is accepted even if a drive is in a not-ready condition. If the tape drive is made ready, the errors stop.
With SCSIMOUNT off, these errors occur when a tape is rewound/offline'd by the MVS guest.
Hercules startup log:
Hercules configuration file:
The text was updated successfully, but these errors were encountered: