Strange QIC150 problem (reads OK, writes corrupted) 4/330 two SCSIs
2007-12-25 8:10:00
I've been procrastinating sending this out, since I never have solved
the problem (most of the proposals require bringing the system down, which I
don't really want to do, as long as they have other tape drives they can use).
Anyway, here's my original query:
======================================================================
Have an odd one here. We've got a 4/330 running 4.1.2. It has two SCSI
controlers, the sm0 controller that shipped with it, and a VME si controller
(si0) which we recently added.
We added the second controller at the advice of our optical jukebox vendor,
who said that their juke box would work better on a SCSI bus of its own.
We have a QIC150 1/4" drive on the original (sm0) controller, and it has
started to act funny. I have verified that it reads tapes from other drives
correctly, but when I cut tapes and then read them back in, I get corrupted
data. Curiously enough, tar doesn't complain about checksums, but if I
extract files and them sum them against the originals, the extracted ones
are definitely bad. Using od -x shows that the errors seem to be single
bit errors in bit 8 of a byte: ie a 0xc5 extracts as a 0x85.
Our system disk, which is also on the sm0 bus seems to be unaffected.
I suspect that we are having trouble either because of putting in the second
SCSI controler, because of the jukebox device drivers (which are rather
flaky), or because of the jukebox itself. (We have already replaced the
tape drive assembly once).
Has anyone seen anything like this before? Anyone using two SCSIs on a
4/330?
=============================================================================
And the responses:
===========
trdlnk!mike@uunet.UU.NET (Michael Sullivan) comfirms from experience
that a Sun4 can run happily with an sm0 and an si0.
==========
louis@andataco.com (Louis M. Brune) suggests checking the "usual suspect"
such as termination, cables, etc, and to try changing the SCSI bus
order.
That doesn't seem to be it... (TN)
==========
dan@bellcore.com (Daniel Strick) suggests making sure parity checking is
enabled on the tape drive. (On Archive 2150S this is a "lock of
nine jumper positions just to the left of the SCSI cable connector
(as viewed from the rear of the drive) and the parity enable is
the one on the lower left. It should have a jumper installed.")
This sounds like a good idea, but I haven't opened up the drive yet,
since if I understand correctly, this won't solve my problem, just
make sure that I get error messages. (TN)
===========
ups!kalli!kevin@fourx.Aus.Sun.COM (Kevin Sheehan {Consulting Poster Child})
suggests that tar only checksums headers, which explains why tar is
not reporting errors. He also suggests that the bus itself is
probably not bad, since the disk works OK and to try dding large
files on and off the drive to check the drive itself.
We've swapped the drive with a new one in the past to no avail, so
I'm fairly sure its not the drive.. (TN)
==========
Thanks to everyone for their responses!
Ted Nolan
Comments
Got something to say?
You must be logged in to post a comment.
