[91] in SIPB-AFS-requests
this may eventually be useful knowledge
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Thu Nov 2 09:22:31 1989
Date: Thu, 2 Nov 89 09:03:08 EST
From: John T Kohl <jtkohl@ATHENA.MIT.EDU>
To: sipb-afsreq@ATHENA.MIT.EDU
> From: coppi@groucho.tapir.Caltech.EDU (Paul Coppi)
> Newsgroups: comp.sys.dec
> Keywords: PMAX, Exabyte
> Date: 1 Nov 89 18:48:07 GMT
> Reply-To: coppi@groucho.tapir.Caltech.EDU (Paul Coppi)
> Organization: Theoretical Astrophysics, Caltech
> Thanks to all those who answered our request for help a couple
> weeks back. Our Exabyte seems to be working fine now. The
> problem apparently arose because the DS3100 SCSI cannot handle
> disconnects on an odd byte boundary while our Exabyte had
> odd byte disconnects enabled. Thus, when another SCSI device asked
> for the bus and the Exabyte disconnected, the DS3100 always thought
> the last two bytes in the transfer had been written. In reality,
> the Exabyte sometimes only wrote the second-to-last byte and ignored
> the last one (because it had disconnected itself from the bus).
> Hence the dropped bytes we were seeing. That's my theory anyways.
> To remedy this problem, switch 3 on the 8 bit DIP switch on the
> "MX Card" must be set to the ON position to disable odd byte
> disconnects. Apparently some older
> Exabytes have a set of jumpers instead of the DIP switch.
> Jumper J3 must be set to the "L-M" position. The jumpers are apparently
> located next to an IC labeled U30, while the DIP switch is obvious.
> (There is only one.) Getting to the DIP switch is a bit involved as
> the card cage in the Exabyte must
> be partially disassembled to yank the relevant card out. (Second
> one in from the end with the SCSI connector? I forget.) As always,
> make sure you have grounded yourself. One little static discharge
> and you're in for very expensive repairs. Also, you may wish to consult
> the company you bought the drive from with regards to invalidating
> warranties, etc.
> With the DIP switch set properly, the Exabyte appears to work
> fine for us. Note that we are running Ultrix 3.1. Ultrix 3.0 may have
> some additional problems in its SCSI drivers.
> Thanks again to those who helped,
> Paolo Coppi
> (coppi@zeppo.caltech.edu, coppi@tapir.caltech.edu)
