StoreEver Tape Storage
cancel
Showing results for 
Search instead for 
Did you mean: 

Daisychaining HP Surestore C9264CB

 
Highlighted
Regular Advisor

Daisychaining HP Surestore C9264CB

I had a Dell equivalent of the HP Surestore device and an HP Surestore C9264CB. I tried daisychaining the two on a SCSI bus, the HP at SCSI ID 5, the Dell at ID 6. After connecting everything I powered up the Proliant 6500. Both devices are on the internal SCSI controller via the external interface. The machine runs Red Hat Linux v9. When the mahcine boots it scans the SCSI bus and identifies both correctly. Linux sees the both devices as well assigning them device names /dev/sg0 and /dev/sg1. I can interact with the HP using the mtx software to load and unload tapes but when I tried the Dell it would produce an error.

Thinking the Dell unit may be defective I purchased an identical C9265CB, set it's SCSI ID to 6 and brought everything up. SCSI BIOS saw both devices, Linux also saw them assigning the same /dev/sg0 and /dev/sg1 to them but again trying to interact with the device on ID 6 I get the same failures

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 = 03
mtx: Request Sense: BPV=yes
mtx: Request Sense: Error in CDB=yes
mtx: Request Sense: SKSV=yes
mtx: Request Sense: Field Pointer = 00 00
READ ELEMENT STATUS Command Failed

I have the SCSI cable going into the bottom interface of the first tape robot, a small 18 inch cable from the top interface of the first robot to the bottom interface of the second robot and a terminator on the top interface of the second robot.

Both robots have 3 DLT cartridges loaded, both power up without errors.

I have been able to write to the tapes in the /dev/sg0 with a linux tar -zcvf /dev/st0 filenames and able to read the tapes successfully. My problem is I need to have both tape robots available for full and differential backups in a week's time, can't be changing tapes manually.

Is there a problem daisychaining two DLT robots together?
13 REPLIES 13
Highlighted
Acclaimed Contributor

Re: Daisychaining HP Surestore C9264CB

I'm not exactly sure what device this is, but must be an autoloader.

Depending on the settings there are 1 or 2 SCSI addresses per device (robot and drive) or it does LUN mode (e.g. 6:0 is robot, 6:1 is drive) with a single ID per box.

You should check for unique SCSI IDs.

Hope this helps!
Regards
Torsten.

__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.

__________________________________________________
No support by private messages. Please ask the forum!

If you feel this was helpful please click the KUDOS! thumb below!   
Highlighted
Regular Advisor

Re: Daisychaining HP Surestore C9264CB

Yes, they are autoloaders. Already verified each robot has unique SCSI ID. The Dell unit I had attached to a Proliant DL380 and it worked fine but that was a single robot. As stated before I need to have the two autoloaders available for full and differential backups throughout a week, eight cartridges in a single autoloader doesn't meet the needs.
Highlighted
Acclaimed Contributor

Re: Daisychaining HP Surestore C9264CB

The manual says:

...
The HP StorageWorks 1/8 Ultrium 232, Ultrium 448 and Ultrium 960 Tape Autoloader models
and the DLT VS80 Tape Autoloader models occupy one SCSI ID.
...
All other Tape Autoloader models occupy two SCSI IDs...


So check if a single box occupies 1 or 2 SCSI IDs.

Hope this helps!
Regards
Torsten.

__________________________________________________
There are only 10 types of people in the world -
those who understand binary, and those who don't.

__________________________________________________
No support by private messages. Please ask the forum!

If you feel this was helpful please click the KUDOS! thumb below!   
Highlighted
Regular Advisor

Re: Daisychaining HP Surestore C9264CB

Googling this problem someone suggested changing the configuration to have Autoloader=Off to Autoloader=On. I did that, rebooted but still no luck accessing the second robot other than with the inventory command.

I reset the SCSI ID on the original unit to use ID 3 and cycled the power on the tape robot as it instructed. I rebooted the linux machine, the BIOS saw both tape robots at the correct SCSI IDs. Linux booted and saw both devices at the correct SCSI IDs.

If I run

mtx -f /dev/sg0 inventory

the original robot scans all slots.

I then run

mtx -f /dev/sg1 inventory and it too scans all slots.

I run mtx -f /dev/sg0 inquiry
and same for sg1 and both return information.


mtx -f /dev/sg0 inquiry
Product Type: Tape Drive
Vendor ID: 'BNCHMARK'
Product ID: 'VS640 '
Revision: '5032'
Attached Changer: No

[root@vrod sg]# mtx -f /dev/sg1 inquiry
Product Type: Tape Drive
Vendor ID: 'HP '
Product ID: 'C9264CB-VS80 '
Revision: '5E40'
Attached Changer: No
[root@vrod sg]#

Running mtx -f /dev/sgX status produces:

