Xref: utzoo comp.unix.ultrix:2554 comp.sys.dec:2468 comp.periphs:2458 comp.os.vms:21609
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!think!snorkelwacker!spdcc!dyer
From: dyer@spdcc.COM (Steve Dyer)
Newsgroups: comp.unix.ultrix,comp.sys.dec,comp.periphs,comp.os.vms
Subject: Re: Exabyte 8200 on a DECstation 3100 ?
Message-ID: <1247@ursa-major.SPDCC.COM>
Date: 16 Jan 90 19:53:30 GMT
References: <513@massey.ac.nz>
Reply-To: dyer@ursa-major.spdcc.COM (Steve Dyer)
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Lines: 21

I found that during my upgrade from Ultrix 3.0 to Ultrix 3.1,
my kernel had a lot of xxxx_data.o files which did not get rebuilt
from their new xxxx_data.c files.  Thus, I was building a
composite Ultrix kernel with some 3.0 binaries and some 3.1 binaries.

At the very least make sure that scsi_data.o is built from scsi_data.c.
The Ultrix 3.1 scsi driver relies on the presence of a 3.1 scsi_data.c
entry for the Exabyte--it will misbehave if you are building a kernel
with an older 3.0 scsi_data.o.

If the Exabyte is recognized as a "TZ88" upon boot up, then you've
got the wrong file from 3.0 linked into your kernel.  It should be
recognized as a "TZxx".  Since cleaning this up, the Exabyte has
been working fine.  The dip switches on the drive should include
"no disconnect on odd byte boundaries".


-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edu