I don't know the part numbers for the bad cables because StorageTek took
the old ones back. I should also note that it wasn't just the round SCSI
cables to the server that were replaced. They also replaced the external
round cables that connect the various daisy chained components in the
library, i.e. the drives, picker, etc. with flat ribbon style cables.
Looking at the various cables, I see a lot of numbers, but with the
exception of the terminators, I don't see any that actually indicate
"P/N", but here they are:
<< Round SCSI cables to server >>
The cables are black. The printing on the cable reads: Style 20276 30V
VW-1 Madison Cable Corp. There is also a sticker on the cable that
reads: 10083684 124034 COP120200 Amphenol 00/52
Both SCSI cables have the same information.
<< Flat Ribbon cables >>
The cables are black. No printing appears on the cable, only a sticker
that reads: Woven Electronics SCSI68 3137088-02 425001 EC Number 140563
All ribbon cables have the same information.
<< Terminators >>
Ultra 2/Ultra160/Ultra3 Amphenol P/N 497040001
I'm not saying that you don't have the right cables, but we thought we
did since we were operating just fine for a while. We just assumed that
StorageTek would have given us the right cables since they outa know
what we're using. I mean they did. They saw our setup. And, since
everything worked okay for while what else were we to think?! We found
out otherwise -- as in we found out the ones we had were not the right
type, never mind the fact that they would might fine with other
equipment -- and if another supplier has provided you the cables, I
think it might be worth a visit from StorageTek or maybe contacting them
just to double check that you indeed have the right "type". Until you
can "absolutely" rule out the cables, you won't be eliminating the
biggest variable.
George
"Neild, Jim" wrote:
>
> What was the part number for the wrong cables and the number for the
> replacements?
>
> Cheers,
> Jim
>
> -----Original Message-----
> From: George Sinclair [mailto:George.Sinclair AT NOAA DOT GOV]
> Sent: Wednesday, June 04, 2003 10:47 AM
> To:
> Subject: Re: [Networker] SCSI errors
>
> We are using a StorageTek L80, running a storagenode server on a Redhat
> Linux box, and we were seeing similar problems for a while. It turned
> out that we had the wrong SCSI cables. They were NOT the proper LVD
> cables, but you wouldn't know it by looking at them. Interestingly,
> however, we did manage to run trouble free for a while before the errors
> starting rearing their ugly heads. After that, it was intermittent, so
> just because you don't have the proper cables doesn't mean that backups
> may not succeed part of the time. StorageTek came and replaced the
> cables. They admitted that they had had numerous complaints from
> customers about these SCSI problems and bad SCSI cables. After replacing
> the cables, the problems went away. Check the part numbers on those
> cables and call StorageTek to verify that you absolutely have the right
> ones. Do not assume you do.
>
> George
>
> Frank Altpeter wrote:
> >
> > hi again,
> >
> > It seems that i don't have any time to celebrate any little success,
> > since it doesn't take long time for the next problem to appear :-(
> >
> > Since some weeks i sometimes see SCSI errors in the system log file,
> > like these:
> >
> > Jun 1 12:45:12 r2d2 kernel: scsi : aborting command due to timeout :
> > pid 213591 32, scsi2, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00
> >
> > In the beginning, there was only scsidev 0,0,0 (the first of five LTO
> > ultrium tape devices) that got the error. Because i assumed the error
> > in the SCSI card, i disabled this drive until i can contact a
> > StorageTek professional to check it.
> >
> > But now i see SCSI errors on all five tape devices. The tapes are
> > distributed to three Tekram DC-390U3W cards. So i don't think that the
>
> > cards are causing the errors, but i don't have any clue where to
> > search now.
> >
> > Additionally to the above entry, i'm getting a lot of these now:
> >
> > Jun 4 08:40:30 r2d2 kernel: sym53c1010-33-0-<6,*>: target did not
> > report SYNC. Jun 4 08:40:31 r2d2 kernel: scsi : aborting command due
> > to timeout : pid 30973041, scsi5, channel 0, id 4, lun 0 Inquiry 00 00
>
> > 00 f f 00 Jun 4 08:40:31 r2d2 kernel: sym53c8xx_abort: pid=30973041
> > serial_number=30972996 serial_number_at_timeout=30972996
> >
> > I know this is slightly off-topic, but it's a great problem for me,
> > and btw. NetWorker of course refuses to work if a tape devices keeps
> > hanging in the 'verifying label' state due to scsi timeouts...
> >
> > Well, to the hardware:
> >
> > 3 x Tekram DC-390 U3W Ultra 160 SCSI cards
> > 5 x IBM LTO Ultrium drives, builtin to a StorageTek L700 tape library
> > 1 x ASUS PR-DLSW Dual Intel Xeon-based motherboard 2 x Intel Xeon 2
> > GHz 1 x 1024 MB RAM
> > 1 x Redhat Linux 7.3 (Valhalla)
> >
> > [root@r2d2 root]# cat /proc/scsi/scsi
> > Attached devices:
> > Host: scsi0 Channel: 00 Id: 05 Lun: 00
> > Vendor: easyRAID Model: F8 Rev: 0001
> > Type: Direct-Access ANSI SCSI revision: 03
> > Host: scsi0 Channel: 00 Id: 06 Lun: 00
> > Vendor: STK Model: L700 Rev: 0301
> > Type: Medium Changer ANSI SCSI revision: 03
> > Host: scsi2 Channel: 00 Id: 00 Lun: 00
> > Vendor: IBM Model: ULTRIUM-TD1 Rev: 27Q1
> > Type: Sequential-Access ANSI SCSI revision: 03
> > Host: scsi2 Channel: 00 Id: 01 Lun: 00
> > Vendor: IBM Model: ULTRIUM-TD1 Rev: 27Q1
> > Type: Sequential-Access ANSI SCSI revision: 03
> > Host: scsi2 Channel: 00 Id: 02 Lun: 00
> > Vendor: IBM Model: ULTRIUM-TD1 Rev: 27Q1
> > Type: Sequential-Access ANSI SCSI revision: 03
> > Host: scsi5 Channel: 00 Id: 03 Lun: 00
> > Vendor: IBM Model: ULTRIUM-TD1 Rev: 27Q1
> > Type: Sequential-Access ANSI SCSI revision: 03
> > Host: scsi5 Channel: 00 Id: 04 Lun: 00
> > Vendor: IBM Model: ULTRIUM-TD1 Rev: 27Q1
> > Type: Sequential-Access ANSI SCSI revision: 03
> >
> > With kind regards,
> >
> > Frank Altpeter
> >
> > --
> > 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.
> > =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>
> --
> 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.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
--
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.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