mtx -f /dev/sg0 status
Storage Changer /dev/sg0:1 Drives, 8 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
Storage Element 7:Full
Storage Element 8:Full
[root@vrod sg]#
[root@vrod sg]# mtx -f /dev/sg1 status
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 = 03
mtx: Request Sense: BPV=yes
mtx: Request Sense: Error in CDB=yes
mtx: Request Sense: SKSV=yes
mtx: Request Sense: Field Pointer = 00 00
READ ELEMENT STATUS Command Failed
Highlighted
Honored Contributor

Re: Daisychaining HP Surestore C9264CB

I would like to be sure I well understand:
you have a server with a HBA
you have two autoloaders

first autoloader is a 1/8 with a VS80 tape drive

second autoloader is a Dell with a DLT drive


your goal is to daisy chain both unit on the single scsi chain.


well for what I know:
the HP 1/8 with VS80 use a single SCSI id and two luns (lun 0 and lun 1) so you should be sure you enable lun scanning in your HBA bios

the Dell autoloader is unknown to me, but I may suppose that it use two SCSI id, one for the drive and one for the robot (could be also it use LUN mode, it should appear in next step)

at this point, you should first be sure that during POST of your pc, when the control is passed to the HBA Bios, you can see all the four devices (two robots and two drives) it is not important if it is a LUN or a SCSI ID, all four device should appear in the list at that moment.

if you cannot see all four device, try to attach one at a time, and identify what can be seen and what cannot.

when all four devices are listed in the hba bios, then you can proceed further


I'm not a Linux specialist, but from your last output it looks like you can see only the two tapes one a vs80 and another is a SDLT640, both are probably the LUN 0 of the relative scsi ID > then probably it is enough to enable LUN scanning in your HBA Bios
Highlighted
Regular Advisor

Re: Daisychaining HP Surestore C9264CB

No, the Dell is out of the picture. The Dell had worked on the DL380 with an Adaptec SCSI Raid controller as it's interface. The DL380 was destined for another customer so I tried moving the Adaptec RAID controller (don't know model number) into my Proliant 6500. The 6500 didn't like the Adaptec / Dell combination so I moved the Dell tape to the onboard SCSI. It still wouldn't work (similar sense code errors) so I tried the HP. The HP works fine with the on board SCSI. My problem is I need more cartridges than a single 1/8 Autoloader provides. I purchased another, same model but it has different tape drive. The HP that works says it has a BNCHMARK VS640 (same as Dell) the HP that doesn't work says it's Vendor ID is HP and Product ID is 'C9264CB-VS80'. I don't know if that is part of the problem.

So to be clear, I have two C9264CB Autoloader 1/8 devices, the first (working) at SCSI ID 3, the second (not working) at SCSI ID 6.

I don't know how to get into the Proliant's onboard SCSI configuration to enable LUN scanning.

Why would one unit work and the other not.
Highlighted
Honored Contributor

Re: Daisychaining HP Surestore C9264CB

I know for sure the autoloader with the tape drive VS80 use Lun for the controller.
I do not know for the autoloader with the VS640

did you observed the server monitor during POST? did you see the HBA scanning? did you identify what is detected? during the POST, when you see the HBA banner, you shoudl probably see also a message like "press CTRL A or press F8" to enter the bios... this is the key to enter and enable lun scanning
(usually raid controllers do not support lun scanning, and do not support tape drive)
Highlighted
Regular Advisor

Re: Daisychaining HP Surestore C9264CB

The Proliant 6500's on board SCSI does not display "CTRL-A" or "F8" to configure it. It just scans the ports and identifies the two Surestore autoloaders at their correct addresses. The server is busy this time of day so I can't try booting with the SmartStart CD to try configuring it that way. I'll have to try tomorrow when there is light load on the server.
Highlighted
Honored Contributor

Re: Daisychaining HP Surestore C9264CB

Lots of discussion around cabling/config/etc but the problem isn't there. In the error message it says that the communications with the library are working just fine:
[root@vrod sg]# mtx -f /dev/sg1 status
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 = 03
mtx: Request Sense: BPV=yes
mtx: Request Sense: Error in CDB=yes
mtx: Request Sense: SKSV=yes
mtx: Request Sense: Field Pointer = 00 00
READ ELEMENT STATUS Command Failed

The above is an error message saying that the READ ELEMENT STATUS command sent by mtx was illegal with this device. It points to an error in byte 3, bit 0 of the CDB which is a field called "STARTING ELEMENT ADDRESS". It doesn't say waht value was in that field of the CDB but appently mtx is sending a value that the autoloader doesn't support.

That is a really old autoloader. I'm not able to look and see if mtx was supported with that autoloader or not.

You might check and see if that is new enough that it has a configuration for "Random" mode or "Sequential" mode. If so set it to "Random" as the READ ELEMENT STATUS command isn't allowed when in Sequential.