: SUMMARY: Strange QIC150 problem (reads OK, writes corrupted) 4/330 two SCSIs

From: Ted Nolan SRI Ft Bragg (ted@usasoc.soc.mil)
Date: Tue Mar 30 1993 - 15:38:06 CST


Hello folks,

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
                                ted@usasoc.soc.mil



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:39 CDT