Hi there!
On January 17, 2003 at 15:20, George Sinclair wrote:
>
> I can't communicate with our ATL P1000 SDLT tape library. The library
> has two Quantum SDLT drives. The picker and devices are NOT reported by
> the /etc/LGTOuscsi/inquire command (see below). I have seen this in the
> past a few times, but normally a reboot always fixed it. This is the
Since you have used this machine in this configuration in the past,
I assume that the /dev/st*, /dev/nst*, and /dev/sg* device files
exist. Silly things first, don't you know :-)
And SCSI ID's. Don't for get the SCSI id conflicts. There are
some weird messages in the output below.
> Jan 17 17:59:07 snode kernel: kmod: failed to exec /sbin/modprobe -s -k
> scsi_hostadapter, errno = 2
This doesn't look good. May be nothing, though.
<from above>
> We are actually running two libraries on this Red Hat Linux storage node
> server. The other library is an STK L80, and it's behaving fine. That
> library is on its own separate SCSI card, not the same SCSI card as the
> P1000 SDLT. In the case of the other library, its SCSI card is a dual
> channel card, so two drives are running on one channel, and the picker
> and the other two drives are sharing the other channel. We are running
> NetWorker 6.1.1 on both the storage node server and the primary server.
> The primary server is a Sun, and it manages its own library -- an ATL
> P1000 DLT 7000.
> Jan 17 17:59:07 snode kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI
> Jan 17 17:59:07 snode kernel: scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI
> Jan 17 17:59:07 snode kernel: scsi2 : sym53c8xx-1.7.3c-20010512
> Jan 17 17:59:07 snode kernel: scsi3 : percraid
4 SCSI controllers, which I believe is correct based on your mail
above. The array you are having trouble with is on the sym53c8xx
card, right?
> Here's the output from the inquire command:
>
> NetWorker: SYSTEM error: read failed with 'Resource temporarily
> unavailable'on try 9
This means NetWorker attempted to open the device and request
scsi inquiry data and received an error from linux when it
attempted to read the result. It tries 10 times to do this.
> [email protected]:SEAGATE ULTRIUM06242-XXX1460|Tape, /dev/nst0
> [email protected]:SEAGATE ULTRIUM06242-XXX1460|Tape, /dev/nst1
> [email protected]:STK L80 0211|Autochanger (Jukebox),
> /dev/sg2
> [email protected]:SEAGATE ULTRIUM06242-XXX1460|Tape, /dev/nst2
> [email protected]:SEAGATE ULTRIUM06242-XXX1460|Tape, /dev/nst3
> [email protected]: |Disk, /dev/sg5
> [email protected]: |Disk, /dev/nst4
> [email protected]: |Disk, /dev/nst5
> [email protected]:DELL PERCRAID RAID10 V1.0|Disk, /dev/sg8
> Jan 17 17:59:07 snode kernel: Attached scsi tape st0 at scsi0, channel
> 0, id 2, lun 0
> Jan 17 17:59:07 snode kernel: Attached scsi tape st1 at scsi0, channel
> 0, id 3, lun 0
> Jan 17 17:59:07 snode kernel: Attached scsi tape st2 at scsi1, channel
> 0, id 4, lun 0
> Jan 17 17:59:07 snode kernel: Attached scsi tape st3 at scsi1, channel
> 0, id 5, lun 0
> Jan 17 17:59:07 snode kernel: Attached scsi tape st4 at scsi2, channel
> 0, id 2, lun 0
> Jan 17 17:59:07 snode kernel: Attached scsi tape st5 at scsi2, channel
> 0, id 3, lun 0
What does the OS think? If you run 'mt -f /dev/nst4 status' what
do you get? And, if you check /proc/scsi/scsi as well, though
that will probably relate the boot messages.
Byron
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
