03-10-2014 01:07 PM
Hello Everybody
My robot stopped to work. I can see it here :
Solved! Go to Solution.
03-10-2014 02:45 PM
/dev/sg/c1tw500143801605d386l0: Tape (/dev/rmt/4): "HP Ultrium 4-SCSI"
The above is NOT a robot - it is a tape drive.
This is a robot:
/dev/sg/c0tw2002000e1111677dl1: Changer: "IBM 3573-TL"
and this one too:
/dev/sg/c0tw500104f000597437l0: Changer: "STK L180"
You never told us your Solaris version?
Or NBU version?
Do you have the latest device mappings installed?
I find it strange that cfgadm and sgscan output seems to be totally different.
Do you have persistent binding in place?
My suggestion is to cleanup device entries with devfsadm -C -c tape and ensure that persistent binding is in place.
Then perform reconfiguration reboot and confirm device entries - compare cfgadm and sgscan output.
Let us know how it goes....
03-10-2014 02:34 PM
Did you just upgrade firmware?
If everything was working before, you might want to try and reboot the robot and restart ltid. See if it syncs back up. If not remove the devices and readd with the wizard. If all else fails, you will want to rebuild your SG drivers (TECH63095). It would not hurt to even do that first.
03-10-2014 02:45 PM
/dev/sg/c1tw500143801605d386l0: Tape (/dev/rmt/4): "HP Ultrium 4-SCSI"
The above is NOT a robot - it is a tape drive.
This is a robot:
/dev/sg/c0tw2002000e1111677dl1: Changer: "IBM 3573-TL"
and this one too:
/dev/sg/c0tw500104f000597437l0: Changer: "STK L180"
You never told us your Solaris version?
Or NBU version?
Do you have the latest device mappings installed?
I find it strange that cfgadm and sgscan output seems to be totally different.
Do you have persistent binding in place?
My suggestion is to cleanup device entries with devfsadm -C -c tape and ensure that persistent binding is in place.
Then perform reconfiguration reboot and confirm device entries - compare cfgadm and sgscan output.
Let us know how it goes....
03-10-2014 02:59 PM
From cfgadm I see 3 changers
The changer is (from cfgadm)
03-10-2014 03:13 PM
See my point in my post about rebuilding the sgdriver.
If there is no reason to believe it has changed, and it shouldn't have done, on the 'off-change' that a mistake is made when rebuilding it, it won't work, Now, if the sg driver wasn't the cause of the problem in the first place, you now have two faults that give the same symptoms.
That, is then very very diffilcult to fix, as there is no way of confirming the sg driver is correct, because of the original fault.
I think first, we confirm what (if anything has been changed).
If the sg.links and .conf files are correct (in /usr/openv/volmgr/bin/drivers) then the sg driver can be rebuilt with just these commands: