[comp.sys.dec] Exabyte 8200 on a DECstation 3100 ?

GEustace@massey.ac.nz (Glen Eustace) (01/16/90)

We have just aquired an 2 Exabyte 8200 video tape drives.  It is our
intention to use these drives on our DECstation 3100s, but to date can
not even get the machines to boot.

We have the drives set to Unit 4, a 'test -c' from the boot prompt
correctly finds the drive and identifies it as a TAPE etc etc.

I am not exactly sure what version we have, the config file has

Ultrix_3.0_FT1, but we have done an upgrade to 3.1

Anyway, when we boot the kernel finds our 3 rz disks as rz0-2 and then
the tape drive as tz4 (tz??), it then print the ethernet Address and hangs.

The NZ supplier has never used one on a DECstation 3100 but has
successfully on a VAXstation 3100 under VMS, we are the guinea pig!  Has
anyone managed to get one of these drives or something similiar
successfully configured onto a DECserver 3100, and if so what must we do.
If no one has, can anyone suggest what might be going wrong?

-- 
-----------------------------------------------------------------------
  Glen Eustace, Software Manager, Computer Centre, Massey University,
   Palmerston North, New Zealand. Phone: +64 63 69099 x7440 GMT+12
             E-Mail via Internet: G.Eustace@massey.ac.nz
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

dyer@spdcc.COM (Steve Dyer) (01/17/90)

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

grr@cbmvax.commodore.com (George Robbins) (01/17/90)

In article <1247@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
> 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.

Did you remember to do a "make depend"?

After installing an upgrade the best thing to do is remove or rename the
build directory (/sys/XXXX or /sys/MIPS/XXXX) and then do the config/make.

Doing config ; cd ; make clean ; make depend ; make vmunix is a resaonable
approximation...
-- 
George Robbins - now working for,	uucp: {uunet|pyramid|rutgers}!cbmvax!grr
but no way officially representing	arpa: cbmvax!grr@uunet.uu.net
Commodore, Engineering Department	fone: 215-431-9255 (only by moonlite)